Good to know.
BTW, with moving sprites I got 3000 nodes at 30 FPS. I am sure that is caused by slow Python for-loops, so I need to test it with C++ as well.
EDIT: With C++ I got ~27 FPS with 6000 moving nodes. Almost 2 times better than Python. I’m a little disappointed, it seems that it’s not the Python for loops that is slowing it, it’s just the setPos operations are too heavy.
You can quite a few more sprites. Here’s I think around 8k sprites running at ~200fps on hardware that sucked back in 2016 and it’s running physics and collisions for all of them at the same time. I remember cranking it up to a million particles and it still run above 30fps.
Cool demo. Looks like a hailstorm. Thanks, I’ll try it.
Though I was aiming to display as many full-blown PANDA NODES with two textured triangles, not just sprites. I’ve already seen that we can render several thousand point sprites under one single node. (About 20K sprites for my Xeon E3, GeForce 1050).
You cannot do that efficiently because each panda node requires a separate graphics batch. They need to be combined into one node at some stage (which is what RigidBodyCombiner does).
The only way I could see that work is if we created a special kind of SpriteNode that didn’t itself render any geometry, but instead represented a handle to some subset of some Geom that holds all the sprites.
I see. Well, I guess this is the downside of scenegraph-based renderers.
Thanks for taking your time replying to forum posts!
For the record, we do actually have plans for a renderer that can automatically batch multiple nodes into the same graphics batch, but it’s a very complex endeavour that will probably take some time before this can be implemented.