Hi Johannes, I don't believe VirtualProgram is sufficiently sophisticated for our purposes, I agree about linking existing osg::Shader rather than composing these on the fly like in Roland's implementation.
However we still have to inject code into the main for each of the vertex, geometry and fragment programs, the alternative would to have massing main functions that contain all the possible variations and then using uniforms to switch between the different parts. I don't believe the later approach is at all suitable for performance or for practicality. Right now I think keeping the bulk of the code in osg::Shader functions, and then composing the mains on demand and caching these main osg::Shader will be both the most flexible and the best performing solution. One could look at it as a bit of tacking the best bits from Roland approach and the best bits of VirtualProgram, and then mixing in a means of extending the existing fixed function StateAttribute in a way that provides a pretty seamless support for shader composition. At least that's my hope... Robert. On Fri, Jun 25, 2010 at 1:14 PM, Johannes Maier <ver...@gmx.de> wrote: > Hi, > as I mentioned somewhere else, we are also thinking about a shader > composition concept. > After some consideration we came to the conclusion, that shader linking is > probably the most time-effective approach. > So we would go with Wojtek and use his VirtualProgram - extending and > implementing it. > In combination with a clean shader implementation of the FFP you can > activate/deactivate FFP-functionality by linking an empty dummy-function or a > fully implemented function. > These FFP-functionalities could also be used in own shadercode - just use the > (ie osg_fog-)function in your own code. > OSG will link it, when fog is activated and unlink (read: link empty > function), when fog is deactivated. > The linking itself should be much faster than generating some shadercode on > runtime (even with caching). > Using empty functions as "not-active"-dummys may sound like overhead, but > calling a (empty) function didn't cost any measurable time when we tested it. > Linking/Unlinking and updating needed uniforms could be implemented in > osg::State ie through the mentioned shadercompositor-interface. > ... > > Cheers, > Johannes > > ------------------ > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=29409#29409 > > > > > > _______________________________________________ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
