RE: render particle

Hi Dave,
	Can you (or someone else) elaborate on this? If I pass a point size
into the vertex shader using a generic attribute when drawing POINT_SPRITES,
what is the best way to use this value to scale the resulting sprite? I was
thinking of using it to scale the texture coordinates in the pixel shader to
shrink the texture, but the problem is I can't grow the sprite beyond the
current value of POINT_SIZE. Is there some way to control the sprite size by
doing something in the vertex shader?

Thanks

Malcolm


-----Original Message-----
Astle
Sent: Tuesday, March 07, 2006 8:39 PM
To: Multiple recipients of list OPENGL-GAMEDEV-L

Other than distance-based attenuation, there isn't a way to change the 
point size within a single draw call in the fixed function pipeline*, 
but with a vertex shader, you can easily use one of the generic 
attributes to set an arbitrary per-point size value.

With a shader, you should be able to easily render a large number of 
particles in a single call.

(* - in desktop GL, anyway. OpenGL ES includes a fixed-function 
extension that does exactly this).

Dave Astle

-------------------------------------------------------------------------
Staff Engineer, ATI Research
Executive Producer, GameDev.net, LLC: http://www.gamedev.net/
Four-time author, Course Technology PTR
-------------------------------------------------------------------------

Balogh Péter wrote:
> My main concern is the state changes, if I have to use n sizes for the 
> system. Because what if I have 100 particles, all with different sizes. 
> As far as I know, I can't render 100 particles with different sizes 
> unless for every particle I call
> 
> glPointParameterfARB( GL_POINT_SIZE_MAX_ARB, fAdSize);
> glBegin(GL_POINTS);
> glColor4fv((float *)&ptmp->color);
> glVertex3fv((float *)&ptmp->pos);
> glEnd();
> 
> wich seems pretty expensive, considering the alternative that I could 
> precalculate the 100 particles to 400 vertices, while rendering huge 
> meshes(while the card is rendering), and after the meshes I simlpy 
> render the 400 vertices as a vertexarray.
> 
> Does the POINT_SPRITE method stalls the gpu? Is there a way, to batch 
> the different size/color attributes with positions, and render with a 
> small number of render calls like huge triangle meshes? I don't really 
> have bus or fillrate or cpu limitation yet (lack of final concept of 
> visual requirements). I'm trying to find and implement the overall 
> cheapest particle system for few 1000 particles.
> 
> All help appreciated!
> 
> Peter Balogh
> 
> Kent Quirk wrote:
> 
>> Andras has good advice.
>>
>> But if you're reluctant to use OpenGL sprites because you want to use 
>> OpenGL 1.1, then you could also consider rendering each particle as a 
>> single billboarded (always facing the camera) triangle.
>>
>> You can render them with alpha on and use a texture with a circular 
>> gradient (solid in the middle, transparent at the edges). If you use 
>> the "Flyweight" pattern you can treat all the particles in one as 
>> having common attributes and minimize state changes.
>>
>> It's old technology, but it's been proven in many games. And if your 
>> target is that low, you probably want to consider it.
>>
>>    Kent
>>
>>
>>
>>
>> Andras Balogh wrote:
>>
>>> First, you'll probably be limited by fillrate way before you'll be 
>>> limited  by vertex transforms. But even if not, next you'll be 
>>> limited by bus  bandwidth, and points need 4 times less bandwidth 
>>> than quads. Finally, the  only time you might want to micro-optimize 
>>> like this, is when you're  competing with johnc, but then you 
>>> probably wouldn't need our advice ;)
>>>
>>> Trust me, getting rid of camera transformation is not an 
>>> optimization.  There's so much more going on that this won't make the 
>>> slightest  difference! I'm sure you've heard this before: "Premature 
>>> optimization is  the root of all evil". Always go with the simplest 
>>> solution, and then  optimize the bottleneck. It makes no sense to 
>>> optimize something that is  not even the bottleneck! You'll end up 
>>> with more complicated, less  flexible and probably slower code.
>>>
>>> Of course, sprites have their problems, like HW dependent size limit 
>>> (most  cards max out at 64x64 pixels), but that's not a speed issue, 
>>> but a  feature issue.
>>>
>>>
>>> Andras
>>
>>
>>
>>
>> ----- FAQ and OpenGL Resources at:
>>  http://www.geocities.com/SiliconValley/Hills/9956/OpenGL
>>
> ----- FAQ and OpenGL Resources at:
>  http://www.geocities.com/SiliconValley/Hills/9956/OpenGL
> 


----- 
FAQ and OpenGL Resources at:
  http://www.geocities.com/SiliconValley/Hills/9956/OpenGL

-- 
Author: Dave Astle
  INET: [email protected]

Fat City Hosting, San Diego, California -- http://www.fatcity.com
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [email protected] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB OPENGL-GAMEDEV-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing)


----- 
FAQ and OpenGL Resources at:
  http://www.geocities.com/SiliconValley/Hills/9956/OpenGL

-- 
Author: Malcolm Bechard
  INET: [email protected]

Fat City Hosting, San Diego, California -- http://www.fatcity.com
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [email protected] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB OPENGL-GAMEDEV-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).