On Wed, Feb 18, 2015 at 3:16 PM, Robert Osfield <[email protected]> wrote:
> Hi Glenn et. al. > > Today I've been revisiting the osgTerrain::DisplacementMappingTechnique, > GeometryPool and associated shaders to make better use of the new > #pragma(tic) shader composition. I haven't completed this work yet, but > attached are the two main shaders I'm working on, these are where the bulk > of the different options are for handling different numbers of colour > layers, optional height fields etc. are. I have been able to replace > combine two original vertex main shaders into one, and four different > fragment main shaders into one. I have attached the shaders to > illustrate my work in progress. > > Previously the GeometryPool had to manage the selection between the > different combinations of shaders and create a different osg::Program for > each combination, while now I will be able to remove all this C++ code for > management of shaders and replace with simply StateSet::setDefine(..) to > toggle the various features on/off. This toggle on/off of features can be > generic - just needing to know the name of the feature to toggle, it won't > need to know about GeometryPool or where it's attached different Programs. > This is big advantage as it decouples the C++ implementation details from > the interface. The C++ implementation is also simpler so will be easier to > understand and maintain going forward. > > Once I've got the DisplacementMapping/GeometryPool code sorted (hopefully > by end of tomorrow) I'll check it all in and provide others a more complex > illustration of how to use the new form shader composition. > > The work I did on osgVolume in 2013/14 managed it's own local management > of different shader combinations - osg::ShaderComposition just didn't fit > the problem I was trying to solve so ended up creating a local code to > solve the problem. However, this work would be an ideal candidate for > converting to use #pragma(tic) shader composition, implementing it should > be able to remove C++ code and make the shaders easier to manage. Once > I've done this it should also be an example that members of the community > can use as inspiration. > > A note for Glenn, could you give me an example of what type of > modifications to the attached shaders you'd like to add in - just sticking > the GLSL code you want to add directly into the GLSL without any of the > #ifdef etc. would be fine. Knowing what type of GLSL you want to inject > will help me know what entry points would be useful to add to the shaders > to give you the ability to customize them. > > Cheers, > Robert. > 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.
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
