I guess there's really two different philosophical directions that OSG can take in the OpenGL3.x timeframe. Maybe there's more than two, but the two I can think of are as follows:
1) Backwards compatibility. Continue to support the existing OSG API to enable apps to transparently port to OpenGL 3.x. OSG emulates the fixed function pipe by creating Uniforms for state attributes and modes and supplying default shaders that use the Uniforms to reproduce the old OpenGL 2.x functionality. Note that option 1 doesn't preclude users from accessing the 3.x interface through their own uniforms and shaders. However, it retains the "conflict" that OpenGL 3.x resolves, namely, an API that appears to guarantee certain functionality, which breaks when the wrong shader is loaded. 2) Break with compatibility. Remove from the OSG API all state attributes or other OSG functionality that relies on the fixed function pipe. OSG becomes a spatial organizer and mechanism for loading user-defined uniforms and textures into user-defined shaders. Seems like both have pros and cons, which I don't have the time to enumerate this morning. Personally, I've been leaning towards option 2, which seems cleaner and more in spirit with OpenGL 3.x; the major downside, of course, is the immense porting effort inflicted on app developers who decide they can't stay on OSG/OpenGL 2.x. To which I would say a) that's their choice, as OSG/OpenGL 2.x will be available for years to come, and b) API ports have been done successfully in the past: Starbase PHIGS, PEX, etc., no one misses them. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466 _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
