animation and memory

i'm trying to get a feel for how much animation i can include in a character and how it effects memory and performance. For instance if i have a simple run cycle that is 16 frames verses a more complex loop that is 3 times the length, or 48 frames.

Also i noticed that if i export a maya scene at 24fps or 30fps that the animation clip in unity will show that value, does unity then play it back at that rate or at least attempt to? if so then my guess would be animating at 24fps would save 20% of the keyframe information. is this correct?

thanks.. my background is in film/broadcast where it is not an issue.

 

Our company had the same issue, where our animations were exported at 20 frames per second, but Unity would always import it at 30 fps regardless, so our keyframes were always off. After some research on the forums, someone from Unity, maybe the CTO, stated that it always imports at 30 fps. If you go into the animation that was imported, I always noticed that the sample rate was always 30 though, regardless of the fps when importing. Our solution was just to make everything into 30 fps to expedite the process, especially since there weren't many other options available to explore due to our time constraints. As for memory limitation and whatnot, I'll be finding that out soon enough.

 

I thought it defaulted to 60fps..?

 

Strange. My animation clips show a sample rate of 30 when i export at 30fps and 24 at 24fps. Maybe it has to do with Maya when it exports? since mayas frame rate is tied to the the time line and will scale keys if you change the frame rate. either way it looks like it plays at the correct speed.

Any idea how much longer animation clips affect the performance?

 

The performance of animations depends on a couple of different factors, and, of course, on where your playing them. First, the number of polygons used to construct the object being animated will have a big impact on performance, so keeping that as low as possible while still getting the desired look is very key. If you spend 10K of your tris/vert budget on one object, then this may or may not be a bad thing depending on what else is going on. Based on our tests, and the wisdom of the forum in general, going past 15-20K overall for older devices will create significant problems. In Maya, for example, you can reduce the number of polygons in the mesh down to the point that the mesh still looks acceptable but is also phone friendly. The 100K Orc with the 75K plasma rifle that you just downloaded off Turbosquid is not going to work on iPhone

Then there is the question of the number of bones being used in the animation. If skin quality is set to auto, then this will depend on how the object was exported from the animation tool. If it this is dialed down to 1 bone per vertex, then performance will be better, but of course, the animation will be of poorer quality. 2 bones will look better but be more expensive, etc.

Unity imports the animations at 30 FPS while Maya and other tools can export them at different rates. In Maya, this can be set in the preferences. If you don't export at 30, the key frames will be wrong which, of course, will create problems in a couple of different ways, but most importantly it will be impossible to break monolithic animations down into individual playable clips upon import, using frame number documentation.

 

so is the animation length (number of keyframes) less of a concern? i'm trying to decide between more complex/interesting loops or simpler ones.

i used smooth skinning in maya which spreads it across several bones so i imagine if it starts to lag i should optimize the skin weighting?

thanks, that's good to know. i was going to plan my animation at 24fps.

 

What really matters for your animation data is how many keys you have. If you have a rotating cube with a keyframe at time = 0 and one at time = 1.0 seconds, it doesn't matter whether your frame rate is 24 or 30fps. You still have 2 keyframes in the animation clip, which is all that Unity cares about. As Hanultech's post implied, having more bones means the clip has more animation data.

When it does make a difference, however, is when you tell Unity how to compress animations in the import settings. Animation Baking simply uses FBX's keyframe baking and reduction, so you are getting whatever FBX gives you. You can confirm all of this by looking at your animation curve data in the Animation Editor for Unity 2.6, but briefly:

1. Any channels you freeze in Maya will have no animation curve data when brought into Unity. So, if you are not animating scale, lock the scale channels in Maya and you will have no scale data: simple as that. However, if one animation clip (A) has no scale data, but another (B) does, then interrupting B by cross-fading to A is likely to produce weird results. Clip B will not be blending to a scale value of 1 since A has no animation data for the scale when it has come into Unity. The scale will just stop wherever it was when B's animation state weight reaches 0.

