When and where to do animations for Non-Character Assets in Game Engines?

zachagreg

So I couldn't find this info in the animation wiki and can't for some reason put this into google correctly for the results I'm looking for. 

I was wondering what is the recommended process or best case scenario for putting non character animations into engine. Non-character as in props or things that the character may interact with. 

Specific use case being a kit full of different items that someone would have to construct sequentially. ie) Opening a sandwich kit with ingredients in it, taking each ingredient out one by one, then clicking the specific ingredients in order to build the sandwich in which the only animations would either be folding or moving the item onto the sandwich.

I know for the animations that require any sort of object oriented animation such as bending, folding or wiggling it would be best to do the animations in the DCC, however for the animations of the items going in and out of the case or to and from the sandwich would those also be better suited to be done in the DCC or done in the engine?

Mark Dygert

In engine animation is still like working in the dark ages and most animators would prefer to work where they'll have the most control and easiest time. 

I'm not sure a sandwich is the best scenario because there really isn't much to rig up or animate, but maybe that's just how I'm thinking of how it can be done?

1) Click and done
 You click the ingredient and it pops into its final state on the sandwich. Not much animation there, just posing the pieces. Maybe the ingredient has 3-4 states but really the anim work is minimal, mostly posing and popping.

2) Click and drag
You pick up the ingredient and drag it around the scene and place it where you want. There isn't much animation, maybe some dynamics so things have secondary motion and they wiggle, flop and lay down. There might be some light anim work but not much. This is pretty unpredictable and very much "surgeon simulator" or "I am Bread" levels of hilarity. Maybe that's what you want, maybe not? /shrug

3) Click and play
You click it plays an scripted animation. This would more than likely be done in DCC, most control, longest production time, might be frustrating to players that have to sit through repetitive animations. The appreciation for animation quickly falls off the more you make people watch it, if it even exists in the first place. Most people wouldn't even appreciate the work that would go into making a sandwich. Considering the production cost involved and the diminishing returns, most people would probably go with option 1, unless it's a really important part of the game?

Anyway...
Most "non-character" animation is handled the same way, with joints, rigging and animators doing their thing. They really don't animate "characters" they animate controllers that drive joints, so how those get configured really doesn't matter that much. If the controller drives the elbow or a treasure chest, they really don't care, the principles of animation apply to anything that moves.

zachagreg

Thanks Mark, that clears up a lot. The usage case here is mostly 3) Click and play at least for the functionality that we've been doing. While I completely agree with the drawbacks of that case and is much of the reason why I am asking this question. As to me that case requires so much unnecessary production time due to the multiple states of each object needed to be "animated" to and fro from potentially different places. An example being a tomato coming from the case to the sink then to the cutting board and finally to the sandwich, however with some instances it needing to go directly from the case to the sandwich. It's an instructional scenario the sandwich is just an example.

I know this example is horrendous but frankly that's the gist of what we're having to do here, so ultimately not my decision. However, I also don't like wasting company time on a problem that can be handled more elegantly and with less cost. Such as you point out. Option 3 quickly gets boring and costs a lot to produce. Especially when getting into more complicated instructional portions that are worse than a sandwich and has multiple components interacting with each other in various orders. Such as running various tests using a chemistry set.

A follow up what is the common process with using bones on objects that do not have any hinges or deformations? Such as an object just having the one bone that controls a crate or tomato. Bone or no bone in those situations? Or would it depend upon engine and usage? 

Mark Dygert

It really depends on the engine and the game.

Usually static meshes/objects can be animated in engine without bones but often it unlocks a lot more tools if the object is treated as a skeletal mesh. Even as a simple one with just one joint can unlock certain skeletal mesh tools that just aren't available to static meshes.

If you need to load animations onto the object or if you can get away with animating it in engine. Most animators will want the control of DCC so that means skeletal meshes. Just being able to load animations onto a skeletal mesh can be enough to go that route. But then if the animation isn't important and it's just moving from A to B you might be able to get static meshes to do what you need.

With that said, skeletal meshes can cost more resources than static meshes, but building a system that deals with both static and skeletal can be a mess so a lot of people will pick one. Usually the one that gives them the most options and flexibility (skeletal) and they just eat the extra tech cost as part of the overhead. 

In the case of the game I'm working on...
we decided that all of our weapons where going to be skeletal and most of the simple weapons (swords and clubs) have just a single joint but the more complex weapons have a much more complex skeletons. But because they're skeletal meshes we can run blank animations that embed notify flags in the anims to drive different events. We could have picked static mesh and driven those events through blueprints or code but that wouldn't let our artist/animators interact with them in an easy way. Since our most complex items required animations we decided to treat everything that way and not double up on the systems and play "what if it is a..." in code.

Collision and physics are other considerations.
If you want to apply cloth to a floppy slice of meat, you're going to need a skeletal mesh even if it's one joint. You might want to do that secondary motion with a joint chain that can animate as well has have dynamics turned/blended on and off. So it can be in one pose when it's just sitting there, turn all floppy and then transition to another pose when its placed.

You can also capture dynamic poses in some engines (like unreal) and blend that with an animation. We use this when a player ragdolls, they ragdoll and get all floppy but then start to blend into an on the ground pose so we can seamlessly play a "get up" animation. That same principle can be applied to anything else that uses physics objects in Unreal.

It all starts to get very specific to the game and the engine. There are a bunch of different ways to handle and not really one solid "always do this" answer.

zachagreg

Okay that is what I had thought, is that it is very case dependent. Thanks for all of the info. We are doing a lot of skeletal meshes right now as most of our components are interactable. I fear this is causing a bit too much overhead though in the long run. As we are targeting WebGL in Unity and Unity does not bake lighting on skeletal meshes anymore. So I believe we're running into a double issue where the cost of the skeletal mesh is not just causing the tech cost but a cost to not being able to bake lighting on most objects.

Unfortunately that means we can't utilize mixed either as WebGL does not support directional lightmaps as of yet. I believe in our case there are multiple fronts that may need reworking at some point in our pipeline. But you've definitely helped to resolve one of them so for that, thank you.