Hi Paul, I'm still open to suggestions on the make up of what your are looking, but I don't yet think you have the right design combination to avoid pitfalls of it's own. Though discussion perhaps we can arrive at a better solution, be it OSG intrusive or done externally.
On Fri, Dec 11, 2009 at 4:46 PM, Paul Martz <[email protected]> wrote: > I think I've already addressed the performance and maintenance concerns in > my first post. To recap, by default, OpenGL calls would go directly into > OpenGL. As for maintenance issues, I'd argue that we already have them, and > a system like I'm proposing would actually make it easier to add new OpenGL > features and extensions, as well as add them in a unified and consistent > way. Having a single class is not extensible by end users - something which is essential for authors of external NodeKits. Using an optional compile between macro's/inline functions and the modified versions to avoid performance degradation will lead to binary in-compatibility between the code with diagnostics and one without. If one did keep binary compatibility then use need to use a template method design pattern with an extra if (callback) callback(data..) else glFunction(data...) which while binary compatible will introduce a performance hit. -- I don't know if this might help, but Don Burns wrote a parser of the gl.h to automatically produce a wrapper library that allowed you that calls GL for you, and you just link to the Don's OglDump library. For more details: http://www.andesengineering.com/OglDump/ogldump.html It's written for unix, using lex/yacc, so one would need to do some more work to get it working under Windows, but it might give one a leg up. Cheers, Robert. _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
