Author Topic: UTIL: gDEBugger OpenGL Scene Analyzer (Windows/Mac/Linux)  (Read 320 times)

Legacy_OldTimeRadio

  • Hero Member
  • *****
  • Posts: 2307
  • Karma: +0/-0
UTIL: gDEBugger OpenGL Scene Analyzer (Windows/Mac/Linux)
« on: November 26, 2012, 10:06:22 pm »


               Here's a sweet little OpenGL scene analyzer called gDEBugger.  Performance counters allow you to examine game performance real-time or, if you prefer, step through individual OpenGL draw calls (for instance) to help identify whether a piece of custom content (game area/creature/tile/placeable/etc.) is problematic and/or whether it could be optimized.
'Posted

Setup:
On the first run after installing, a dialog box will pop up allowing you to request a free license.  Enter whatever information you like and click the Get Free License button.  You should receive confirmation that your license was installed successfully and then the Start dialog will pop up, allowing you to make a new project or view the sample project.  I recommend playing around with the sample (Teapot) project before going further.  It'll give you an idea what the program is capable of and also familiarize you with some of the controls.

Basic Usage (with the Teapot demo):
Once you select the teapot demo, you're going to see the main window of the debugger which will look something like the screenshot at the top of this post but without any data.  To launch the demo, press the Go button- the green 'play' button.  While the bar graphs for the performance counters show you real-time data about what's going on, certain inspections can take place only with the program paused, which you do by hitting the Break button- the dark gray 'pause' button.  You can resume where you left off by hitting the Go button again.  The program has great help features both in hover-help and the help file that comes with it.  The two toolbars you'll be using most are the Debug and Viewers.  They're both in the help file under "Toolbars".

Configuration and usage with NWMain:
Some of the debugger's reporting is based around knowing when a frame has completely been drawn so it keeps an eye out for what's called a Frame Terminator.  A frame terminator is just whatever OpenGL command is used by the program when a frame is done drawing, just before a new frame is to begin.  While a number of potential Frame Terminator commands are used by NWN to communicate with OpenGL, the most accurate I've found so far is SwapLayerBuffers.  I'll explain how to use this under the screenshot, but the screenshot below is from my NWMain project and shows what I think is the most accurate setup for testing:
'Posted

With the setup above, this is how you break NWN and step through the draw calls:
1. After having launched NWMain from the debugger, with NWN in windowed mode (and preferably with the HUD hidden by hitting the 'H' key), select the dDEBugger window.  NWN will automatically pause.
2. Click the dark gray Break button (the rest of the Debug toolbar buttons will become active)
3. Click the Frame Step button once.  This will bring you to the end of the frame)
4. Click the Single Step button twice.  This will get you passed a spurious glClear and into a totally blank frame.

That's it!  '<img'>

At this point you can watch the scene being built by repeatedly clicking the Draw Step button, go back into real-time analysis by clicking the Go button or dig around in the scene assets using the buttons on the Viewers toolbar.  If you wish to move frame by frame, just click the Frame Step button.

NOTE: If you want to identify the number of "Draw Calls" for a scene, it's the number of Draw Steps from blank screen until you're done drawing the frame.  You can identify the number of "Draw Calls" for a creature or tile or whatever just by counting the number of Draw Steps it takes to create them.

Adding Performance Counters:
When you first start debugging NWMain you're going to notice that only a few of the Performance Counters are actually doing anything.  This is because the default counters are measuring the wrong OpenGL Context.  They're measuring OGL Context 1 and you want counters which are measuring OpenGL Context 2.  All you need to do is double-click here and a window will come up, allowing you to remove the bunk counters and replace them with the ones you want.  gDEBugger also supports some other performance counters from NVidia and ATI, but adding and dealing with those is outside the scope of this post.

"Yay!  I'm doing it!  What the hell am I looking for, again?"
Good question!  The very best thing you can do to understand what you're looking for is simply taking a scene, queuing up a new frame using the steps above and then using the Draw Step button to watch it being built, object by object.  While each draw call (i.e. "Draw Step") may be composed of a number of OpenGL commands, it's the number of "draw calls" that you want to keep as low as possible "Draw Calls" = "Draw Steps" in gDEBugger.  "Draw Calls" are NOT OpenGL calls as listed in the OGL Calls/frame performance monitor.  For instance, while a frame might take 1,200 OpenGL calls to draw a frame, it may only take 42 draw calls ("Draw Steps") to do it.  Since you don't have access to the source code, you're up a creek as far as changing how many OpenGL commands are used to perform an operation unless you can achieve the same result using a different/more efficient modeling method.

Anyway, after Draw Stepping through a couple of scenes you should start to recognize that some things require a lot more draw calls than others.  For instance to put a beggar NPC on the screen, it requires 14 different draw calls, one for each body part.  However, to put a character on screen who's wearing a skin mesh robe, it only takes about 6: The individual body parts which are showing and a single draw call for the entire robe.

For tiles or placeables, meshes which use the same texture can be combined into a single mesh in G/Max and they will be put on the screen in a single draw call.  For instance, combining four trees on the same tile which use the same texture and Aurora Trimesh settings.

Speaking of textures, more efficiency can be attained by combining multiple textures into a Texture Atlas.  I posted a link to a texture atlas generator script (requires Max, IIRC) which will help you create a texture atlas for a number of different meshes in a scene.  The number of textures in a scene can be inspected with the Textures and Buffers viewer in gDEBugger once the program is Break-ed, from the Viewers toolbar buttons or CTRL-T

Whew!  '<img'>
               
               

               


                     Modifié par OldTimeRadio, 26 novembre 2012 - 10:08 .