Sign in to follow this  
fishleg003

A faster way to draw than...

Recommended Posts

fishleg003    122
Been trying to have a good crack at particle system for some time i did have one working with imediate mode but it was rather slow so i switched to the method below but im still wondering if i can get more speed from it some how... Basically ive got a giant array of points every 4 points being a quad and the information that goes with it which represents each particle on the screen. To be honest its not that much faster i can only get to around 6000 particles before i start to get slow down below 30 fps i would of expected alot more to be honest :(. For each emitter id do this to draw all its particles.
glEnableClientState(GL_TEXTURE_COORD_ARRAY);
ENABLE_TEXTURE(Home->Tex_data->id);

glVertexPointer(3, GL_FLOAT, sizeof(Particle_XYZRGBUV), &Points[0].XYZ);
glTexCoordPointer(2, GL_FLOAT, sizeof(Particle_XYZRGBUV), &Points[0].UV);
glNormalPointer(GL_FLOAT, sizeof(Particle_XYZRGBUV), &Points[0].N);
glColorPointer(4, GL_FLOAT, sizeof(Particle_XYZRGBUV), &Points[0].RGBA);

glDrawArrays( GL_QUADS, 0, curr * 4 );

DISABLE_TEXTURE();		
glDisableClientState(GL_TEXTURE_COORD_ARRAY);

So any speed tips mucho appreciated :). cheers fishy

Share this post


Link to post
Share on other sites
deavik    570
EDIT: Missed "particle system" in the OP's post, so the rest is quite useless.

If your card supports vertex buffer objects, you could port your existing vertex array code to use a VBO. Since VBO's are stored in Video Card memory, it should be must faster.

Another trick is ofcourse display lists. Very easy to set up, very fast and also a core feature since opengl 1.0 (or is it 1.1? -- anyway I'm pretty sure your implementation supports it [smile]).

[Edited by - deavik on March 15, 2006 10:23:36 AM]

Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
Quote:
Original post by deavik
If your card supports vertex buffer objects, you could port your existing vertex array code to use a VBO. Since VBO's are stored in Video Card memory, it should be must faster.

Another trick is ofcourse display lists. Very easy to set up, very fast and also a core feature since opengl 1.0 (or is it 1.1? -- anyway I'm pretty sure your implementation supports it [smile]).


I don't think VBOs will be of much help for a dynamic particle system. Aren't VBOs more for static geometry?

Also, lets say he made a display list for a particle quad. Wouldn't the glTranslate() calls required to position all those display lists offset the speed boost? How do you propose he use display lists?

One way to boost things fishleg, is to determine the optimum array size to send to the card at a given time. Sometimes sending and drawing 4 arrays @ 2000 elements is faster than sending one array @ 8000 elements. There is no "magic number"- it depends on the user's hardware. I've heard 2000 is a decent middle ground though.

Share this post


Link to post
Share on other sites
deavik    570
Oh yes, I completely overlooked "particle system". In that case, display lists will also not be any help. Sorry for causing the confusion.

Share this post


Link to post
Share on other sites
Kalidor    1087
This is assuming that you are billboarding each particle's quad inside some update function.

You may be able to get a speed gain by just sending the position of each particle in each of the four vertices per particle and then write a vertex shader that will offset each vertex in the correct direction based on its corresponding texture coordinate so that you do the billboarding on the GPU.

[EDIT]
What I mean by "sending the position of each particle in each of the four vertices" is this...
Let pi be the ith particle's position.
Your vertex array would then be [p0, p0, p0, p0, p1, p1, p1, p1, ..., pn, pn, pn, pn]
[/EDIT]

If your texture coordinates (or normals or colors) don't change you may get a speed boost from having just those in a VBO.

I think other than that it would be something else like the update function slowing you down. There's not much else to speed up on the rendering side here.

Oh, just noticed this... it may be better to call glVertexPointer last because I think most drivers do the heavy setup stuff in that function. This probably won't affect speed too much, if at all, however.

Share this post


Link to post
Share on other sites
fishleg003    122
Thx alot for the advice everyone.

Was not aware of the 2000 at a go be worth a shot :).

Ill move the vertex pointer to the end aswell.

The texture coords dont change that often at all neither do the normals so in theory if i made those two into buffers i could gain some speed off those ?


thx again
fishy.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this