Hi Paul, On Sun, Feb 22, 2009 at 8:38 PM, Paul Martz <[email protected]> wrote: > 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'm not sure about the totally right... once we've actually got code working and it works well could we say they we might be on the right track. That's part of the fun though... none of know how exactly things are going to pan out over the next five years, some stuff will work well, other approaches won't. > 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. I currently think of current OpenGL 2.x as modes enabling/disabling sets of shaders, and StateAttributes as setting of one or more uniforms associated with these shaders. The OSG's doesn't currently manage shaders like this though, osg::Uniforms and osg::Program sit completely orthogonal to the fixed function pipeline. One could hide GL3 shaders/unfirms within internally mapping between modes/StateAtttributes, and this might even be a first step - it's something that is relevant to GL2 as much as GL3 so one could even experiment with this in GL2. I think the next step would be to evolve the OSG's management of Modes and StateAttributes such that the mapping to enable/disabling shaders and setting of groups of uniforms is much more seamless. One might even get to the point where osg::Program/osg::Shader, osg::Uniform, osg::StateAttribute and osg::StateSet need to be revamped to fit with this more transparent mapping. Is such an API leap an OSG 3.x step though? > 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. Wow. I have in passing thought about the possibility of StateSets being able to define vertex attributes, but hadn't thought about it in the context of GL3 dev, and haven't thought about it for a long time, so long I had forgotten! One problem with decoupling the vertex definitions for PrimitiveSets would be that you wouldn't know how to compute the bounding volume of the leaves, one would only be able to compute the bounding box when the vertex data is attached. One could inherit the vertex data down to the leaves, but if you have two parental paths then the leaves could inherit two or more sets of vertex data. There is also the question about the coordinate system that vertices would be in, for instance what do you do is there is a transform below where the vertices are attached, but about the primitive leaves? Finally there is the issue of ensuring that the primitive sets have all the vertex data they require, a looser coupling would be that scene graph consistency would have to be more carefully managed. Inheriting other vertex attributes is somewhat easier though as there isn't the same bounding volume issue, but still does have a few potential pitfalls so if we do introduce this flexibility we'd need to be mindful of these pitfalls. Robert. > 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 > _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
