Advertisement Jump to content
Sign in to follow this  
Glass_Knife

OpenGL Debugging Graphics

This topic is 1762 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I am curious what you have in your bag of tricks for debugging 3d graphics.  I know it is a broad question, but I'm hoping there are some really good ideas out there floating around in the ether that I haven't stumbled upon yet.

 

I see this with beginners a lot.  Most of the problems in a beginning OpenGL class were students putting everything into the scene, and then nothing shows up.  To me, it is a "black screen of death".  Where is my model?  There aren't any errors, and no way to really figure out what's wrong.  But that feels like guessing, and debugging by guessing never works out.

 

For example, when I was writing a software renderer from scratch, I was trying to clip in homogeneous coordinates.  But I didn't really understand the math, so when I tried out the clip code I got an array index out of bound exception (this was in Java).  Well great.  I had no idea how to fix that.  I ended up setting up four views: top, left, front, and perspective, and then drawing the view frustum, hand clipping all the lines so nothing would crash.  Then I could see what was happening.  It ended up being a sign error in the near clipping plane.  It was easy to fix, but it took two weeks of side work to find it.

 

What do you do when you load up a scene and nothing is there?

Edited by Glass_Knife

Share this post


Link to post
Share on other sites
Advertisement

What do you do when you load up a scene and nothing is there?

I ask myself why I was stupid enough to have gotten that far without testing along the way. In brief, "Don't get in that situation." wink.png

 

Actually, I just go back to the last change I made (usually not more than one or two routines), undo it to make sure that's where the problem is, and debug from there. I have the luxury of relatively small apps that don't take long to compile. However, if you're going to spend more than an hour debugging something, a few minutes compile time is worth the effort.

 

 

 


array index out of bound exception (this was in Java). Well great. I had no idea how to fix that.

When you have an error as specific as that - you should be able to locate the line of code that's causing the problem. Admittedly, I'm unfamiliar with how one might debug java, but a good IDE will pinpoint things for you. In a specific case like that - look at the data coming in and determine if it's right or not. That, at a minimum, divides your code in half. Either the problem is before that line of code, or after.

Edited by Buckeye

Share this post


Link to post
Share on other sites


Now, thats kind of a bare-bones debugging experience. There are much better tools today -- like PIX, Visual Studio Graphics Diagnostics, and Valve's similar upcoming OpenGL tools -- that let you inspect the goings-on of the graphics pipeline in great detail by capturing all your draw commands together with all the data. For example, this topic is the same black-screen-of-death style problem, and the tools make it pretty straight forward to investigate and discover the problem.

 

I imagined that having some kind of tool would be necessary to really get in there and figure out what is going on.  In my example I wrote my own graphical debugging framework so I could play with the problem and figure out what was happening.  Maybe I just haven't put enough time into my code to add  debugging capabilities.  I can think of lots of things that could be done to inspect the pipeline and find problems.

Share this post


Link to post
Share on other sites

Obviously tools are great, if they work. Fixing the "where's my triangle?" problem can be hard no matter what, and I think that's a reflection on the complexity of the hardware and the API's.

 

Having a quick loop for recompiling shaders can be really nice for debugging, especially if you can hot-swap them while your program is running. It can make it very easy to quickly isolate problems without having to step through a debugger line by line.

Share this post


Link to post
Share on other sites

 

and debugging by guessing never works out.

It always works out. Beginning graphics is all about guessing

My biggest takeaway from when I started, was never program stuff without source control. Once you break something especially in graphics, it could take hours. Don't have people put everything into the scene. Create a box first, apply a texture second, put 1 more item, put another texture. Verifying each time that it works helps to know exactly what line is breaking it. Then its a matter of taking the breaking code and moving it around to see if it works in different areas.

Share this post


Link to post
Share on other sites

Don't forget the glValidateProgram function, call this right before you do the drawcalls and write away the output somewhere.
Useful for if your shader linked correctly, but doesn't produce expected output (eg. a black screen of doom).

Share this post


Link to post
Share on other sites

when i started development with cuda i discovered nvidia nsight, i've never used it for opengl debugging but it looks very promising :)

 

Share this post


Link to post
Share on other sites

AMD have CodeXL aswell, it's a visual studio addin, lets you debug your OpenGL states as though you are using the VS debugger(almost). Really helpful. Aside from that, I have a checkError function that if I create  a debug build (no optimisations) it will call glGetError and log the results with a timestamp and a little information about where it was called, what the state of the program at that point was. I sprinkle it liberally around problem errors, and run my app for a little while, and parse my logs after. I normally write it to a stringstream and on calling the destructor for the singleton I dump the stringstream to a file, formatted.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!