Re: render particle

You can`t rotate point, in vertex shader or fragment shader.


Wov Great!  :)  And what about rotation? :))

Peter Balogh

Dave Astle wrote:
> 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
> 
----- 
FAQ and OpenGL Resources at:
  http://www.geocities.com/SiliconValley/Hills/9956/OpenGL

-- 
Author: =?ISO-8859-1?Q?Balogh_P=E9ter?=
  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).


<--------------------===================================-------------------->
           DELFI mail pašto sistema http://www.mail.lt
----- 
FAQ and OpenGL Resources at:
  http://www.geocities.com/SiliconValley/Hills/9956/OpenGL

-- 
Author: Frail
  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).