Hi Mathias, 2010/6/29 Mathias Fröhlich <m.froehl...@science-computing.de>: > So, what I think is that we need minimize shader compilation as well as shader > *linking* as much as possible. If the implementation you have in mind really > does this, then fine. If you intent to relink on about every > StateAttribute::compose(osg::State&) call, I expect to run into problems.
I think you've mis-understood my intentions. My plan has been to cache the osg::Program and main shaders once they are generated, Roland's implementation also takes the route. Calls to StateAttribute::compose(osg::State&) or it equivalent would only been done when a new shader combination is required. > The only thing that might then turn out problematic is that then there is the > StateAttribute::compose(State&) call which directly operates on the State > object. Once this is in place, backward compatibility will never make that go > away. In effect this will make a switch to a > StateAttribute::compose(CullTimeShaderComposer&) call impossible... I don't think a CullTimeShaderComposer is a good idea, but a subclass from ShaderComposer is fine, so I don't think there is a tightly coupling issue at all. We just need to get the design right so we can alter subclass from ShaderComposer as well as write our own sets of shaders. > That is the reason I am thinking about that current proposal for such a long > time. May be the State should provide such a 'ShaderCompositon' object as a > member and you let the state attribute work on this member of the State? As for the end of last week osg::State already has a ShaderComposer* get/setShaderComposer method :-) ShaderComposer is just a placeholder right now. > Then this could be moved easier if this turns out to be critical? I think we'll need to be pretty easy going with what the final design is until we've played with actually implementing the code. Is pretty rare for a design to work perfectly once you start trying to solve real problems with it. For me the real test will be how well we can implement the fixed function pipeline within shader composition - if this works neatly and conveniently then we'll be well on track. > So, again the critical thing from my point of view: > If you can make sure that we never relink during draw once no new shader > combination appears, I believe we are fine. I believe we'll all be in agreement here. This is certainly what I'm aiming for, all the designs I'm working on use a program cache as a fundamental part of the design, with state changes minimized. I don't see it all as much different to what we do know with creating texture objects, VBO's, display lists, it's just we'll be operating on a slightly higher level, it should all be the same principle - the OSG worries about doing things efficiently, and the scene graph developer just concentrates on composing the scene graph and state classes to get the result they want. Robert. _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
