Hi Robert,
On 19 February 2015 at 10:19, Robert Milharcic <[email protected]
> wrote:
> 1. Add a new layer of abstraction for StateSet's define API, lets say
> class object ShaderDefine that we can subclass. The ShaderDefine (or any
> other suitable name) would contain std:string _defineName, std::string
> _defineValue and at least a less operator, since you are inserting
> definition into map, and virtual void apply(State&) const {}. Of course,
> the apply would then be called from State::applyDefineList() giving the
> user an opportunity for define's customization. So the new
> StateSet::setDefine() would look something like this:
> setDefine(ShaderDefine*, StateAttribute::OverrideValue);. Also, with the
> proposed abstraction it would be easier to write serialization support.
>
What would you be trying to do by sub-classing from ShaderDefine?
Currently shader defines have a std::string that maps to the string used in
the #pragma entry, and a std::string that maps to the value assigned to the
#define that will be generated.
One approach I considered when designing #pragma(tic) shader composition
was the use of a immutable osg::Token object and a factory that generates
unique Token objects for each std::string value used, so "LIGHTING" would
always map to a single osg::Token object that has a string "Lighting". The
use of these Token objects would speed up comparisons as it could be done
entirely on pointer comparisons.
Another possible variation I considered briefly was that overlap between
the way that uniforms and vertex attributes are applied - they all have
names associated with them. Could one unify elements of defines with way
the interface one has for uniforms and vertex attributes? I did spend long
enough to explore the possibilities, and as it'd likely require lots of
intrusive internal and API changes it's not something that was appropriate
pursue more than an observation of commonalities.
The solution I plumped of using a std::string name and value for each
define entry was driven by simplicity of API and implementation. The
approach is not something I've seen before so just getting something
working to prove the concept or not was important. In the end the approach
has been more powerful than I original envisaged.
>
> 2. The greatest strength of old shader composer is
> ShaderComposer::getOrCreateProgram(). As others have already mentioned,
> this is the point where we used to gain control over the program
> composition. I'm personally using this control point for things like
> program->addBindAttribLocation/addBindFragDataLocation/addBindUniformBlock
> and for some other sanity checks. It would be great if we can somehow
> install a callback or overload some member to regain the control of the
> program composition.
Perhaps osg::Program itself could be adapted to allow it to be easily
subclassed so that the shader selection, compilation and linking and
uniform/attribute setup could be managed by end users that wish to subclass
from osg::Program. Another approach would be to defer this work to a
helper object that gets assigned to osg::State. Perhaps the
PerContexProgram/PerContextShader classes could have a role here in some
way.
What I'd really need is a concrete example in front of me that illustrates
what functionality is needed but isn't possible. An example based on the
old osg::ShaderComposition would be fine.
I'm keen to find low impact ways of adding more power without complicating
the API and OSG backend. So far #pragma(tic) shader composition is
straight forward to use for a range of usage cases so am confident that
it's got most things right. It is just a first cut though, I don't feel
it's the final word on shader composition, I'm far more confident about it
than my previous attempts and solving this type of task.
Robert.
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
