Hi Robert,
I was amazed by the simplicity of the new pragmatic shader composition -
but yet it is so powerful. Well done! So, I was making good progress
porting old shader composition code to pragmatic one until I hit the
wall. The problem is, I don't see any obvious way to extend the current
pragmatic shader composition API. If I may, I would suggest two things
for consideration:
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.
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.
Robert Milharcic
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
