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
