Hi,
> Your solution seem to be a good one for usability point of view. But > possibility to render complex scene or extend rendering capability > without rewrite a osg::Pipeline/osg::Program is not available. Yes, but as I said : > My problem is also to handle application specific StateAttribute and to allow > a way to specify different StateAttribute <=> GLSL binding for different > applications. In my point of view, a generic-pipeline-which-cover-all-use-case is a bad idea because this is too complex. I perfectly agree with what you said about shader generator and different lighting models (I've worked a lot with osgEarth VirtualProgram and shader generator, and this is a great system). But after several osg based application developpement for different customers, I can say that it had help me a lot if I can define an application-specific (and not a generic-which-cover-all-the-use-case) pipeline so all my application-specific shaders can be unified, both in syntax and logic. > So this is an UberShader solution, one shader could render all drawable in > the scene Yes, but it is only an example. The osg::Pipeline class is pure virtual and allow the developper to develop a specific pipeline for a specific application, using a UberShader or regular shader, or shader generator or whatever. Thank you! Cheers, Aurelien ------------------ Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=53219#53219 _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
