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
