Hi Bruce,
The phrase gets thrown around a lot, and there seems to be an assumption that everyone knows exactly what it means in this context. I'm new, I don't, and searching doesn't seem to solve the problem.
You're right, when we talk about shader composition it's what we're labeling our attempts to find a way to make the shader-based pipeline of newer OpenGL versions react to changes in what used to be OpenGL state, and will eventually become OSG state. It's an attempt to keep the nice encapsulation of state that OSG gives us through StateSets and StateAttributes but make it work on the shader-based OpenGL 3.x+.
The osgshadercompositor example in the current OSG sources shows what could be a potential direction for this. It has a new subclass of osg::Program, VirtualProgram, and you essentially add prototypes for functions along with a shader fragment associated to it, and lower down in the graph you might override that prototype with a new shader fragment, kind of like virtual functions in object-oriented code.
(there's currently a performance penalty associated with the use of VirtualProgram which someone will look into eventually)
Note that the osgshadergen example is totally different, it generates one shader from a combination of states instead of linking the right shader fragments together. IMHO this is less powerful.
Look at the example and see if you can join the discussion when the time comes :-)
Is this the sort of thing shader composition will help with?
I think it definitely can help with your situation. In our case, when we talk about it, it's mostly for the goal I explained above, as well as to help with nodekits which may specify a default shader that the user then needs to completely rewrite for their application (examples are osgShadow and osgOcean). Shader composition would help make that process easier by defining an interface that the nodekit's shaders expose, and then the user's shaders can call functions from that interface to get the right results.
Hope that clears things up at least theoretically. Robert has said that it's one of his milestones for OSG 3.0 to implement at least a first version of shader composition (or some way to make shader-based development better integrated into the OSG graph) so I guess he'll start a discussion about it eventually.
J-S -- ______________________________________________________ Jean-Sebastien Guay [email protected] http://www.cm-labs.com/ http://whitestar02.webhop.org/ _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
