Hi,
we had some problems with a quite simple application rendering a series of GL_TRIANGLES. They all were called within one glBegin/glEnd block. glMaterial was used to change some properties. However, some triangles started to dissappear after changing the same glMaterial properties a second time within that glBegin/glEnd block.
The openGL spec says the following, so I am a little bit concerned about the correctness of the forceware drivers we used:
The material parameters can be updated at any time. In particular, glMaterial can be called between a call to glBegin and the corresponding call to glEnd. If only a single material parameter is to be changed per vertex, however, glColorMaterial is preferred over glMaterial (see glColorMaterial).
Did I understand something wrong here? Actually it doesn’t say anything about chaning the properties multiple times, but IMHO The material parameters can be updated at any time. means I can change it whenever I want…
If some triangles start to disappear that sounds like a driver bug.
The spec you cite is only right about the fixed function pipeline. glMaterial inside begin-end while shaders are active may not update the material until the glEnd. => Avoid glMaterial in begin-end, it’s evil.
You’re rendering independent triangles and say you have a lot of them. If the material change only affects whole triangles you better split the primitives and move the glMaterial calls outside the begin-end.
Other performance tips would be:
Do not use double typed OpenGL API entry points.
Avoid immediate mode alltogether.
Something like this should work and be faster
glMaterialf(GL_FRONT_AND_BACK, GL_SHININESS, 8.0f );
glBegin(GL_TRIANGLES);
glNormal3f( 0.0f, 0.0f, -1.0f );
glTexCoord2f( 0.531250f, 0.132813f );
glVertex3f( 8.45f, 2.545f, -3.955f );
.... a long list of normals, texcoords and vertices....
glEnd();
glMaterialf(GL_FRONT_AND_BACK, GL_SHININESS, 32.0f );
glBegin(GL_TRIANGLES);
glNormal3f( 0.0f, 1.0f, 0.0f );
glTexCoord2f( 0.03125f, 0.005859f );
glVertex3f( 8.45f, 2.1225f, -3.955f );
.... another long list of normals, texcoords and vertices....
glEnd();
Thanks for the reply. Actually we id what you suggested (move it outside glBegin/glEnd) and we already changed the code to Vertex Arrays now (much faster without any bugs! =).
So its just good to know that it seems to be a driver bug. We do NOT use any shaders for that code - so the spec should allow us to do it the way we did… Well maybe some NVIDIA guy reads this…
Well, reading your post doesn’t mean anyone will be able to reproduce this.
You need to provide at least informations about OS, graphics hardware, driver version(!) plus a reproducer application.
No repro, no fix.
ok, I used three different machines - two with Geforce Cards, one laptop with an old driver (don’t care about this) and a new PC with quite a new driver (AMD Athlon X2 4200, 2 GB Ram, Win XP Professional 32bit SP2, Forceware 169.21, Geforce 7900 GT) and we could reproduce the problem on both devices.
However, the third one was a quadro machine (Intel Core 2 Duo, 1.8 GHz, 2 GB Ram, Win XP Professional 32bit SP2, Forceware 169.47, Quadro FX1500) and here everything was working correctly.