Hi Bruce, On Wed, Jun 23, 2010 at 9:23 PM, Bruce Wheaton <[email protected]> wrote: > So, we would do the same enable calls on state sets with custom made enums, > and then also provide a shader function that will be used only if that > feature is enabled?
Yes that's the idea. > It sounds like a great idea... although isn't it maybe sufficiently useful > that it deserves it's own enable and set functions, especially if all the > enums are custom? Then name collisions won't be a problem. To support the seamless mapping of the existing fixed function pipeline based scene graph to shaders we'll need retain support for the existing setMode(GLenum..) functionality, having another set of methods for enabling/disabling shaders as well introduce it's own conflicts - it conceptually would separate custom shaders from fixed function shaders, but internal implementation wise they'd still have to be mixed so we'd end up with concepts and API that don't match what is happening behinds the scenes. I feel this would be a recipe for confusion and lots of bugs in OSG and end user code. My wish to achieve a good level of transparency about how things are mapped from the scene graph API front end and how the final shaders are composed in the back end. Right now engineers are familiar with the idea of fixed function pipeline and shaders, and the fact that they are two separate routes in OpenGL, if we get it right way break down this separating both in implementation and conceptually then we'll suddenly open out lots of possibilities in people minds. > The more I think about it though, the more it does seem like enable/disable > and set value is a good fit. The there could also be different backend > methods to create the final shader - by compilation if there's enough time, > or by conditional if the graphics system does it quickly enough... Having a ShaderComposer that is attached to osg::State that does the work of taking all the enable modes and generating the final osg::Shader/osg::Program will be the natural way to implement it. Roland's implementation already has this in place in the form of an osg::ShaderGenerator class. Potentially we could allow users to assign their own custom ShaderComposor at application start up, or perhaps even allow one to attach a custom ShaderCompsor to a StateSet and maintain a stack in osg::State, so the the top of the stack is used to do the shader composition. Most application would never need to override the standard shader composition but I would guess that some advanced users might relish the opportunity. For a first pass I want to get something working with just a single ShaderGenerator attached to osg::State, there is enough complexities to deal with without making things more complicated at the start. > One worry might be the implication that every single 'building block' could > be dropped in and things will still work. I have a number of shader pieces > that only work in the context of a bunch of other shader pieces being active, > along with the correct textures etc etc. Needing to make sure various components are enabled to achieve an overall effect is something that we all need to manage right now so I would expect we'll still have to play by these rules - be sensible about creating scene graphs that work and not expecting the backend to somehow cope when we throw at it an inconsistent setup. It has just occurred to me the ShaderComposer itself could output quite a bit of useful debugging about what modes are enabled, what shaders are available and what is output is generated - this might be quite useful for debugging scene graph state. Robert. _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
