Large particles and fillrate limitations

Sage
Posts: 1,199
Joined: 2004.10
Post: #1
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:

[Image: Clouds.png]

(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 Wink

Any ideas?
Quote this message in a reply
Moderator
Posts: 916
Joined: 2002.10
Post: #2
what card are you testing on?
how are you drawing these particles? (vertex array, displaylist, immediate mode)
Quote this message in a reply
Sage
Posts: 1,199
Joined: 2004.10
Post: #3
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.
Quote this message in a reply
Sage
Posts: 1,232
Joined: 2002.10
Post: #4
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.)
Quote this message in a reply
Sage
Posts: 1,199
Joined: 2004.10
Post: #5
For clarity, when I say 100x100 or 300x300 what I mean is in screen coordinates, after projection.
Quote this message in a reply
Sage
Posts: 1,199
Joined: 2004.10
Post: #6
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.
Quote this message in a reply
Sage
Posts: 1,232
Joined: 2002.10
Post: #7
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)
Quote this message in a reply
Sage
Posts: 1,199
Joined: 2004.10
Post: #8
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.
Quote this message in a reply
Sage
Posts: 1,199
Joined: 2004.10
Post: #9
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.
Quote this message in a reply
DoG
Moderator
Posts: 869
Joined: 2003.01
Post: #10
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.
Quote this message in a reply
Moderator
Posts: 916
Joined: 2002.10
Post: #11
a suggestion, try using a non textured quad. If you get better performance, consider using colored primitives for your particles.
Quote this message in a reply
Sage
Posts: 1,199
Joined: 2004.10
Post: #12
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.
Quote this message in a reply
Moderator
Posts: 916
Joined: 2002.10
Post: #13
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.
Quote this message in a reply
Sage
Posts: 1,232
Joined: 2002.10
Post: #14
Texturing is practically free compared to blending, especially if he's only using one small alpha texture on one texture unit.
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  Audio limitations for Phones trurkowski 3 3,907 Sep 25, 2012 03:17 PM
Last Post: trurkowski
  Consistent "look" between small and large objects WhatMeWorry 1 2,544 Oct 10, 2005 12:26 AM
Last Post: Fenris
  Large Texture Images Nick 1 2,990 Feb 15, 2005 08:18 PM
Last Post: OneSadCookie
  Turn a Quad into particles MACnus 10 6,623 Feb 6, 2005 09:10 AM
Last Post: Duane
  Display massively large image data Feanor 13 5,037 Jun 26, 2003 08:26 PM
Last Post: kelvin