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?

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."

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.

In general, I would first recommend taking smaller steps towards the goal, and make little pass-fail test along the way or step through in the debugger and just see if things look right and act reasonable. Sometimes this is like baby steps -- for example, rather than loading a model from a file, I'd first hard-code a cube, because its easier to see that things are exactly as I think they are. Then I render that cube in the default location with no transformations (or maybe just pushed out along Z). Basically, you progress through the steps one at a time, doing the minimal thing to verify that it plays nice with what you've already done.

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.

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.

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.

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.