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" <robert.osfi...@gmail.com>
Sent: Thursday, June 24, 2010 4:51 PM
To: <osg-users@lists.openscenegraph.org>
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
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
