Hi Glenn, On 19 February 2015 at 16:21, Glenn Waldron <gwald...@gmail.com> wrote:
> Well.. the possibilities really are endless. Today in osgEarth there are > probably 15+ VirtualProgram modules for terrain alone, plus various others, > and support for including custom user shaders (http://goo.gl/I51FHv). > > What they have in common is a contract: a set of legal injection points > and function prototypes. None of these modules know about any of the > others, and the built-in main() functions don't know about any of these > modules beforehand. But as long as each one abides by the contract they > will work together. > > Perhaps a contract-based approach can be built on top of the new > #pragmatic system... that is what I am wresting with at the moment... Maybe > using #pragmatic one could specify some pre-defined injection points. > However it isn't clear then how you would inject multiple functions and > multiple modules using the #define approach, or how you'd support > overrides, etc. > One can place the #define's into the GLSL main()'s to serve as the pre-defined injection points and then have these populated by the StateSet::setDefine(..) methods. StateSet::setDefine(..) fully supports the OSG's established OVERRIDE/PROTECTED/ON/OFF functionality that exists for Modes, StateAttribute and Uniforms. One thing that isn't currently supported to pre-pending or appending define values to #define's that already have a value, so if one provides a value of the FS_END_OF_MAIN #define it can only take one value. Potentially would could add this ability but it'll complicate the API and implementation so unless it's shown we really need it I'll not implementation. With having lots of different shader possibilities, adding them all to a Program and only having the ones that are used linked (by utilizing the #pragma requires(..) functionality) should be efficient. However, since you will now at scene graph creation time what shader combinations are needed one should be able to just populate the topmost osg::Program with the all the shaders that are required and then have then enabled/disabled individually as required. I am optimistic that you could probably replace the old VirtualProgram approach in osgEarth with #pragma(tic) shader composition, but of course this could only be done for users using OSG-3.4, which really doesn't help you too much as it only exists in my future plans so far :-) I don't expect any issues with the two co-existing so it's not something we probably need to worry about for a good while. Cheers, Robert.
_______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
