Hi Robert, I made an implementation of some kind of ShaderComposer (called ShaderMerger) and I would like to submit it. I wrote an pdf-document with an explanation, how the whole concept works and how it is used - also I created an example application for testing.
In short: It allows to spread fragments of shader code over a scenegraph and use a StateAttribute (ShaderTemplate) as a template (or filter) to define in what sequence they should assemble a shader program. Hence it gives the opportunity to (re)arrange shader code fragments dynamically. I appended 2 versions of it - one being a pure example working with DrawCallbacks (osgshadertemplate_callback.zip) and one directly replacing the ShaderComposer in osg::State (osgshadertemplate_direct.zip). I came up with this when I looked at your first ShaderComposer implementation. The basic problem I see is, that every ShaderComponent would inject its code depending on a float number - but there is no easy way to change this order by runtime or use the same code fragments in a different order. Also there may be ShaderComponents which have the same float number - so the order would be more or less random. So I put up a new StateAttribute (ShaderTemplate), which can define the order of code injections - even which code injections will be made (as some kind of filter). I created a class ShaderInjection, which is similar to your ShaderComponent, but uses a little different way of injecting its code. It will just append its code to existing code parts of specific locations of a shaderfile (similar to a ShaderComponent: variables, functions and in the main) - since the order is defined by a ShaderTemplate a ShaderInjection can be reused more easily. A ShaderInjection uses a key word to be referenced by a ShaderTemplate. It will always be used the last applied ShaderInjection of a specific key - so you can override a ShaderInjection by another in the SceneGraph using the same key word. As far as I understand your ShaderComposer, there will be many ShaderAttributes (containing ShaderComponents) with different osg::StateAttribute::Types (hence using different stacks in osg::State). So you can override ShaderAttributes through ShaderAttributes with the same Type, but there seems to be a flaw: A loaded Model which will be placed in the scenegraph will always use all last applied ShaderAttributes ... since it can not know which there may be, it can not just turn these "OFF". Right now - just using the FFP-StateAttributes - a model which (specified by the modeller) don't want to use texturing can just set it off (because this StateAttribute is wellknown). Through the ShaderTemplate, a loaded model can exactly use the shader fragments it is supposed to (or be forced to use only FFP by an empty ShaderTemplate) - and filter out all unwanted shader fragments from the scenegraph. It can still use wanted shader fragments from the scenegraph - ie the global lighting method (which may be implemented as per pixel lighting). Next thing I would do is add osg::Shader to the ShaderInjections so it will be possible to link a precompiled Shader to the final program. Right now it only combines shader source fragments to one final shader source code. I can think also of shadergenerators like one who takes care of ffp shader generation (I wrote one before, but did not implement it into the ShaderMerger yet). Since the ShaderMerger gets the whole state, it (or the generators it contains) can analyze it and create shader source - even combine it with shader source fragments from the scenegraph. I'm personally in favour of a fixed ffp shader generator, because the FFP will not change and the shader composition should generate by default the exact results of the FFP. This concept could take care of many problems - including dynamic (re)use of source fragments, implementation of a simulated ffp (through a fixed shader generator which will be triggered by key words) and problems evolving through possible different versions of OpenGL/GLSL (we only have to add a version to the ShaderInjection class and implement a dynamic usage of the most fitting shader fragments of a key word). In the PDF I describe some of these future improvements I have in mind - and which I may implement in the next weeks. For now I just want to know, if this concept stands a chance or if I missed some major flaws. :-) This implementation is made against the latest revision (Revision 11779.) Thank you! Cheers, Johannes ------------------ Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31822#31822 Attachments: http://forum.openscenegraph.org//files/shadertemplates_131.pdf http://forum.openscenegraph.org//files/osgshadertemplate_direct_159.zip http://forum.openscenegraph.org//files/osgshadertemplate_callback_499.zip _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
