PDA

View Full Version : Best way to debug OpenGL 3.3+ issues



Kreed
09-04-2012, 11:21 AM
My question is what would be the best way to debug and possibly see what the issue is? Is there a way to see exactly what the MVP looks like in the shader? Is there a way to verify what vertices actually make their way into the shader? I tried using glGetError() each frame, but I am not getting anything returned. Also, I am a Linux user, so some of the debugging options aren't available to me.

As for a bit of elaboration, I have an application that has a vector of "Quad" objects that store the MVP and vertices for each quad. I have verified that all of my vertices and the MVP contain the correct data, but when they are passed to the shader, all I get is a black screen.

This simple shader and the code for the "quad" objects were tested in a smaller application, and worked flawlessly. Now that I merged it into a larger project, I don't get any output.

Thanks for the help.
-Kreed

Dark Photon
09-04-2012, 06:46 PM
You have lots of options. At the point you're about to draw the object, you can print out the MODELVIEW and PROJECTION you're feeding GL (or query it back from GL, if you're letting GL do the matrix math), and ensure it looks legit.

To help eliminate "rogue state" from being the culprit, disable depth/stencil/scissor/alpha tests and blend/fog/cull face/etc., and bind a simple shader that just multiplies by MVP in vtx and outputs a red color in fragment (i.e. only requires vtx positions to be legit). That plus glPolygonMode ( GL_FRONT_AND_BACK, GL_LINE ) can help you see exactly where your vertices are ending up, if they're landing in the view frustum at all.

With this, you should be able to reset MODELVIEW to the identity temporarily and wedge in an EYE-SPACE quad for testing that shows up on-screen (in frustum). Then gradually unwind the test shims until you don't see the quad anymore to determine what rogue state is messed up.

Alternatively, you can do some glGet* calls to query current state to try and figure out what's wrong. But I find it's simpler to get something working and then unwind it until it breaks -- whatever works best for yuo.