Re: render particle
Dave Astle <dave <at> gamedev.net>
2006-03-08 05:59:24 GMT
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: dave <at> gamedev.net
Fat City Hosting, San Diego, California -- http://www.fatcity.com
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru <at> fatcity.com (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).
RSS Feed