Hi Farshid, On 16 February 2015 at 23:18, Farshid Lashkari <[email protected]> wrote:
> 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. > The OSG already only applies uniforms that are relevant to an GLSL program so even if you provide them in the scene graph, but not use them in the shade they will be ignored. This means you shouldn't need to go to the extra effort of applying/not applying uniforms as it'll already be done for you. Control of what elements go into the final GLSL program can now be controlled via the #pragma requires() functionality, so it moves the need to manage this side of things from the C++ code into the GLSL code. As the GLSL code is compiled at runtime it makes things more flexible. Development different shader combination no longer requires modifying C++ code and then re-compiling the app. Potentially you can even edit the shaders and their composition at runtime. > > 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... > The new shader composition functionality can easily toggle on/off shaders using the #pragma requires() functionality so it's now lightweight to just attach the shader to the osg::Program decorating your subgraph and have it appropriate define toggle/on off the feature when needed. Selection of the textures required or not required and associated uniforms is not something supported by the new functionality, but be managed via cull callbacks. An simpler alternative is to just decide which texture unit you are going to place a particular texture and assign it and the associated uniform for it. This could leaves gaps in the texture unit usage but there is nothing in OpenGL multi-texturing support that requires the units to be sequentially assigned. 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. > I will keep the old framework around for 3.4, but officially deprecated it. It might be parts of the old framework could be utilized in a future refinement of #pragma(tic) shader composition but for new users I don't want them trying to use something that is far more complicated than the functional benefit it provides. > 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. > If it took you years of work to get the old shader composition working then perhaps that's a sign that I got it wrong.... :-) What I'd appreciate a proper review of the new functionality with an eye to work out how all these various tasks can be solved. Certainly from the feedback about not removing osg::ShaderComposition has not been done from a basis of seeing how to utilize the framework, but from trying to fit the new functionality into the same boxes that the old functionality provided. #pragma(tic) shader composition is a very different beast. It moves control from C++ application code to GLSL shaders. So please guys, can you spend some time thinking about, and trying out the new approach in a constructive way. I want feedback on it. So far all I've had feedback is on my suggestion of removing the old functionality. Robert.
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
