Hi Robert, The new shader composition feature seems really interesting. The code sample is easy to follow and at first glance it does appear to be simpler to work with than the previous osg::ShaderComposer implementation. However, as someone who has invested a lot of time and work into the older framework, I'd like to also voice my concern over your plan to deprecate/remove it.
I haven't had a chance to really dive into the implementation details, so forgive me if my concerns are completely overblown. Like David, I can't really provide a concise example program that demonstrates how I'm currently using the ShaderComposer framework. However, there are a couple features of the existing framework I'd like to point out that are absolutely critical for my use case. 1) Being able to override osg::ShaderComposer::getOrCreateProgram(). This is huge, because I can implement my own algorithm for composing shader code. It also gives me control of how the osg::Program object is generated and allows me to automatically apply uniforms based on the shader components. Another benefit is that I can implement my own shader caching strategy. 2) The osg::ShaderComposer object is called within the context of osg::State::apply. This is crucial, because it allows my composer to automatically apply textures based on the specified shader components. For example, if I wanted to add caustic lighting to the scene, my custom shader component would specify the caustic texture and shader code. The composer would then apply the texture to the next available texture unit and automatically apply the necessary sampler uniform. This makes it easy for us to define self contained shader effects that use textures, without needing to be aware of the scene and which texture units are available. This is also used for adding texture projected lights, ambient light cube maps, ramp-based lighting models, etc... If the new framework allows for such use cases, then great! If not, then I think it's reasonable to keep the old framework around for advanced use cases that require more low-level hooks into the scene graph. Again, the new framework looks great and I'm not criticizing it at all. I'm just worried about losing years of work I've invested into the old framework. Cheers, Farshid On Fri, Feb 13, 2015 at 7:00 AM, Robert Osfield <robert.osfi...@gmail.com> wrote: > Hi All, > > I have now checked in core OSG support for a new form of shader > composition that leverages #pragma's to extended GLSL shaders to specify > which #define's that it requires from the scene graph. The scene graph > passes these to the shaders via StateSet::setDefine(..) and provides full > support for the OSG's state override/protected options. > > I have modified the osgshadercomposition example to illustrate a very > simple example that utlizes three shaders checked into > OpenSceneGraph-Data/shaders trunk. So on the code look for > OpenSceneGraph/examples/osgshadercomposition.cpp and on the shader from > look at OpenSceneGraph-Data/shaders/osgshadercompostion.vert, > osgshadercomposition.frag and lighting.vert. > > I will write more later about how to use this new capability. It's gotta > be one of the coolest features added to the OSG for quite a few years :-) > > Cheers, > Robert. > > _______________________________________________ > 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
