I am debugging a rendering issue and could use some help. Please view the
attached images to see the error. The problem is intermittent but always
fails when the application starts and it never goes away. The platform is a
quadro 1400 fx driving twin 1600x1200 panels under Linux on an x86_64
system. Any ideas on how I might proceed to debug this would be
appreciated.
If I compile the application 32-bit or with debugging enabled, it never
fails.
You might check if you are forgetting to set some variable to zero when you initialize it. In debug-mode the compiler usually does this for you, but not in release (or equivalent).
Otherwise it’s a quite hard to tell what’s wrong… something with textures?
You use OpenGL lighting and make these buttons of polygons, not textures, right? Looks like it’s related to specular lighting / shininess. Could also be unnormalized normal vectors.
You also mentioned it works fine after 32-bit compilation. Perhaps it’s data alignment on data passed to gl…v() then.
Yes, the buttons are made of polygons and the text is a transparent texture. The rim of the magnifying glass does not use textures. The red cross-hair it not lit which may explain why the problem is related to lighting.
The program also uses a vertex/fragment shader which may be leaving the pipeline in a bad state after the shader is disabled. I will disable the shader from the beginning and see what happens.
Just want to clarify something: You using lighting for the buttons, right? So the buttons are not just textures quads, the actually have the geometrical shape that is “percieved” with the shading? I.e. the high-lights in top right corners caused by lighting, not texturing?
Are you using some kind of distance attenuation for your lighting? It seems you might be flooding your scene a bit. What leads me to think this is that the yellow frame for the “magnifier” is purely polygons and seems “over-lit” in the bug-image.
OK, so I forgot to mention that we use Intel’s Linux compilers. If I switch to gcc, the problem goes away. Has anyone else experienced OpenGL issues with Intel’s Linux compilers?
Just in case anyone runs into a similar problem. We found some uninitialized float variables in a class that caused nan’s to be passed into glFloatfv(GL_LIGHT0, GL_SPECULAR, color)