Hi Robert,
Hi Sebastien,
(SebastiAn ;-)
That's really great news and I cannot wait to replace my messy code with
such core feature :-)
If you need help testing/use cases, feel free to contact me.
Cheers
Sebastian
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
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
