Hi Aurelien, I'm currently working on a shader generator for OSG. And I am really interested by this topic.
Correct me if I'm wrong : Your main problem is "how to handle fixed pipeline attribute/uniform in GLSL Core profile?" To do this, you create a big Uniform Buffer Object (UBO) that store all attributes you need to draw the scene. You add, by code injection, shaders function/declaration to access to uniforms in UBO. Then shaders in SceneGraph could use this functions to render drawables. Problem I see in your approach: If you change one attribute, you have to update the entire UBO. ModelView matrix change for each drawable, so UBO is updated on each drawable. In a scene with 1000 drawables, if one drawable use a lot of attributes to be renderer, and 999 others use only few attributes, we still send to the GPU a lot of useless attributes. Your first submission in date of 2013/02/1, just add uniform in each osg::StateAttribute, is more flexible than this one. I think the problem of Fixed Function Pipeline in OpenGL 3 Core profile must be solved by a solid shader generator (SG) that could create shader like the FFP, or any custom shader the user need. To do this, SG have to use osg::StateAttribute to inject code/uniforms in final program like Robert start to do with osg::ShaderComponent and osg::ShaderAttribute. This way, we only have a shader with what we need, and only required uniform are send to the GPU. We don't add code to solve one part (FFP in Core profile) of a bigger problem (shader generation). I will try to finish the first version of my Shader Generator before the end of April. And an example to handle FFP in OpenGL Core Profile My 2 cents David 2013/3/23 Aurelien Albert <[email protected]> > Hi, > > On next week I'll have to make some important decisions about my current > two project's software architecture. > > This submission really help me because I can now leave the "OpenGL State > machine" management to the osg::State class and implement different ways to > use the "OpenGL State machine" with different osg::Pipeline classes. > > I can still use this submission with a locally modified osg version, but I > prefer to be connected on the osg trunk. > > So, is there anybody interested by this submission ? > Robert, do you have any comments about what I've done here ? Could you > tell me if you plan to merge this or not ? (there is no hurry for the > merge, but I really would like to know your opinion before make any > software architecture decision) > > > Thank you! > > Cheers, > Aurelien > > ------------------ > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=53212#53212 > > > > > > _______________________________________________ > 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
