My game has very low FPS when camera is watching many moving Actors. I was searching the forums and find RigidBodyCombiner as a possible solution with this demo: discourse.panda3d.org/viewtopic.php?t=7858
After trying to integrate this in my game and failing because I saw no improvements, I modified the demo mentioned above and loaded my model instead of the box model. But instead of getting better FPS at was even worse!
I thought it was my fault, that i messed up something with the model and tried the model used in Roaming Ralph. Was even worse.
On my model the analyze() delivers:
And I have also problems with Actors. Models work fine with RBC but if I use Actors they all are on position (0,0,0) and you are not possible to move them. Same with the Actor of the Roaming Ralph demo.
In fact I need a possibility to show at least 100 moving models which are not really modeled detailtly. RBC does not work, same for flattenStrong. Maybe I have done something wrong, hope I can get some help here.
You didn’t provide your hardware specs or measurement data but having played with using lots of actors myself, it’s quite possible you’re hitting a simple hardware limit (probably your CPU). RBC only helps with certain kinds of bottlenecks: it is essentially a tradeoff between using more CPU and less GPU. If your CPU is already the one being pushed too hard, it will only make things worse.
In astelix’s sample the sheer amount of nodes for rendering is too high for the GPU to munch so it caps at around 20fps for me. Enabling RBC removes the bottleneck from the GPU side and voila, I get over 60fps.
As for your problem, there is no simple solution. You can try searching for threads where this problem is discussed, but unfortunately you’ll probably only enocunter suggestions for using instancing.
Right, the “rigid” in RigidBodyCombiner is meant to imply that it should be used for rigid bodies only, not animated actors. RigidBodyCombiner will not work with animated actors.
If your vertex weighting is simple, and you are not using shaders, you might be able to offload some of the CPU cost of animation to the GPU, by adding:
hardware-animated-vertices 1
to your Config.prc file.
Beyond that, you have to get clever with your actors and your scene. For instance, if many of your actors are showing the same frame, you can using instancing to reduce the need to recompute the same animation needlessly.
First of all thanks for your fast help. Indeed animations are a big issue. I checked FPS with and without animations. I had a look at this instancing thing and got this idea about it:
I load for each animation one actor. Every former actor is now a nodepath. If I now want him to do animation 1 I instance him to the Actor which performs animation 1. But now I have the problem that I am not able to stop animation 1 and start animation 2.
Is there a possibility to delete this instance connection and set a new one? Or did I wrong with handling instancing?
Another thing is that FPS is also bad if I have no animations but lot of nodes in my view. But perhaps if I use the thing, I mentioned above I can use RBC because then I do not have longer Actors but NodePaths.
I’m confused. The RBC doesn’t work with instances either, but instances are only an optimization for animated models, which we’ve already established the RBC doesn’t work with.
To summarize: there are lots of different possible reasons that you might have performance issues with a given scene. One possibility is the amount of CPU it requires to compute animation. Another, completely unrelated, possibility is the number of individual Geoms that must be sent to the graphics card. There are other possibilities as well.
The RBC can be used to solve precisely one problem: too many individual Geoms being sent to the graphics card, due to a large number of individually-moving but other rigid models. If this reason is the sole reason for your performance issue, then the RBC can help.
If, on the other hand, your problem is the amount of CPU used to compute animation, because you have lots of objects that are computing the same animation redundantly, then you can use instancing to reduce this redundant computation. This is the only case in which instancing can be a performance advantage.
If you want to display many animated characters on the screen(with many i mean like 200+) and they are not unique looking you can do a hidden render of all the looping animations that can possibly be shown, lets say running, walking, flying, idling(in my case 4), so do 4x2 hidden renders of these characters looping the animations with an 1/2 offset, why 4x2 cause doing a single does not give enough variety, so whenever a model needs to play a specific animation you instance it from an existing loop animation, for example if i need to draw another running char i instance it from and existing hidden runner by choosing either the 1 or 2 runner to instance from.
So you will have 4x2=12 hidden animated chars all the time, but every single animated char you will add will cost a lot less due to instancing.
Of course if you have lets say 4 races 2 sex choices that’s 8 unique looking chars, so if they all have lets say 5 looping animations you will have a total of 8x5=40 animations if you do 2 hidden copies you’ll have 80 hidden animations, so this solution does not work well for and MMORPG. Yet it can work wonders for an RTS.
The 2 copies are optional if your eye can bear the syncronous movement you can do 1.
Well maybe it was not the most clear or on topic answer, 5 beers have their price.
@enc: you are absolutely right and i am working on that solution. it is RTS, should work good. lets see.
@drwr: sorry for confusion. when i has created the topic I thought animations was not the point because one of my team members has said, that he tried instancing and it hasn’t helped. after creating topic and you mentioned it again, I’ve seen animation is at least one point what can be improved because calculating 50 times same animation needs some cpu power.
so we need further improvements and I thought perhaps RBC can work with instances but in fact it can’t. Because it is the first time and I apparently don’t really know how it works yet, I excuse for confusion.
Conclusion: Seems we got 2 bottlenecks. Animations and lot of geoms. Animations should be solved with instancing the way enc proposed, geoms should be solved by using RBC somehow. But we can only use it on things that aren’t Actors. Unfortunately in our RTS most are Actors.
I loaded some Models, added them all to a node and then called rbc.collect(). Then I wanted to hide one of these nodes but then every node was hidden. Same if I show it again. I haven’t used any flatten function.
Is this normal and not possible to hide or show single nodes under a RBC node?
Correct. All you can do with the nodes under an RBC is to adjust their transform. Thus, you may be able to “hide” a node by setting its scale to 0 (or nearly 0), but you cannot explicitly hide() or show() it individually.
I have now loaded for every unit in my RTS and every animation one actor. Now is the thing, that the enemy player should have the same models but with different textures.
Is there any way to put on different textures but calculating same animation only once? Simple solution would be to load for every animation of every unit with one texture one actor. But this grows with big number of textures = enemies.
I know, I am hard to understand, so all in short again:
Same Actor with same animation but different Texture. How can I use instancing here?
I have now another problem with the RBC. I attached all my small models to a RBC-NodePath. If I now move with the camera too far away from the RBC-NodePath position the attached models were not displayed anymore.
I think this is normal behavior because the RBC-NodePath is not in view anymore so it will not be rendered and so the models attached to it. But not sure about that. Is there a way to force rendering of the RBC-NodePath if it is not hidden?
What I did with RBC: In a RTS-game the healthbars take much performance so I decided to solve this with RBC. These units are moving of course but if I use more RBCs or even move RBC I will loose performance improvements.
Hmm, I don’t know what you’re describing. There’s nothing about the RBC that should make objects within it disappear prematurely when you move the camera farther away. It’s possible to get this effect if you go out of your way with bounding volumes or such, but it should work correctly by default, so, I need more information.
Can you demonstrate with a bit of sample code precisely what’s going wrong?
