Hi Wojtek, I don't really see a strong separation between emulation of the fixed function pipeline and shader composition. My current view is that we'll have StateAttribute's that provide batches of uniforms, any shaders that are required, and guidance on how into inject support for them into the vertex/geometry/fragment/main shaders. The fact that a StateAttribute might be come from a fixed function pipeline background won't make any difference to the actual shader composition. At least this is what I'm gunning for.
I would also like to make it quite easy to find out what uniforms various StateAttribute subclasses use and what Shaders they provide. I really don't want us to end up with black boxes that users either use without knowing, or ignoring completely because they aren't sure what they do. The situation you describe is really what I'm trying to avoid - I want the community to be able to freely mix and match where they find each component useful. For high level techniques such as deferred shading I see it as natural that you'd happily mix the two. The first pass rendering the scene to a depth and colour buffers could happily use a traditional StateAttribute without any custom shaders if you don't need them, but then the second pass you'd obvious bring in to play all your custom shaders. There are also high level techniques like overlays and shadows where eye linear texgen is used, here you'd want to leverage the OSG's core support for eye linear texgen, otherwise you'll end up have to code lots of your own solutions. Robert. On Thu, Jun 24, 2010 at 11:25 PM, Wojciech Lewandowski <[email protected]> wrote: > Hi Guys, > > We all seem to agree that the topic actually consists from two subtopics: > ShaderGeneration and ShaderComposition. Shader generation would be mostly > used to emulate Fixed Pipeline and replace GL Attributes/Modes with > generated uniforms and shader pieces. ShaderComposition would allow mixing > and linking of various shader pieces gathered during cull traversal. Shader > Generation seems to be the current focus of the discussion. > ShaderComposition seems to be of a lower priority. I have the felling that > these two subjects could be addressed together but they also could be > addressed independently. ShaderComposition is needed to implement > ShaderGeneration but not the opposite. So wouldn't it be better to first > implement flexible ShaderCompositor that at first would only work with > programmable pipeline in OSG ?. And later build ShaderGenerator on top of > ShaderCompositor ? > > I believe there is a number of developers interested only in programmable > pipeline. They would not mind writing shader chunks and using their > uniforms to attain effect that fixed pipeline would also give them. They > would do this to have clear and consistent shader code. And often they want > to make transition to fully programmable pipeline as fast as possible > because they feel thats how the 3D future will look. > > I am ready to make such switch. I only need working ShaderComposition. > Personally I'm not interested in fixed pipeline emulation and where possible > I will try to program shader pipeline myself. Call me short sighted but I am > afraid that trying to replace programmers with shader generators will make > this coding more complicated. > > Once ShaderComposition becomes available I am not going to go back to FFP > and will avoid StateAttributes that exist only in fixed pipeline. I will > thus indirectly avoid using ShaderGeneration feature as well. In my opinion > many programmable pipeline concepts are easier to understand than the stuff > in Fixed Pipeline (take TexEnv or TexMat for example) and I would always > prefer to have direct control over uniforms & shaders neccessary to > implement certain feature. With ShaderGeneration I will never be sure what > shader code was produced and how uniforms were attached. > > That's my opinion. But I am taking the risk of presenting it because I think > there are others who share this view and would prefer to make transition to > fully programmable pipeline as quickly as possible. There is a number of > algorithms where Fixed pipeline states simply don't fit. Deffered shading > for huge number of lights for example. Its better to implement them in fully > programmable environment than mix fixed and programmable approaches. > > I know there are other users and lots of existing OSG code which relies on > fixed pipeline. I understand that this existing code will require > ShaderGeneration but I really feel that the discussion is focusing on second > step when first one was not made yet. > > Cheers, > Wojtek Lewandowski > PS. I won't be able to respond for next 3 days. > > > > -------------------------------------------------- > From: "Robert Osfield" <[email protected]> > Sent: Thursday, June 24, 2010 4:51 PM > To: <[email protected]> > Subject: Re: [osg-users] Shader composition, OpenGL modes and custom modes > >> Hi All, >> >> As another step towards experimenting with shader composition I've >> renamed the osgshadercompositor example to osgvirtualprogram as this >> example is based around a VirtualProgram class, and I'd like to >> differentiate between test beds like this and work to towards the >> final shader composition support. >> >> Later I'll add a >> osgshadercomposition/osgshadercompositor/osgshadercomposer example >> that will be the test bed for the new work on shader composition. >> >> Robert. >> _______________________________________________ >> osg-users mailing list >> [email protected] >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
