Hi Robert,
I think shader composition would be the next big thing for OSG although
robust design is far from trivial. For most users hiding shaders or
"snippets" would be the good thing. I would love to have state sets with OSG
modes not GL ones i.e.
StateSet
{
OSG_LIGHTING ON
osgLightingModel {
mode PHONG
}
OSG_NORMAL_MAP ON
OSG_SHADOW ON
OSG_FOG ON
osgFogModel {
mode VOLUMETRIC
upDir 0 0 1
}
}
Power user could register ther own modes/attributes handled by external
toolkits. With this approach different backends for GL1, GL2, GL3, GLES,
Sofware rasterizer, Software raytracer, DirectX :) could be implemented.
Regards,
Maciej
2009/2/23 Robert Osfield <[email protected]>
> HI Marciej,
>
> You thoughts on shader "snippets" being collected and assembled into
> programs that are then cached is roughly what I've been envisaging as
> well. It's something I did try to get my head around when we
> integrated GLSL into the core OSG a few years back, but the complexity
> of this system meant that much more time would have to be invested in
> developing, so rather than be so ambitious we went for the current
> approach of decoupling uniforms from osg::Program, but not the whole
> hog of decoupling osg::Shader from osg::Program.
>
> The full blown shader composition is something we do need to address
> in the next generation of the OSG. Exactly what the interface should
> be, and how we implement the back-end is the big hard part. Once we
> have such a scheme in place then provided only fixed function style
> capabilities in GL3 or GL2 GLSL path ways should be much easier. At
> this point the distinction between the fixed function pipeline and
> shader pipeline will melt away and become an implementation detail,
> rather than a scene graph interface one.
>
> Robert.
>
> On Mon, Feb 23, 2009 at 10:04 AM, Maciej Krol <[email protected]> wrote:
> > Hi Robert et al,
> >
> > I thought about concept of generating shader code in cull traversal from
> > shader snippets. Snippet is a piece of GLSL code that implements certain
> > functionality like texture sampling or lighting, usually few lines of
> code.
> > Snippets have defined inputs like required varyings, uniforms and output
> > variables of dependant snippets. Output of snippet is a glsl variable
> (i.e.
> > texture coordinate, texture color) for internal snippet or
> > gl_FragColor/gl_FragData for terminal snippet. Snippets sit in a StateSet
> > just like modes and attributes. In cull traversal dependency graph of
> > snippets is created. From this graph GLSL program is generated or fetched
> > from cache. This approach would allow to seamlessly use functionality
> from
> > different toolkits without the need to rewrite shaders or to use
> ubershader.
> > Toolkits such as osgShadow or osgFX would expose shader snippets for
> certain
> > effects (shadow, phong lighting, atmospheric fog, etc) which could be
> merged
> > into snippet dependency graph. To imlement fixed function pipeline
> > functionality one can define mapping from modes/attributes to snippets.
> It
> > is just a concept. I do not know would it work in terms of ease of use
> and
> > extensibility.
> >
> > GLSL is a must in these days especially for one reason - per pixel
> lighting.
> > It is a pity that it is not exposed in a fixed function pipeline. In my
> > applications I map fixed function pipeline to GLSL with custom visitor.
> > Based on state set modes (lighting, fog, ...) and vertex attributes
> (normal,
> > tangent, texco, ...) GLSL shaders are generated and cached in a map
> (modes,
> > vertAttribs)=>shader so they are unique. Only certain cases of FFP are
> > handled. Visitor is called in ReadFileCallback to convert FFP to GLSL. In
> > typical scenario You need only a few unique shaders (light on/off, color
> map
> > on/off, normal map on/off, env map on/off, fog on/off). Such simple
> solution
> > really pays off in visual quality of scenes.
> >
> > Regards,
> > Maciej
> >
> > 2009/2/20 Robert Osfield <[email protected]>
> >>
> >> Hi All,
> >>
> >> One of the items I have ticking away as a background process is the
> >> topic of how we should gracefully manage the transition from the usage
> >> of fixed function pipeline to entirely shader based implementations.
> >> One motivation is the obvious one - GL3 and OpenGL ES don't have any
> >> fixed function pipeline, so we need to know how to implement the
> >> current OSG functionality that relies upon fixed function pipeline,
> >> and a second more subtle one - how to manage the combination of
> >> different shaders in a way that is as flexible and intuitive as the
> >> fixed function pipeline is for composing different elements of state
> >> together.
> >>
> >> This isn't an easy problem to solve, and rather than try to come up
> >> with a complete solution right now, in tinkering round the edges
> >> trying to get a better picture of the landscape of the problem. One
> >> area we can map out right now is that of how existing fixed function
> >> pipeline features would map to GLSL shaders. I recall that such a
> >> mapping has been published, but a quick search on the web didn't pin
> >> point it. Does anyone have a reference to such a body of work?
> >>
> >> 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
>
--
Regards,
Maciej Krol
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