2. If you do not compress animations, you will get one keyframe sample for every non-frozen animation channel based on your frame rate settings (in Maya this is Window -> Settings/Preferences -> Settings subsection, Time drop-down. NOT to be confused with your playback settings in the Time Slider subsection). So you can sample at 24 fps or 30 fps or whatever you want. There are two important notes here. As far as I can tell, you can only use the named presets (Film 24, PAL 25, NTSC 30, Show 48, PAL Field 50, NTSC Field 60). Anything else appears to just sample at 30 fps on import (I am guessing this is a FBX limitation of some kind, and probably what Rekkair was talking about). Furthermore, in order to get an animation to re-sample at a new frame rate, you may have to make a change in the Maya file (i.e. so you don't get the "Warning: No changes to save." message) and let Unity reimport.

3. If you do compress animations, which is advisable, Unity is going to reduce pretty intelligently, but based on the input frame rate (so something like 24-60 fps). As such you have to do some tricks if you don't want certain details to get compressed out. In Touch KO, for example, the slow-mo facial deformation was animated at a slower speed in Maya and then the animation states in Unity just had their speed increased to be lined up with the global time settings there.

4. None of this affects how you set frame ranges for cutting up your file into animation clips in your import settings, contrary to what Hanultech posted. Just use the actual frame numbers in your FBX file (or use the one-animation-per-file approach with the @ naming convention, which I advise for a plethora of other reasons).

So there is my long explanation. In practice, however, I have found that as long as I am using keyframe reduction, there is not much performance or memory overhead from animation data itself. All of the animations in Touch KO were motion captured, but reduced very well. Performance will tend to be impacted more by some of the factors Hanultech mentioned, including number of bones per character, number of characters on screen, skin quality of characters, number of vertices per character, and so on. However, a high-poly character is still going to slow you down, whether or not his animations are more complex, as this is a graphics issue, not an animation issue. Memory is going to be more impacted by things like large textures, sound files, etc.

You can change the number of influences per vertex on the Unity side, so don't bother re-skinning in Maya if you want it lower. The Auto setting in the Skinned Mesh Renderer is not tied to how you skinned in Maya or Max, but rather to your global quality settings in Unity.

 

Thanks a lot.. it's a whole new work flow for me and this really helps.

 

In addition to the great information Adam provides, I just wanted to note that from a practical standpoint, a lot developers purchase 3D models, and that in addition to the model files, they normally come with documentation on the animations that looks something like this:

Frames 0 - 50: Walking no gun.
Frames 51 - 52: Walking with gun.
etc.

When the models are imported into Unity, the animation sequences will often show up as one monolithic animation, and this requires that that it be split apart into individual clips which can be programmatically played, cross-faded, etc.

A common problem is that if the animations were not recorded and exported at 30FPS, the clips that are created in the import settings based on the frame documentation won't line up. (Took a while to figure that one out first time I ran into it.) This can be fixed by re-recording the animation at 30FPS in the animation tool and re-exporting it. I am not aware of a way in Unity to address this issue. Doesn't mean there isn't one, but I wasn't able to find it.

 

I don't understand why keyframe reduction is an issue. Isn't it better to have more keyframes? It will take more memory, but then the CPU won't need to work as hard at interpolation. All that the keyframes are is storage of the bone transforms.

 

More or less keyframes on the same animation curve has no effect on cpu load - Unity is just sampling that curve over time, having more keys doesn't make that process any easier, as the current frame at any given time is always between keys, never precisely on them. The complexity of that curve will effect memory usage, but nothing else. CPU strain comes into the equation when you have a lot of curves being evaluated at once.

So in short...

More moving parts = CPU
More keys/longer clips = memory

In the vast scheme of things, I find that the memory consumption of animation is almost meaningless compared to what textures and sounds represent. Making shorter animation files to save on memory is like cleaning your ashtray so you can make more space for luggage in your car. It's not worth sacrificing animation quality over it.

As for framerates, Unity doesn't really think in terms of frames, like most realtime 3D engines it is strictly a time-based environment, so you can animate at whatever framerate you wish. If you animate a 24 frame cycle in maya at 24fps, it will be one second long in unity. Same for a 30 frame cycle at 30fps. The fact is that your game will probably have a vary inconsistent framerate, fluctuating at least a little bit at all times, so your animation is never really playing back at the framerate you animated it. Even if your game is perfectly optimized and renders at nearly a solid 30fps, its more like 29.89 or 30.02 at any given instant, and your animations are never being rendered exactly as your maya frames were.

 

Don't disagree. But if your utilizing a third party model and relying on the frame documentation, that documentation was written based on a specific frame rate. If the model was exported at other than 30FPS, creating clips upon import based on the documentation will be wrong, unless there is a way in Unity to specify a sampling rate of other than 30FPS. So, then you have two choices: Change the sampling rate to 30 in the animation tool and re-export the model, or run the model in the tool and determine alternative frame points from which to construct your clips.

Based on the thousands of posts regarding problems importing models, I would venture to guess that most developers are relying on someone else to create their animated models. Granted the problem is nowhere near as pervasive as lost UV mappings, but people still seem to get tripped up by this. I only know enough Maya to get in trouble, and ran smack into this problem the first time I tried to incorporate a third party model.

 

Shouldn't be a problem if you can get your animator to give you clips instead of a big timeline. I have no clue how any other tools work, but we've been creating actions in Blender, which translate fine into Unity "clips".

 

i haven't tried exporting just animation clips yet but i imagine that it is possible. Or not?

thanks again its been a lot of help.

 

Maybe my experience thus far has been unusual, but the third party Maya models I have used have all been setup with with one long continuos animation and documentation on the frame sets for different clips. Not being a animation artist by any stretch of the imagination, I have no clue whether this is standard practice. Being an engineer, however, it seems to make sense. Should "walk with no gun" and "wave hi" be two separate clips, or one? I would say it depends. By modeling the animation in one long clip, you allow the developer to create whatever individual clips they desire.

Anyway, either way it is trivial to fix, I have to admit the first time I ran into the problem, I was pretty stumped. I yelled at the artist telling him his documentation was wrong. He politely responds by asking what rate Unity was sampling at, and I said...uhmm... :roll:

 

I don't think you understand. The Blender actions I was talking about are just like Unity clips. They do occur in the same frames, but they're not combined unless you tell them to be, using the Non-Linear Animation editor. Unity provides a nice utility for splitting clips that exist together on a long timeline, but it's not necessary to do that.

 

Oh, I get it. I actually haven't messed with Maya to know if you can do equivalently, but I'll do some exploration when I have time. I would imagine that you can. Funny, I started learning Blender and then decided to plunk down something like $2,800 for Maya, only to find learning that to be equivalently challenging. I do like what of Maya I have actually gotten my mind around. Now if I could just do something about that whole lack of artistic talent thing....