HI Wojtek,
On 19 February 2015 at 13:17, Wojciech Lewandowski <
[email protected]> wrote:
> I am not actively working with any code which would require shader
> composition at the moment but I saw few such efforts in various projects in
> the past, so I am really glad OSG is going to implement own scheme and
> users will not need to invent the wheel anymore ;-). As someone only mildly
> interested in the topic at the moment I only briefly looked at new shadow
> composition example, and have only one question.
>
> I noticed that we may add/override parts of shader code using setDefine(
> "USER_FUNC(args)" ) as in your example:
>
> stateset->setDefine("VERTEX_FUNC(v)" , "vec4(v.x, v.y, v.z *
> sin(osg_SimulationTime), v.w)");
>
> But I feel that this solution may be inadequate for large blocks of shader
> code which used would want linked instead of being effectively merged with
> parent "Ubershader" program.
>
You should be able to multiple line insertion using the standard multi-line
#define line ending of \
However for general code sanity I don't think large blocks of code should
be inserted into shaders this way - just because it's possible doesn't mean
it's sensible. What I'd do myself in situations like this would be the
have a separate shader that does the has functions that do bulk of the
work, and then have a define in the main that places the call the functions.
> Do you have a method or anticipate that such method can be added, which
> would allow to add or override whole shaders in effective Program applied
> to OpenGL context ? Something that ShaderAttribute was supposed to do in
> former ShaderComposition scheme ? For example whould this be possible to
> replace whole lighting.vert shader from your example with entirely
> different shader doing own lighting at some subnode and its StateSet ?
>
Right now #pragma(tic) shader composition can only select between all the
shaders attached to a single osg::Program, it can't insert/remove shaders
from elsewhere in the scene graph at runtime like the old
osg::ShaderCompostion was designed to do, or what VirtualProgram does.
However, if you do want to choose between different shaders for different
subgraphs what you can do is place all the shader possibilities in the
osg::Program that decorates the scene graph and then have the individual
shaders utilize the #pragma requires(..) functionality so that as you
provide the appropriate #defines in the different subgraphs then the
different shaders get linked to the GLSL program object relevant to that
subgraph.
The other approach is simply that have a separate osg::Program for the
subgraphs that want to specialize the shaders and that these local subgraph
osg::Program link in the osg::Shader they want for that subgraph. This is
the very old way of course... crude but it's always there as a fallback
solution.
What I'm keen to do is have a solution that gets a lot of functionality for
a small amount of complexity. Getting this balance right is hard. The old
osg::ShaderComposition approach was in theory very powerful, but the
complexity associated with understanding and using it make it prohibitive
to most users. It might be that we can simplify osg::ShaderComposition now
we have #pragma(tic) shader composition - for instance the whole code
injection side is effectively redundant.
Robert.
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
