Re: render particle

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

-- 
Author: =?ISO-8859-2?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).