I'm continuing my pondering of shader composition and I'm currently
thinking about extending StateAttribute a little to support shader
composition. Currently we have two virtual methods in
StateAttribute::getModeUsage(ModeUsage&) and
StateAttribute::apply(State&) that subclasses override to provide the
specific behavior associated with that attribute. I'm thinking about
retaining these, but extending their role a little, and adding another
virtual method StateAttribute::compose(osg::State&). As well as this
small addition to StateAttribute we'd need to extend ModeUsage to help
provide more details about the nature of the modes that it supports
w.r.t shader composition.
The roles of these methods would be:
StateAttribute::getModeUsage(ModeUsage&)
Passing information about supported modes that should be used for
glEnable/glDisable, which ones should be mapped to shaders when doing
shader composition. In the case of custom GLenum that we come up with
ourselves these would never be used for glEnable/glDisable,
just for informing
the shader composer what to enable/disabling when compiling
the shader main()
for each of the vertex, geometry and fragment programs.
Roland's implementation follows this pattern already, although via the
introduction ShadeMode::Type and ShaderModeIndexPair.
StateAttribute::apply(State&)
Provides two potential code paths - fixed function calls i.e.
glMaterial and
the shader composition version applying unifoms that are local to that
StateAttribute and are required for the shaders associated with
that attribute.
I'm thinking about having a couple of macros to introduce each
of the code
paths such that for each GL/GLES target we build the OSG to we'll be able
to enable or disable each path appropriately, either at runtime
or compile
time.
StateAttribute::compose(State&) / maybe compose(ShaderComposer&)
Pushes the osg::Shader objects required for the functionality (could be
none to many) and pushes the GLSL code fragments that need to
injected into
Shader main of the the vertex, geometry and fragment programs.
I'm also wondering about the possibility of having a ShaderAttribute
class that subclasses from StateAttribute and makes it possible to set
up the osg::Shader's associated with the attribute, and the GLSL code
fragments that need to injected, as well as set up the custom type and
modes associated with it. We could easily have the type settable to
existing fixed function StateAttribute::Type values and GLenum's so
code enable us to override standard fixed function features with
custom shaders, without ever needing us to subclass - we just compose
the ShaderAttribute with how we want it used.
Since the above suggestions are a relatively small change to the
existing API it will be quick to implement the interface and could be
done with breaking any existing functionality or end users
applications. It's tempting for me to just check these changes in,
and then look at the next part of the equation - the really hard part,
the ShaderComposer interface and implementation.
What I may do is start fleshing out a very basic interface and
implementation for ShaderComposer that does little more than a non op,
and put together a really simple example that enables us to create a
scene graph and see how the wiring works at runtime.
The next step after this would be to get shader composition working
with a custom set of ShaderAttribute that completely ignore the fixed
function pipeline. Once the mechanics of shader composition and
interface are working we can then looking to step by step mapping the
fixed function features across to having code paths that support
shader composition.
If all this comes together well then the next challenge will be
rewriting the way that NodeKits like osgShadow and osgParticle do
their shaders, rather than having them provide full osg::Program for
their shaders we'd need to convert them across to use ShaderAttribute.
Thoughts? Suggestions?
Robert.
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
