Hi Aurelien, I believe both your suggestions are possible but feel it's not appropriate to try and resolve how best to proceed for 3.2. The issue of remapping osg::Matrial to myCustom::Material is an awkward one, one resolved by the core osg::Material having all the functionality desired, or for the backend implementation itself to be replaceable.
After 3.2 is out I'll be happy to discuss more sweeping changes to how the core OSG manages state. One thing I've considered is whether we go for separation of the scene graph data from OpenGL implementation. This approach would have the osg::StateAttribute be just a data container that "has a" graphics API implementation that is assigned during the graphics traversal, this graphics API implementation would bind any extension function pointers as well as OpenGL object handles where required. These graphics API implementations could be different for different target OpenGL implementations. To handle multiple graphics context one would naturally buffer the graphics API implementaion. In cases where it's just a simple wrapper around an OpenGL call one could share a single graphics API implementation amongst multiple scene graph StateAttribute associated with that type, but where one needs GL object handles such as texture you'd create a separate object for each context and for each StateAttribute. However, this is a potentially pretty deep topic to get into, not one I can delve into the eve of going on holiday, and not one helpful with making progress with an imminent release. Cheers, Robert. On 2 July 2013 19:23, Aurelien Albert <[email protected]> wrote: > 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 _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
