I've not at the computer full time for the last couple of days so
haven't been able to push the shader composition implementation on
yet. Design wise I've been doing bits here and there. My latest
thought is that we probably need to encapsulate the component that
will go to make up shader composition as a single class/object. This
class would contain a list of required shaders, the list of shader
modes, and the shader main code injection rules. What to call this
class is a problem... perhaps ShaderSet? ShaderComponent?
ShaderChunk? Thoughts?
For my own design doodling I've run with the name ShaderSet for this
class, so will follow this in rest of the email, if we go for
something different later then so be it. The role of the ShaderSet
would be:
1) Provide a way of encapsulating all the details required to
contribute a single chunk
of functionality that will be combined with other active
ShaderSet to provide final
composed osg::Program.
2) Provide a convenient mapping of a single ShaderSet representing a single
implementation that can be shared by multiple osg::StateAttribute objects,
for instance all osg::Light objects would shader a single
ShaderSet for all
directional lights, another ShaderSet for all positional lights
etc. If different
state attribute objects shader the same ShaderSet then there it
will be easily
to test whether shaders are the same simply be testing the pointer value,
we needn't look into the contents.
This approach works well for the OSG right now with how we manage
osg::StateSet or the StateAttribute within them, so I'm pretty
comfortable that
this approach will be useful when doing shader composition and keeping the
costs of lazy state updating down.
3) The ShaderSet would contain list osg::Shader objects, these osg::Shader
objects would target which ever part of the overall program that
the ShaderSet
effects - be in multiple osg::Shader for vertex programs, one of
vertex program
one for fragment, or any combination. The individual
osg::Shader objects could
also be shared by multiple ShaderSet where appropriate.
4) The StateAttribute would "have a" ShaderSet which defines all the shader
setup required, this ShaderSet would typically be shared by all
instances of
that type of StateAttribute. The StateAttribute also "have"
zero more uniforms
that pass in values to the shaders in the ShaderSet, these
uniforms wouldn't
typically be shared, but would be solely owned by each separate
StateAttribute
object.
The StateAttribute's ShaderSet would only ever be queried if the
shader modes
associated with that ShaderSet and hence StateAttribute are enabled, and
no cached osg::Program for the current configuration of enabled
shader modes
is available.
5) It might well be that some StateAttribute have unifoms but no
ShaderSet, it
might also be appropriate for some StateAttribute to have no uniforms and
a ShaderSet. It might even be appropriate for a single
StateAttribute to have
multiple ShaderSet depending upon what mode it is in - for
instance osg::Light
might be implemented in such a way that you have one ShaderSet for a
directional light, and one ShaderSet for position light,
another for spot lights,
another for per pixel lighting etc, and select the appropriate
one depending
upon the set up of the osg::Light.
6) Given osg::StateSet already has support for managing osg::Uniform directly
perhaps we might even want to make it possible to assign
ShaderSet directly
along side them rather than nesting them within StateAttribute. A pure
shader composition approach could do this, but for seamless
support of existing
fixed function StateAttribute based scene graph we won't be
able to just this.
However, have two ways of doing the same thing might just lead
to confusion...
so it's something I think we just need to implement and test to
see how we get
on.
Anyway these are my latests thoughts. I will be out for much of
today, but later in the week should get more time to start
implementing some code to start experimenting with basic shader
composition.
Cheers,
Robert.
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
