Hi Johannes, I'm just about to make a dev release so I won't dive in a full review yet. With a brief review of your design from your pdf and email it does seem like you've implemented some similar concepts but just introduced new language, and language that does seem less appropriate. Class names can easily be fixed though.
More of concern is that there doesn't seem any clean way for integrating fixed function pipeline and shaders, and the ability to toggle modes and associated shader pathways on/off is missing. These were key elements to my work on shader composition, must have features effectively, and the reason why I deemed previous shader composition implementation insufficient. My own work shader composition is far complete, I've had to back off from this work this last month to complete client work, but I will soon be getting back to it. There are weaknesses in the current design/implementation and I'd us to find what these problem areas are and seek out solutions. It doesn't seem necessary to throw out the whole design and implementation and introduce and new design and implementation, especially one which introduces new weakness with it. Once I've got back to shader composition work I'll do a full review of your code, and my own, and Roland's previous work and look for weaknesses and strengths of the different approaches. I'll be happy to dive into discussion about this, but right now I need to concentrate on getting 2.9.9 out the door and finishing some client work. I'm hoping to be back on shader composition by next week. Cheers, Robert. On Mon, Sep 20, 2010 at 1:20 PM, Johannes Maier <[email protected]> wrote: > 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 > _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
