- Bearbeitet
Unity Mecanim Import - Memory Overhead
Hey Guys,
Have been upgrading our project to use the new mecanim export target. Things are looking pretty good!
https://www.dropbox.com/s/07zfcnhljmhoaw5/Screenshot%202015-06-15%2017.28.15.png?dl=0
However, its looking like the exported animation clips are very large, much larger than the SkeletonRenderer runtime, and too large for it to be an appropriate solution for mobile I think
https://www.dropbox.com/s/qlvbpgdi535w1eg/Screenshot%202015-06-15%2017.32.31.png?dl=0
In googling around - I noticed that this has been a problem with Unity mecanim in general and seems to be mostly mitigated by reducing and compressing the keyframe data.
However, this appears to ONLY be a code path thats available when using their FBX importer - e.g. you cannot invoke the compression/reduction post facto on an AnimationClip.
I looked around but couldn't really find a 3p solution here - does it make sense to build an FBX exporter out of spine? It seems based on your guys latest posts you've been shifting more focus towards the SkeletonRenderer rather than Mecanim.
Also - it would appear there's a bug in the mecanim parser thats producing keyframe data for rotation timelines. Thats likely causing the bulk of the issue
In unity:
https://www.dropbox.com/s/f3zrv7kmznmayoh/Screenshot%202015-06-15%2018.00.54.png?dl=0
In spine:
https://www.dropbox.com/s/dxhhcco32gdcukx/Screenshot%202015-06-15%2018.01.45.png?dl=0
what you call "Mecanim" is actually called "Baked" because it removes Spine from the equation. There is another mecanim workflow that uses SkeletonAnimator (as opposed to Animation) similar to Unity's Animator/Animation. This also uses Mecanim and does not have the overhead. The Baking functions are really only used for when you absolutely can't have the Spine runtime (IE: selling on Asset Store) or have some stupid simple rig that you dont really want to animate using ragdoll or some wind/noise generator or something.
The high density of keyframes are not a glitch, Spine's graph curves are not equivalent to Unity's graph curves so a sampling/baking process is needed to make them match. you are welcome to decrease the baking increment to save on keyframes and sacrifice some accuracy.
see SkeletonBaker.cs
/// <summary>
/// Interval between key sampling for Bezier curves, IK controlled bones, and Inherit Rotation effected bones.
/// </summary>
const float bakeIncrement = 1 / 60f;
Right at the top.
Awesome - thanks for clarifying Mitch, and sorry for the confusion
Definitely see the memory pressure go away with the instantiate-as-mecanim option, but also seeing some of the performance gains from using baked mecanim go with them - which I think makes sense since we're now relying on spine's runtime to actually do the animation instead of the "rasterized" animation clips.
Am I right that this is roughly the state of things for Unity rendering/import options? Just trying to get a feel for our options.
Spine Export Formats - 2 Options Available
JSON - Default export format. Readability/interoperability is nice, easy to integrate with. Wire size and processing speed may make this a less attractive choice for complex rigs or rigs with many skins or animations.
Binary - This trades a smaller wire size and faster parse speed for interoperability and is generally preferable for a rig of moderate or greater complexity.
Unity Rendering Options - 3 Options Available
SkeletonAnimation - This is the recommended rendering option for Spine in Unity and is the most mature target at this point.
Mecanim/SkeletonAnimator - This is for folks who require more advanced blending tools and state modeling than what Spine offers, The tradeoff is some amount of functionality. Since the Spine runtime is still actually powering the animations, this solution offers no greater performance than SkeletonAnimation and may indeed actually be slower in certain circumstances.
Mecanim with Baked Animations - This is targeted generally towards sharing and essentially "rasterizes" the animation. This creates an AnimationController and a series of Animation Clips that can run independently of the spine runtime. The result is a series of Animations that are generally largely in memory and wire size but are generally capable of running significantly faster. This means this MAY be an appropriate solution for a spine animation that is somewhat basic but will be instantiated many times - for instance a monster that may have 50-100 copies on screen at once
Good evaluation 
I'm going to get around to writing it up properly for docs at some point.
There is another option that hasn't been broached yet... and that involves rasterizing and serializing (or just doing it at runtime) the output meshes themselves at a fixed framerate. This would enable you to use all the Spine features as a baked mesh sequence rather than keyframes. It certainly sucks for certain things like parenting other objects to the skeleton, but it would let you jam a huge number of meshes into a scene with very little calculation overhead as all you'd be doing is swapping mesh info. I was planning on covering that pretty soon.