Caveat/Contribute

OGLE was executed by a someone who does not really know graphics programming from his bellybutton, though he's learned a lot in the process. Please take the following discussion with a grain of salt, as it reflects the learning process.

He would love some help driving the project further, to overcome some of the problems mentioned on this page. If you are interested, please get in touch as described in the Feedback page.

Bugs

Vertex Normals
OGLE attempts to capture the normals for every vertex, but we suspect it may be doing it incorrectly (thus the CaptureNormals option defaults to False). See the post on the comp.graphics.api.opengl newsgroup for more info. Also, we have seen the occasional program crash while capturing normals while OGLE'ing.

Texture Coordinates
As of OGLE 0.3b, it is possible to capture texture coordinates (UV) for vertices that have them. This is enabled by the CaptureTextureCoords flag. This has tested to work accurately on some applications (World Of Warcraft) but on others it seems to misbehave, so it is disabled by default.

Vertex Buffer Objects
OGLE seems to have no problem with most programs that use Vertex Buffer Objects to optimize their use of OpenGL, but on some it generates a messy jumble of polygons. As a workaround, you can try disabling OpenGL Vertex Buffer Objects as described in the FAQ.

Limitations

OGLE actually does what it is supposed to do for a relatively broad class of OpenGL applications. Specifically, it captures 3D geomtries accurately as long as the application does not use vertex programs to position vertices/polygons.

Vertex Programs
Captures from applications that do use vertex programs for positioning may find lots and lots of objects all on top of each other at the origin of the 3D model. Vertex programs are an OpenGL extension which, for performance optimization reasons, allows for offloading some custom processing steps to the graphics card using a custom programming language. Thus, it might be impossible to capture the final positions of these vertices without interpreting the vertex programs, which we felt was slightly beyond the scope of a 0.1 beta release!

However, some applications do work without Vertex Programs if your version of OpenGL doesn't support them, and GLIntercept comes with a plugin that will simulate a lack of Vertex Program functionality (see the FAQ for more information about how to do this).

Texture Maps/Colors/Lighting
OGLE does not capture texture maps, color, or lighting information. Geometries that it outputs are bland and flat, but ready to be spiced up in your favorite 3D modelling/animation software. It does, however, optionally capture the texture coordinates.

Display Lists
OGLE does not accurately capture data that is drawn using display lists. This should not be too hard to add, but has been skipped for now because they are a somewhat dated concept.

3D Printing
So far, none of the data captured from any application has been clean and well-formed enough to go right into our 3D printer. We have, however, acheived meatspace with manual cleanup of some models.

ToDo

The primary ToDo for OGLE is understand and implement the rest of OpenGL. We say that because, in effect, OGLE is a reverse-engineering of OpenGL's logic up through the ModelView transformation process.

More specifically, we need to:

• Implement capture for texture maps. This should be relatively straightforward, it just requires a bunch more coding.
• Same for lighting and color information
• Implement Vertex Programs (see the 'Vertex Programs' discussion above) so as to capture data from applications that use Vertex Programs to position vertices. One approach might be to leverage code from the Mesa3D library, as discussed on their mailing list.

Again, if you are interested in helping with any of these ToDo's, please get in touch as described in the Feedback page.