Hi Ferdi, I did make a first pass at this, at least in terms of reusing modules in different shaders.
The glsl functionality has most the same tools as a C compiler. But is missing a few things. osg::Shader provides some the functionality C compiler and some functionality of the preprocessor ( #define etc ). It does not unfortunately support includes or the ability to set defines outside of source code ( that I've found anyway ) , however this can be worked around by prepending your #defines and the contents of your includes to the std::string contianing your source code before feeding it to the shader ( compilation ). Prepending unfortunately messes up the line numbers for debugging though. You can use setShaderSource to build your shaders from a std::string rather than loadShaderSourceFromFile in order to do this. Osg::Program provides the functionality of the linker, resulting in an executable. As such you can build up different osg::Shaders togather to make a complex system with plug in modules. You can have any number of Shaders in a Program, not just one of each type. Just make sure that you have only one main() in each stage ( Vertex, fragment, geometry ) of the Program. So you can have your lighting functions in one osg::Shader, your texture functions in another and then use them in different Programs. I think this saves memory on the graphics card too. Think of osg::Shaders as object files. As for combining algorithms, you just need to plan your interfaces to be general enough, just like when coding in C/C++. The functionality for this is already in OSG, it just isn't immediately obvious. OSG is pretty much a pass through of the OpenGL API, the only place it is less capable is that the OpenGL Shader can be created from multiple char* 'strings' to allow for 'includes', but osgShader can't. Admittedly I have never tried doing that in OpenGL, but the Orange book does mention it as the reasoning for multiple char*s. Colin. > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf > Of Ferdi Smit > Sent: 12 December 2008 13:39 > To: osg > Subject: [osg-users] higher level shader chaining support? > > Hello, > > Just a thought, have people looked at implementing some > higher level shader functionality in OSG? For example a type > of system that is described in GPU Gems 2 ( > http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter13.h tml ) or something similar to direct show (yikes) where shaders > and buffer resources have input and output pins that can be > dynamically connected. > On top of this a shader that mimics the fixed functionality > pipeline could be provided. In this way, various algorithms > requiring shader code can be implemented in a much more > general fashion. You simply connect to the pins you need > transparently. I find myself often writing algorithms using > shaders, and every single time I have to reinvent, program > and incorporate basic opengl lighting and texturing. Then > when you want to combine two of these algorithms everything > falls apart usually. > > -- > Regards, > > Ferdi Smit > INS3 Visualization and 3D Interfaces > CWI Amsterdam, The Netherlands > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce negraph.org > _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
