koobas.hobune.stream
Animation.RebuildInternalState spike
Hey guys, I keep getting CPU spikes which I've tracked in the profiler to Animation.RebuildInternalState. What can be done about this?
UPDATE: I was just at Unite 11, and I asked the Unity developers there. They said that it's a known issue, and it gets called on enable or disable of the animation component (or the object). They recommended pooling your objects, rather than instantiating them in-game, and leaving them in an active, offscreen state. With this and a few other improvements, I got my game from 35fps to ~55.
Hope it helps!
@sandworm can you expand on your work-around - we have a similar issue with DrawVBO and CullAllTerrains spiking, despite otherwise smooth performance and no GC we can detect happening at that time?
We have a LOD system for our skinned meshes (NPCs) that shows the nearest skinned meshes up to a certain number 5 at present and then drops to a non-skinned mesh that bobs about - a low lod in fact of the skinned mesh. This was working really well, but in profiling our game we've found that we get this spike in Animation.RebuildInternalState().
Our LOD system disables the animation on the skinned mesh so that it doesn't run while the mesh is hidden (maybe I don't need to do this, I will check), so I tried moving the objects behind the camera, but we had probably the same level of spiking if not worse, so setting an animation active may cause this function to run and spike, but moving the animation off screen does NOT fix it for me.
We're running on iOS and on a 3G S this spike can be as big as 200$$anonymous$$S - it's putting 3G S as lowest spec hardware under threat tbh. :o(
I am having the same problem with Animation.RebuildInternalState too. I have it take up 13% of the time and 5ms of time. I don't know what keeps calling it? Any ideas.
I was just checking this out over lunch - if I don't disable the animation component and I do disable the skinned mesh renderer, then it looks like my spikes have gone away with two caveats: I've not tested this on the 3G S I was using yesterday; on the 4S I did see a massive ~300MS spike in RebuildInternalState() very early on in the level (i.e. within the first few seconds) but that seemed to be the only one, probably just as a whole bunch of animations hit the camera frustum for the first time.
So my suggested solution - the one we are now using - is to set the skinned mesh renderer enabled to false and not both disabling the animation or moving either object off screen. Of course a solution that moved the object offscreen and disabled the Renderer may prove even more efficient...
I don't have a solution tested yet for the huge spike I received, but perhaps I can align the animations in front the camera for a second with all lights off/texture occluding them and then move them back to their proper positions. Feels like a bit of a hack though...
It looks like the moment a (skinned) animation is considered by the game it will RebuildInternalState(), so while my solution is sound enough, whenever a skinned mesh is going to be rendered for the first time there will be a spike. Our LOD system runs smoothly on a 4S with 60 mobs being considered and simply disabling the skinned renderer.
On the 3G S I am testing with 60 is too many but 30 seems to be acceptable. Both suffer a lot of stuttering early on (first 5-10 seconds) but this test level is completely open and the 60 mobs are tightly packed, in something like two phalanx, so it's probably an artificial grouping. Still I would rather this be called before the game renders a frame even and the player wait longer before the level starts, maybe a second or two all told.
I am thinking of ways to force it to happen, starting with seeing if I can call the method, perhaps by reflection even?
The slightly hacky approach of spawning all the NPCs in front of the player, behind the loading screen, waiting a few frames (okay a second AT$$anonymous$$) and then shifting them back to their spawn location, seems to eli$$anonymous$$ate any visible spike from RebuildInternalState() on my iPhone 4S.
I will check on the 3G S which was struggling more, when I can acquire it - $$anonymous$$rs Bovine is in bed and she is the keeper of said device ;o)
I too was getting this problem. After a LOT of experimentation, I have understood it to have something to do with "attaching unnecessary animations". What I mean by that is that I used to attach all animations used by different AI types in the same prefab and changed their material at runtime and defining their type by code.
Just for the sake of trying I segregated the different AI types into their own prefabs and minimized loading of unnecessary animations. I was relieved to see that this helped; substantially.
I don't know if this is the right solution, but I am no longer getting that CPU spike on Animation.RebuildInternalState.
