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 osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org