I have 50 Ralph’s animated on screen, and this lowers fps dramatically. In PStats I noticed that two parts take lots of time: “/Animation/Ralph/Skinning" and "/Animation/Munge/Geom”. What does this mean, and how to optimize this stuff?
*:Animation:Ralph:Skinning is the time spent to animate Ralph’s vertices for each new frame. It will be linearly proportional to the number of animated vertices onscreen at any given time.
*:Munge:Geom is the time spent preparing vertices to be rendered. This means adapting it as needed to the requirements of the current GSG, e.g. converting DirectX color format to OpenGL color format, and so on. Normally, this operation is done once for each model and then cached, but if the model is animated the cache gets busted every frame. You may be able to eliminate the need to perform this munge by premunging Ralph:
ralph.premungeScene(base.win.getGsg())If you’re using animation blending–e.g. you have interpolate-frames 1 in your Config.prc–skinning may be more expensive than otherwise, so disable this if you can.
Another trick to reduce the cost of animation is to using instancing to replicate Ralph instead of copying him 50 times. Instancing means you only have to animate Ralph once. Of course, this only works as long as all of the Ralphs are in perfect synchronicity. If you have different Ralphs displaying different frames of animation at the same time, you might be clever and try to instance only those that happen to be synchronized.
Another effective trick is to use LOD’s. Surely you don’t need to use all of Ralph’s vertices for all 50 of those models–the ones that are far from the camera need only a fraction of the same number of vertices to look just as good. If you had the ability to generate multiple LOD’s for Ralph, you could get away with far fewer animated vertices for the same quality of image.
Of course, you’d have to make those LOD’s yourself, since Ralph doesn’t come with them.
David
if trying for a crowd effect, you can animate a few ralphs and instance them, and scatter them around randomly, and no one would be the wiser. you can also use imposters for some of them. google ‘imposters graphics’ for some resources on that.
i want to mention that imposter are very usefull for static geometry. it’s sorta the most-extrem level-of-detail you can reach when reducing details.
but its not very suited for animated geomtery since you would have to do texture-updates. which most likely would do more bad than good. althought i have not benchmarked the difference.
Thank you for the answers. In fact, I am making a sort of stress-test, with all these ralphs. I am making a crimsonland-like shooter, and I expected to have about 50 enemies on screen simultaneously.
Pity, premungeScene didn’t help even a little. Now I am playing with instancing.
Also, does the number of animations assigned to an actor have any effect on performance? I mean not necessarily currently playing animations. Is there difference between actors with 2 and with 20 animations?
as drwr said. reducing the number of vertices is a good choice.
ralph might not look like it but he has about 1900 vertices.
i guess it would be easy to create LOD models with half the resolution, still very good looking. for far away models you could even go down to 300 vertices. would make 6 times less cpu-calculations neccessary.
number of animations asigned should make almost no difference. i’m not a that knowledgable so please correct me if i’m wrong. but the cpu shouldnt be busy with anything except the animations which currently playing.
Also, PStats reports that I have around 432 TransformStates, 285 nodes, and 105 geoms. What could be considered as normal amount of them? Maybe, I should lower the amount of nodes/transforms/geoms? How do they affect performance?
BTW, LOD is not an option for me. I have top-down camera, and all actor are more or less equally close.
If you’re not going to allow the camera to zoom in so you’ll be playing from a fixed distance, that would probably help you a lot then with optimizing the detail of your model for performance!
Instancing really helps A LOT. From 11 fps it jumped to 170 fps. I will create a dozen of basic actors, and the rest will be their instances. When a different animation is required, I will substitute the instance with newly-created actor.
These are all very modest figures–nothing to raise any warning flags there.
Don’t you really mean all the actors are equally far? If you’ve got 50 actors onscreen at once, you aren’t seeing much detail for any of them. So you don’t need multiple LOD’s, but you don’t need 1900 vertices either. You just need one low-level model.
OK, that’s another answer too. 
David
toward the end of kingdom hearts 2 there’s a level with a TON of enemies, most of which are just bouncing sprites, but the effect is quite convincing. my wife didn’t notice until i pointed it out. there’s a lot you can achieve by faking it.
Sorry to drag up an old topic, but has anyone had any luck implementing this? If so, I’d be interested in seeing/hearing about sample scenarios and speed gains and of course, if possible, code 
I begun to implement it but later decided to postpone it: there was a number of difficulties.
Such instancing must be tightly integrated with AI (or into Actor class, but that was too deep for me). Normally you create an NPC class, where you define the model and its animations. If you want to instance many actors automatically, then it is better to define actor model and animation for certain AI states rather then for NPCs themselves. Of course, then you need to create separate AI for each NPC type. In other words, the system gets complicated. Maybe I will come back to this algorithm later, when AI for my game is fully implemented, and if I really need this…
At the end, the speed gain is moderate: the number of unique actors (i.e. not actors’ instances) in most cases is still high. I can only recommend using such system if you have many actors doing the same action at the same time (for example, a police squad shoulder to shoulder approaching the column of demonstrators 
).
That is the conclusion I came to myself, but since I’m not really a programmer I thought I was just missing some approach as usual. But thanks for the reply 