Re: render particle

You don't need to do anything like that in the fragment shader. In the 
vertex shader, you can write to a value (gl_pointSize in GLSL, 
result.pointsize in ARB_vertex_program) that sets the size of the point 
in pixels, up to whatever the implementation max is. You could just pass 
through the per-vertex attribute that you specified in the generic 
stream, or you could attenuate that value, or whatever.

Dave

Malcolm Bechard wrote:
> 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
> 

----- 
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).