All

I've implemented a primitive particle system ( my first, actually ) which I've Sharked six ways to sunday and am confident is not hard on the CPU. It is, however, hard on the GPU for fill rate reasons. A screenshot will show you what I mean:



(The screenshot is of a moderate-bad case scenario)


So, basically, it's like a plasma burst from the ground when the laser shoots ground. Anyway, when the particles emit from a distance, I can have hundreds of them alive at once and have no measurable hit to framerate. But since the particles are governed by "wind", should they blow close to the camera there can be a HUGE hit, dropping my framerate from a capped 30fps to as little as 8 or 10. Bummer.

Now, I assume this is simply a matter of fillrate and blending. But, I'd like to know if any of the gurus here have tricks that can help speed up blending of large polys on screen.

My best guesses right now are:

1) Find a magic, faster, glBlendFunc param or something similar
2) Have some sort of logic which detects when the quads are too close to the camera and either pushes them away or simply doesn't draw them. I don't like the sound of that many sqrtf calls

Any ideas?

what card are you testing on?
how are you drawing these particles? (vertex array, displaylist, immediate mode)

I've got an NVIDIA 5200 FX Go in my wee powerbook.

Regarding the rendering style, I'm using immediate mode. After all, I set the texture only once, on the entry point, and then draw all the particles using that one texture.

Like I mentioned above, when the particles are far away, or far enough that most are smaller than 100x100 on screen, there's no noticeable performance hit. And shark revealed that the particle dynamics are taking up less than 1.6% CPU time. It's when the particles are more than 100x100 or so ( perhaps 300x300 or bigger ) that the slowdowns occur.

Pretty much the only thing you can do is to turn on alpha testing, so that the completely transparent portions of your particle texture (i.e. corners) aren't blended. For a circle texture that will reduce fillrate cost by about 20% (1-pi*0.5*0.5).

Or just raise the bottom GPU requirement for your app (Radeon 7500->Radeon 9600 = 400% fillrate improvement.)

For clarity, when I say 100x100 or 300x300 what I mean is in screen coordinates, after projection.

Shucks. I'm already using alpha testing.

I guess my best bet is to simply limit the number of particles that can be emitted when the emission point is "close" to the camera. I've already got a limiting factor, so it shouldn't be too hard.

This won't help for when the wind blows particles back at the camera, though.

Maybe you could fade the alpha out when the particle's Z gets too close to the camera, and remove it completely at a Z that would cause it to become larger than 300x300 or so. Like fogging out distant terrain, in reverse.

I totally sympathize with your problem, though. The fillrate on current GPUs is just too low to draw massive amounts of alpha blended particles like I want (one two three four, about 50,000 particles each)

A further Sharking done just now reveals that with my code cleaned up my smoke particle system's code constituted an overwhelming 0.2% of overall CPU time. So ovbiously, if this is fixable, I've got to do it with GPU trickery.

That's AMAZING stuff, arekkusu!

I like your idea of blending out based on z. I'll give that a stab. It ought to be easy to calculate the critical distance.

Particle systems nowadays are mostly GPU-fillrate dependant. Bummer. If you come up with anything but blending out particles, let us know. With what I am doing, it is not really possible, but I also know that a huge chunk is spent drawing particles.

a suggestion, try using a non textured quad. If you get better performance, consider using colored primitives for your particles.

Well, the good news is that having the quads blend to zero alpha as they approach ( past a calculated threshold ) seems to solve the performance hit 90% of the time. I consider this good enough!

Regarding skyhawk's suggestion, wouldn't this look a lot worse? Or, to get similar appearance to using say N textured quads wouldn't you need say 5*N colored primitives? Wouldn't the overhead of managing quite a bit more outweigh the fillrate benefit?

I'm just asking -- this is the *first* particle system I've ever written, so my experience is limited to the book and web resources I read before I implemented mine.

TomorrowPlusX Wrote:Regarding skyhawk's suggestion, wouldn't this look a lot worse? Or, to get similar appearance to using say N textured quads wouldn't you need say 5*N colored primitives? Wouldn't the overhead of managing quite a bit more outweigh the fillrate benefit?

I'm just asking -- this is the *first* particle system I've ever written, so my experience is limited to the book and web resources I read before I implemented mine.

actually, depending, you might even need more than 5*N, but... colored primitives are pretty cheap compared to textured quads. Microbian: Fighter and Icarus both use display list of colored primitives to do particle effects with.

Texturing is practically free compared to blending, especially if he's only using one small alpha texture on one texture unit.