PDA

View Full Version : weird behaviour (VP)



tellaman
06-11-2003, 08:51 AM
please help me out i just dont get it
i'm creating a display list made of triangles
then i display this compiled list applying a vertex program
i've noticed that if i define my list in this order: glColor4f,glNormal3f,glTexCoord2f,glVertex3f
i get high frame rates (say around 300 fps)
but if i swap texcoord with vertex, like this:
glColor4f,glNormal3f,glVertex3f,glTexCoord2f
i get extremely low fps (50 fps)
is it meant to be that way?

as usual thanks for any help you can provide

Bob
06-11-2003, 09:07 AM
With your first setup (texcoord before vertex), you have one color, normal and texcoord per vertex, and maybe the driver can optimize such setup by using a vertex array-like structure for your display list internally.

With your second setup (vertex before texcoord), the first vertex lacks a texture coordinate and there will be an extra texcoord without vertex, color and normal in the end. Such setup may not be possible using a vertex array setup as above, so maybe the driver is forced to use immediate commands internally aswell.

This is just a guess, I really have no idea.

matt_weird
06-11-2003, 09:50 AM
Originally posted by tellaman:
i've noticed that if i define my list in this order: glColor4f,glNormal3f,glTexCoord2f,glVertex3f
i get high frame rates (say around 300 fps)
but if i swap texcoord with vertex, like this:
glColor4f,glNormal3f,glVertex3f,glTexCoord2f
i get extremely low fps (50 fps)
is it meant to be that way?


well, i noticed, for example, when you're drawing some amount of polygons with the same color specified, you're getting a performance boost specifying that color every time for each polygon, and controversary, if you specify that color before the rendering that group of polygons, it slows down. Red Book says that this last one is more preferable, as it can lessen the function call overhead, and it seems as a very weighty argument. So i was freaked off when i got that kind of results.

Dunno how to explain this, but it seems more likely OpenGL can experience some difficulties with restoring those current parameters every time you're rendering something(in case you're not specifying it right in the glBegin/glEnd scope). Also assuming this, in case of your particular problem, it could depend on a rendering pipeline hierarchy, so maybe specifying those parameters in this order could help even more:

glVertex3f,glNormal3f,glColor4f,glTexCoord2f

Korval
06-11-2003, 10:04 AM
In immediate mode, glVertex* must come last. It species, not only the position, but the fact that the current set of vertex attribute state is complete and should be sent. If you do this:


glVertex3f,glNormal3f,glColor4f,glTexCoord2f


Then the normal, color, and texcoord for the first vertex come from whatever was last set there before. It doesn't do what you want.

As for whether or not you set each parameter each time... you probably ought to. It makes implementing it on graphics hardware that much easier, and therefore likely faster.

amerio
06-11-2003, 10:08 AM
Beware !
glNormal, glColor, glTexCoord specifies attributes for the NEXT glVertex call, so typically you will want to put glVertex by the end of your Begin/End.
You may also try to put your data in a vertex array, and then nest a DrawElement (or sibling) in your display list, instead of begin/ends.