Hi Robert, Has further work been done this? I've actually started a bit on my own shader composition framework until a colleague informed me about the work here. So instead of inventing yet another way of addressing this problem I wouldn't mind helping out here or at least reviewing/testing/contributing to the designs you have so far.
Cheers, Chris On Mon, Sep 20, 2010 at 3:48 PM, Robert Osfield <[email protected]> wrote: > 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 > _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
