Hi Paul, I agree broadly on these two approaches, and rather than one or other them we might be best served by doing both. Option 1 is the easier for an OSG 2.x series to accommodate and could serve as testing ground for Option 2. Such an approach possible allow us to make it easier to migrate users from one approach to the other.
My current thought is see if we can make tweaks to OSG 2.x that change the API in small ways that enable exiting users to port easily from one version to the next and close the gap on the leap to a more API agnostitc scene graph, rather than an OpenGL 2.x centric scene graph. One step might be to rejig the granularity of StateAttribute's so that they have one mode per attribute for all attributes, rather the current situation of have on attribute wrap up mulitple modes (i.e. osg::TexGen / osg::Material). Another step would be to move all GL dependencies out for the headers, and keep it all in the implementation. Another step would be creating mapping between attributes and their shader + uniform counter parts, and provide a mechanism for composing this together in the rendering backend. Some of these steps needn't break existing API, and could be done in parallel to existing development. For instance adding GL3 context support into osgViewer should be possible now that the drivers are out, and this would give the ability to start experimenting. Robert. On Sat, Feb 21, 2009 at 4:06 PM, Paul Martz <[email protected]> wrote: > 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 > _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
