Hi Paul, On 8/14/07, Paul Martz <[EMAIL PROTECTED]> wrote: > I agree, with much of the current OSG dedicated to managing a fixed function > pipeline, starting from a clean slate would be the way to go. I'd hate to > see the OSG community try to maintain the existing API given its such a poor > fit for OpenGL 3.
OSG is designed around the concept of OpenGL modes and attributes, but the coupling is done rather loosely - the fixed function StateAttribute are all optional already, the new state management in GL3 would for the most part just replace the current fixed functions, the general architecture would actually be very similar to what we have right now. osg::Geometry itself would just need a different backend the public interface wouldn't need to be hugely different. The backend will also probably be able to able to accommodate GL3, and high level libs like osgViewer would just need to have different GraphicsWindow implementations written to handle the new means for setting up graphics contexts. The scene graph itself could probably cope with support GL3 without so many radical changes to render it a fundamentally different scene graph. One area that would need to see quite a bit of attention would be the loaders, and perhaps this would be among the most significant chunks of work, as all the loaders assume the fixed function pipeline exists. Could one convert function function objects to shaders and uniforms? Could one hide the fixed function classes without the old StateAttributes and provide a mechanism for setting associated uniforms and shaders? Almost have the OSG code base is loaders so this is no small issue. > As Robert points out, this will be hard for existing OSG (and OpenGL) users. > But these users are the ones who will ultimately decide when the move takes > place. OpenGL 2 drivers should be available for a while, but eventually > there will be an ISV shift towards OpenGL 3, and soon thereafter OpenGL 2 > drivers will disappear. (This will not be unlike the PEX/PHIGS/GL shift to > OpenGL 1.x in the mid-1990s.) Reading the presentations I didn't read anything of the original proposal to provide a backwards compatibility layer for GL2.x on top of GL3. Is this proposal now dropped? Now... if we could only get them to open source the existing OGL2.x drivers then they could live on for as long as they are needed. Did the vendors give any hint as the timeline they expect? Will 2.x still be supported in 5 years? I can imagine that a large number of apps would still not be ported by then. > My main concern with moving forward with a new clean slate is that we need > to see ISV support for that BEFORE the OpenGL 2 drivers go away, so that > there is sufficient time and funding to develop a new OSG that integrates > with OpenGL 3. There will be little movement in OSG towards OpenGL 3 without > funding to back that effort. I believe we can use the existing OSG-2.x series to prototype GL3 support, adding support for NVidia already published extensions is a first step. We could also experiment of how to migrate loaders across to use shaders rather than fixed function pipeline. This type of work needn't be a wholesale ground up block of work, rather biting of little bits as we go along. For a clean slate scene graph I think that we'd need to encompass more goals than just support GL3, as the hardware abstraction layer is just one element of evolving technology. Multi-core CPU/GPU combinations, other language support (Java, Python etc), and mobile graphics are all technologies that we need to embrace to provide an API that really tackles needs of future graphics applications. As a note of funding, would Khronous be able to fund an effort to write a well documented scene graph API ontop of GL3? Use it as a foundation of a new OpenGL SDK? Robert. _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
