Hi Glenn,
On 17 February 2015 at 21:56, Glenn Waldron <[email protected]> wrote:
> In my opinion the biggest problem that shader composition (SC) needs to
> address is the code maintenance nightmare of having to copy, paste, or edit
> other peoples' shaders in order to add your own functionality.
>
I don't we'll ever be able to get away from knowledge of other peoples
shaders, but if they are develop with adaptability in mind then extended
them is possible. An example below.
>
> So I am eager to understand how you will address that. How can I add a new
> shader component without editing the main() functions to support it? For
> example, take the shaders in the terrain displacement code. I want to add
> some gamma correction code into the fragment stage. Will I be able to do
> that without editing your shaders too?
>
The way to tackle this would be to add entry points into the original
shader via defines and using this make it possible to add in the extra
features you want. For instance the fragment shader could look something
like:
#pragma import_defines(FS_BEFORE_MAIN, FS_START_OF_MAIN, FS_END_OF_MAIN)
uniform sampler2D baseTexture;
varying vec2 texcoord;
#ifdef FS_BEFORE_MAIN
FS_BEFORE_MAIN
#endif
void main(void)
{
#ifdef FS_START_OF_MAIN
FS_START_OF_MAIN
#endif
gl_FragColor = texture2D( baseTexture, texcoord);
#ifdef FS_END_OF_MAIN
FS_END_OF_MAIN
#endif
}
So if you want to inject a some kind of processing you could do something
like:
stateset->setDefine("FS_BEFORE_MAIN","uniform blendColor;"
stateset->setDefine("FS_END_OF_MAIN","gl_FragColor = mix(gl_FragColor,
blendColor, blendColor.a);");
One could simplify the shader code further if one provided defaults of ""
for the FS_* defines so you wouldn't need the #ifdefs. I have considered
adding support defaults support via #pragma
import_defines(FOR_PROVIDING_DEFAULTS="0"), but have kept thing simple for
this first iteration.
There will be a limit to how can be done with shader composition without
replacing shaders wholesale, simple because complexity can quickly get out
of hand. When it comes to debugging shaders being able to review them in
their entirety is ideal, as soon as you start optionally adding bits in
knowing what might be going on diminishes. The use of defines like above
is preferable to trying to use generic code insertion (such as by using a
float as I did with osg::ShaderComposition) as even if you don't know what
the define will be substituted with you do at least know what order things
will be done in, and different blocks have specific meaning.
For osgTerrain displacement mapping it's possible to override the
GeometryPool::getProgram(..) so that you can subclass the pool and add in
your own osg::Program or add/substitute shaders into the program. This
gives one the ability to do the high level substitution or utilize the
#pragma(tic) shader composition or a combination of the two.
Robert.
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
