Speeding up custom particle engine -> reducing draw calls

[Gorbstein]

Hi,

I decided to make my own particle engine for my game from scratch, since I wanted some unusual custom functionality. All works well except it is very slow.

My explosion effect uses 6 emitters which give a total of about 30 or so particles on-screen at the peak of the effect. Not many, yet at this point my app drops from about 180FPS to 30FPS. See FPS in titlebar:



Have ruled out the system code since it stays at 180fps if I just do node->setVisible(false) on all particles.

I think the problem is my amount of draw calls, since I'm using a scene node for each quad/particle. Yes, this is bad, but I'm not 100% familiar with the best way to do this in the irrlicht pipeline.

Since I have lots of independently moving quads with changing scale, rotation and material (colour+alpha) properties, what is the best way to render these in the irrlicht pipeline for performance?

D

[sudi]

Well i had the same problem but my particle engine is alot faster...

http://irrlicht.sourceforge.net/phpBB2/ ... p?p=244651

[pippy3]

I've read irrlicht has a lot of complexity issues when it comes to particle effect algorithms.

While it makes sense to write a new particle engine, why not simply patch irrlichts to your desire?

then you can release it and help everyone else.

[sudi]

I've read irrlicht has a lot of complexity issues when it comes to particle effect algorithms.

While it makes sense to write a new particle engine, why not simply patch irrlichts to your desire?

then you can release it and help everyone else.

well didn't i just do that?

[Gorbstein]

Sudi : how did you overcome the problem? Do you use scene-node per particle or another way of combining all independent particles into one scene-node / draw call?

How does irrlicht batch the particles together in its own particle engine?

I thought about writing a custom scenenode which sorts all quads added to it by texture to reduce texture switches, but I read that Irrlicht does this automatically anyway?

I can't use mesh batching because each quad has independent position/alpha/colour, or am I wrong here?

Part of the problem I'm sure is my crappy laptop which only has a Intel915GM (basically like a Geforce2) but other particle engines I've tried (such as SPARK or irrlicht's own) on the same hardware run at about 10k+ particles before slowing down, so I'm still doing something wrong.

Pippy : The reason I didn't want to patch Irrlicht's is that A) this is my very first game and I want to learn the insides, and B) I want to remain fairly engine independent. I've written the game engine so that most of the graphics calls are quite generic and at this moment I could easily plug it into OGRE or something else. I want to stay with Irrlicht though.

D

[sudi]

Well mine basicly works like the irrlicht node. particles are not scenenodes...which is really just a big waste of time. i batch particles of the same type of a particle node into one draw call. so basicly the explosion you see in my project announcment thread has 7 different effects and therefor 7 drawcalls. this could be reduced further and i will do that actually.
But yeah incase your goal isto use a working particle solution for irrlicht that supports what ya need maybe just using mine is a good idea.

[REDDemon]

you can update easily thousands of quads in real time and compute their coordinates(on the CPU) for make them looking to the screen or to something else and still get a Framerate of 300+.

Need only few meshbuffers for that. If you can iterate all the quads in a single loop there will be a great performance increase. Of course you lose the chance to attach them to a scene node.

If you want to attach them you have to get AbsolutePosition (wich is computed). and then add it to quads that belongs to that scene node.

Well you have also to compute particle modifiers (so color,position scaling) and that's can be a bit more long.

thousand of particles at 300+fps is better than 30 particles at <60 fps

[Gorbstein]

Thanks all. OK, I'm starting to see now.

I don't need the functionality of scene nodes, it just seemed a convenient way to get stuff on the screen easily. I don't even need culling - I do that myself anyway - and there aren't going to be many big explosions outside the player view anyway.

Sudi: I had a look at your code in CParticleDrawer and I see what you're doing.. using big vertex buffers to hold all particles in each effect and refreshing it with everything (colour, position, relevant indices) every frame?

This makes sense to me. I think will be able to abstract the Irrlicht part from my engine as well by writing my own VertexBuffer class which just expands to hold enough particles as needed and is refreshed every frame, then all sent to the card using one draw call.

I suppose using a single texture atlas I could do every particle in my engine in one draw call...



D

[bitplane]

I think the problem is my amount of draw calls, since I'm using a scene node for each quad/particle.

Why not use the particle system scene node? It doesn't batch across multiple nodes, but it will be a lot faster than using one per particle.

[sudi]

I think the problem is my amount of draw calls, since I'm using a scene node for each quad/particle.

Why not use the particle system scene node? It doesn't batch across multiple nodes, but it will be a lot faster than using one per particle.

bc the irrlicht particle scenenode only supports billboard particles....