Hi Robert, Thanks for all these explanations and for your efforts about this issue !
Being able to use shader composition's uniforms is very usefull, and will probably help me in various situation. But... I still have a problem with the osg::Material class : the "core" class do not use shader composition's uniforms, so they are not sent to the GPU for all exisiting node kits. For example, I use osg's manipulators, the geometry is builded by osgManipulator::Something class using an osg::Uniform, and my rendering system do not get matrerial values. So, I think about two possible solutions : 1/ use an static member, such as "bool osg::Material::UseCompatibilityUniforms" to configure at runtime if the osg::Material class set these uniforms or not. The same pattern could be used for other classes which use deprecated OpenGL functions, like osg::Light, osg::TexEnv... These flag could be forced to "true" if fixed pipeline is not available. 2/ more flexible, but more work : use factories for some StateAttribute, like osg::Material, osg::Light, osg::TexEnv... do not explicity use "new osg::Material" but "osg::Material::createInstance()". This way, any developper could write its own material class, with respect of the base interface, and by setting the prototype on the factory, the whole osg will use the "special" osg::Material. I think there is a lot of advantages for solution 2/ (separate logic for "how data are represented in a classic 3d file" and for "how to represent these data on the GPU side"), but there is also a big drawback : even if the osg::Material constructor is still public, to really use this system all osg code and plugins code need an update. Thank you! Cheers, Aurelien ------------------ Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=55094#55094 _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
