Hi Sebastien,
Thanks for the modified files. Will be reviewing them this afternoon.
Will there be some mechanism creating a new program object when add a
> define somewhere below an existing program, like the shader composition did?
>
That's my intention. The per context program object will contain a list of
GL program object id's, one for each configuration of defines so far
applied. As new combinations are introduced a new problem is
compiled/linked, but if one has already been created for that combination
then it's reused.
> Also i'd like to undefine on the way/ remove a define/ clear the
> define-set somewhere in the hierarchy, will this be covered by ON/OFF,
> OVERRIDE/PROTECTED mechanism of the state-attribute?
>
Yes, this will be possible via:
stateset->add/setDefine("MY_DEFINE", osg::StateAttribute::OFF);
Or at least that's my thought. Effectively the Define will behave a bit
like StateSet::setMode(...). You'll also be able to associated values with
a define too i,e.
stateset->addDefine("BASE_COLOR","vec4(1.0,0.0,0.0,1.0)");
Which be automatically included in GLSL shader, that have a "#pragma
import_define(BASE_COLOR)" to give you:
#define BASE_COLOR vec4(1.0,0.0,0.0,1.0)
And used there after in the GLSL:
#ifdef BASE_COLOR
vec4 mycolor = BASE_COLOR;
#else
vec4 mycolor = vec4(1.0,1.0,1.0,1.0); // optional fallback
#endif
Whole shaders can be optionally included in the Program as well, via the
#pragma requires(MY_DEFINE), so if no MY_DEFINE is provided in the
osg::StateSet hierarchy in the scene graph then it won't link that shader.
This is useful if you have a osg::Program that contains a geometry shader
that you want to toggle on/off when it's needed or not.
> For example:
>
> Group (with osg::Program X in stateset)
> | |
> | stateset A with define dA ->program with code of X and defines dA
> | |
> | ...
> | stateset B with define dB -> program with code of X and defines dA & dB
> |
> stateset C with define dC -> program with code of X and define C
>
Yep, that's the idea at least. Have to implement it now :-)
What this approach should assist is provided uber osg::Program at the top
of subgraph that can lots of different options just like the fixed function
pipeline currently does.
To tie the approach into the old fixed function pipeline approach I'm also
thinking about define name to GL enum value mapping, so for instance doing
a stateset->setMode(GL_LIGHTING, osg::StateAttribute::ON) would be mapped
to a "GL_LIGHTING" define.
Robert.
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
