Hi Robert -- You are totally right, and I came to the same conclusion as you after sleeping on it. There could be an OpenGL3x-based core library, just a thin wrapper around OpenGL3x with some base scene graph functionality, which sits under an OSG2x compatibility library, and use of the latter is completely optional, much as NodeKits are optional today.
I'd imagine that the OSG2x compatibility library might define some full-function shaders, and existing StateAttributes modified to create Uniforms consumed by those shaders. Anyone writing their own shaders would have the option of using OSG2x uniforms, their own uniforms, or some combination thereof. In the "break with compatibility" category, I thought about eliminating the Geometry and Drawable objects. Consider the following: Today, you attach a texture object to some StateSet, and the current texture is determined by OSG's rules of state inheritance. Now consider doing the same thing with buffer objects containing vertex attributes: If you could attach them to a StateSet and let them inherit like texture objects or any other state, Geodes would only need to contain PrimitiveSets, and the PrimitiveSets would simply sources from the current buffer object. Just stray thoughts, but these are some exciting possibilities, for certain. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466 -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Robert Osfield Sent: Sunday, February 22, 2009 3:57 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Fixed function pipeline -> GLSL shaders 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 _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
