Might I suggest you simplify the actual rendering performed by your scenegraph? Is it one of those christmas trees, where you accumulate state and transforms during a traversal? That’s a very inflexible system in my opinion, and as you point out, a bugger to debug.
Originally posted by knackered:
Might I suggest you simplify the actual rendering performed by your scenegraph? Is it one of those christmas trees, where you accumulate state and transforms during a traversal? That’s a very inflexible system in my opinion, and as you point out, a bugger to debug.
Topic Drift Alert
One of the major optimizations for scenegraph systems is rendering out-of-order: traverse the graph, collect all nodes that use the same rendering state (usually modulo transforms), change the state once and render all the nodes. Add to that optimizations to remove redundant state changes, and you get a pretty complicated system to follow without a debugger. Especially bugs in the state change minimization are really hard to find, as they usually depend on rendering order, which can change for different viewpoints with objects being culled or reordered for transparency.
End Of Topic Drift Alert
I wouldn’t want to live without a GL debugger, even though right now there’s no good one for Linux. But given that gDEBugger and glIntercept are promising Linux versions for the next release I’m hopeful that will change soon. 
So you’re saying the removal of redundant state changes using a state management layer on top of opengl, which is common practice, suddenly makes you require an opengl debugger? Quite frankly, the opengl layer is the last place you should be trying to trap these things!
I suppose if you’re operating in an unlayered framework, with the application directly manipulating opengl state then gdebugger must be a godsend.
dirk, topic title = “gdebugger new version is out. we would like your feedback”.
If this ain’t feedback, I’m a monkey’s uncle. Feedback you should be grateful for, as you’re the one trying to sell a product on a specialist public forum, which isn’t exactly cricket y’know.
ive made something similar myself, which lets me track openglstates, seeing if what i believe them to be and what they actually are (from glget…() commands etc).
now i havent checked out gldebugger but ive seen glIntercept, what i want is, to take a opengl state snapshot (save to file) at a particular point of time in my code, to see if what i believe to be enabled and what is actually enabled, what the shader uniforms states are etc match up. my code does this but its good to have a second opinion, is this possible with either gldebugger or glintercept?
These constants should be replaced with their symbolic enumeration names.
ive got a list of these if anyone wants (GL/gl.h +glext.h ver23 plus i added gl2.0 defines recently)
might save someone some work
Originally posted by knackered:
So you’re saying the removal of redundant state changes using a state management layer on top of opengl, which is common practice, suddenly makes you require an opengl debugger? Quite frankly, the opengl layer is the last place you should be trying to trap these things!
I think I have to disagree here. I work on a pretty generic scenegraph system ( OpenSG ), that is used for many different applications, from visualizing gene expressions to displaying realistic car models. I usually need the debugger when one of my users sends me a problematic scene, where the typical symptom is a part of the scene changing attributes/flickering when viewed from different viewpoints. These models often contain thousands of objects with hundreds of different materials, and removing some of them makes the problem go away. These are not obvious cases where something fundamental goes wrong, but border cases where a combination of different things causes some unexpected result. In these situations it’s really useful being able to log the OpenGL stream for a good and a bad frame and diff the two to see what’s actually happening.
Yeah, it would be nice if it wasn’t necessary to go that low, but it’s comparable to being able to debug a core file after a segfault. Something unexpected happened, and you need to go to the lowest level to get more information about what’s actually happening beyond “The program crashed” or “The image is wrong” before you can start hypothesizing about and start fixing the cause. I wouldn’t want to work without a debugger, and that includes OpenGL. YMMV.
dirk, topic title = “gdebugger new version is out. we would like your feedback”.
If this ain’t feedback, I’m a monkey’s uncle. Feedback you should be grateful for, as you’re the one trying to sell a product on a specialist public forum, which isn’t exactly cricket y’know.
Sorry you got the impression I have any relation to gDEBugger, I don’t. I’m not part of Gremedy, I don’t even use gDEBugger because it doesn’t work on Linux (yet). My off-topic was related to talking about scenegraph-specific problems in a thread about gDEBugger feedback. We can move this to the High-Level APIs forum if you want to continue discussing it.
And, honestly, feedback along the lines of “I can’t think of a single time in the past where this would have been useful” is not really all that constructive to begin with.
Originally posted by zed:
… i havent checked out gldebugger but ive seen glIntercept, what i want is, to take a opengl state snapshot (save to file) at a particular point of time in my code … is this possible with either gldebugger or glintercept?"
Hi Zed
gDEBugger enables you to:
a. Save a snapshot of the entire OpenGL state machine to a file (File -> Save state variables).
b. Watch selected state variables values (OpenGL State Variables View).
The common usage is to break the application run at a place where things are OK, break it again when things are wrong, and compare the state machine values.
You can break the application run at a specific function call (example: when the application calls the OpenGL function that starts the draw of a primitive), or plant a glStringMarkerGREMEDY in your application, and mark it as a breakpoint.
The gDEBugger team
www.gremedy.com