HI Aurelien, I have just done a code review and am going to reject the code as is. I feel the approach won't scale well as one is hardwiring support for osg::Material into RenderLeaf and State, and if we take this approach when the times comes to support all the rest of the fixed function pipeline we'll end up with huge mess of code to maintain and the performance overhead with all the checks would also be detrimental. While the approach you have taken does follow what I did for the modelview and projection matrices these are special cases and require very specific type of handling which differs from normal OpenGL state attributes that are handled by osg::StateAttribute.
This issue you are trying to solve is one I've been aware of for a couple of years, I have also done some of the legwork in creating an infrastructure in the OSG to support mapping of fixed function pipeline to shaders in the form of shader composition. The two halves of shader composition is the management of the shaders themselves which is equvilant to the glEnable/glDisable functionality in the fixed function pipeline, and the uniform management that is equivalent to mapping osg::Material to osg_Material as you have done. Before I could complete the work on shader composition I got swamped by other more pressing client and community work and alas haven't had the time to get back and complete this work. Shader composition is bleeding dev work with no good prior art to learn and be inspired by so it's not something that is easy to drop in and out of from time to time - I need to focus just on this topic for a couple of weeks to get my head around all the issues and potential solutions. For a bit of idea of where I was going have a look at the osgshadercomposition example and the various supporting classes. In my work I hadn't solved the issue of automatic mapping of old fixed function state like osg::Material, but had a plan of have osg::StateAttribute subclasses like osg::Material provide their own osg::ShaderComponent which in turn provide the shaders, and then the uniforms that will be required by these shaders. I'm afraid the provision of the shaders is the bit I hadn't nailed down yet, but had a vague idea that the state attributes would maintain their own osg::Uniform and apply these from within their apply() method, or have these queried by osg::State. I must admit I didn't spend time thinking about your usage model - provide your own shaders but want the uniforms, but this case should just require the disabling of the shader composition but enabling of the uniform application. One of the guiding principles of the approach I was going for was that the implementation of the various osg::StateAttribute (such as osg::Material, osg::Light etc.) is that they would all provide their own local uniform and shader implementations, their wouldn't be any global approach to implementing the individual functionality - as I mentioned in my first paragraph I don't like this approach as it'll lead to lots of functionality being hardwired into classes like osg::State to the extent that it'll kill performance and maintainability. As I haven' solved all the problems of shader composition yet perhaps others can reflect on the issue and how we might implement the automatic uniform provision be state attributes in a way that solves the specific problem that you have now and leads naturally on to full blown shader composition. Cheers, Robert. Robert. On 7 February 2013 11:42, Aurelien Albert <[email protected]> wrote: > Hi, > > In "advanced" OpenGL (glsl > 320 I think) gl_material is deprecated. > > This is really annoying if you want to render "normal" files such as > 3ds/ive/osgb... which contains osg::Material. > > This submission works like the "setUseModelViewAndProjectionUniforms" method > on osg::State, by introducing the "setUseGLMaterialUniforms" method : > > This method add some uniforms, synced with the current osg::Material : > > osg_FrontMaterial.ambient > osg_FrontMaterial.diffuse > osg_FrontMaterial.specular > osg_FrontMaterial.emission > osg_FrontMaterial.shininess > > and > > osg_BackMaterial.ambient > osg_BackMaterial.diffuse > osg_BackMaterial.specular > osg_BackMaterial.emission > osg_BackMaterial.shininess > > > To use it in a shader, you can : > > 1/ Declare only uniforms you want to use : > > > Code: > uniform vec4 osg_FrontMaterial.ambient; > uniform vec4 osg_FrontMaterial.diffuse; > > > > If you use only these two values > > 2/ Declare complete structure : > > > Code: > // Define the structure > struct osg_Material > { > vec4 ambient; > vec4 diffuse; > vec4 specular; > vec4 emission; > float shininess; > }; > > // Declare the unfiroms : > uniform osg_Material osg_FrontMaterial; > uniform osg_Material osg_BackMaterial; > > > > > and then use osg_FrontMaterial.ambient, osg_FrontMaterial.diffuse, etc... in > your shader code. > > > > Thank you! > > Cheers, > Aurelien > > ------------------ > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=52462#52462 > > > > > _______________________________________________ > osg-submissions mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org > _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
