Hi Mathias, 2010/6/25 Mathias Fröhlich <m.froehl...@science-computing.de>: > With that proposal - espcially the StateAttribute::compose call working > directly on the osg::State - I conclude that we need to relink during draw: > * we will probably loose state sorting for the shader combinations > * shaders need to be at least relinked on every state change which will have > some runtime (drawtime) overhead.
The plan I have wouldn't affect state sorting, and lazy state updating of the composed shader programs would be utilized, and caching of the composed shader programs would be used once it has been composed. Only when you change modes will you need to go look for a new composed shader program, and only when you can't find an already cached one for the current set of enabled modes will you have to compose an new shader program. At least this is what I have in, and believe it'll be essential. The OSG's existing state sorting and lazy state management for modes and attributes will all work as is, we shouldn't need to modify it at all, so this will all happen automatically during cull as it builds up the rendering graphs and state graphs in the rendering backend. The only thing that will change will be what happen different will be internally in osg::State during the draw traversal, the rest of the draw will actually be identical. I'm expecting all the hardwork over the next few weeks to happen in osg::State, in the new shader composer classes and eventually in the various subclasses of osg::StateAttribute to provide the shader versions of the fixed function pipeline. The rest of the OSG is likely to remain pretty well untouched, and hopefully this will apply to end user applications as well - unless they want to leverage the new features that is :-) Robert. _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
