Hi All, I'm currently brainstorming on how to support of shader composition in the OSG, and would like to get some feedback one element of a possible approach that I'm considering.
Two of my design goals is to provide a good mapping between the fixed function pipeline and shader based pipelines, and I'd also like to minimize the number of code changes required by end user applications. Whether these are both attainable or not we'll work in the next few weeks, but I guess few would disagree with that these are worthy goals. The absolute minimum code changes required in end user apps is none at all, might this be possible? If that is to be achieved then we need to be able to use the osg::StateSet::setMode(GLenum,...) and all the osg::StateSet::setAttribute(..) and all StateAttributes subclasses that we are familiar with. Now some parts of OpenGL state are common between the fixed function pipeline and the shader pipeline and live on right from GL1 to GL4 and GLES2, these parts needn't change one bit which is good news. However, the majority of glEnable/glDisable(GLenum) and the associated glFunctionCalls aren't mapped, for these we'd need to automatically map these to equivalent glShader/glPrograms and glUniforms. This mapping will have to automatically detect these modes and avoid calling the usual glEnable/glDisable, as well as be redirected into a current active set of modes that are enabled, this active set of modes would then map to the appropriate combination of shaders to implement them. This mapping of modes is something that osg::State could do for us without any changes to osg::State. The second half of this approach would be for the osg::StateAttrirbute::apply(..) methods to use uniforms to pass in the state to the shaders rather than their use glFunctionCalls. Again this is something that should be possible to hide from the set of those StateAttribute subclasses and osg::State. I *think* it should be possible to get something working along these lines. Implementation will tell us whether it's possible though. Now mapping of the fixed function pipeline to shaders conveniently is only part of the story with shader composition. We actually want end users to be able to selectively replace parts of the glProgram without their own shaders, both replacing the fixed function parts and composing your own shaders - we'd want a full mix and match, from all standard fixed function equivalents to all custom shaders. Now one element of what makes the current fixed function pipeline so convenient is that we can enable/disable whole chunks of fixed function pipeline anywhere in the scene graph, and the one of OSG's greatest assets over the years has been the decoupling of modes from attributes making these OpenGL feature really accessible, this asset would be great to carry over into the new era of shader composition. Since I'm wanting to a real easy mix/match of the fixed function and custom shaders then I also want to blurr the distinction when using modes. Which leads me to a suggestion that might be controversial... and the crux for this post... My thought is to allow users to use osg::StateSet::setMode(GLenum...) with not just the standard GLenum we know and love, and that are managed by Khronos, but to allow us to use our own custom mode values that extend beyond that our gl.h headers provide. These GLenum values would down to OSG users to decide when they set up their custom shaders, and for them to tell the OSG how to map them to shaders when doing shader composition. Perhaps we could just ear mark a certain range of values that we use ourselves, perhaps even tell Khronos about it so they can advice us to avoid certain ranges that the plan on using. Perhaps we just do it informally and pick a pretty distant range along way from anything that OpenGL uses right now. Thoughts? Robert. _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
