Hi Robert,
Hi Sebastian,
I think modifications to the core OSG are appropriate, and probably
best to do them incrementally. My first thought along the lines of
your item 1 suggestion would be change State/State.cpp so that instead
of caching the shader components in the AttributeStack via
the last_applied_shadercomponent member variable (search for it's
usage in the header and .cpp) and passing this on in the list of
ShaderComponents to the ShaderComposer one could instead get the last
applied StateAttribute's from the AttributeStack and pass these as a
list of StateAttribute onto the ShaderComposer instead. The
ShaderComposer could then get the ShaderComponents form the
StateAttribute as it deems fit.
This approach would allow one to create a custom ShaderComposer that
casts the StateAttribute and does any special handling it wants or
simply pass on the ShaderComponents attached to the StateAttributes.
Subclassing from ShaderAttribute to add the binding you want is
possible, or just adding them directly. In the first instance I'd
suggest we look at refactoring osg::State/ShaderComposer to handle
StateAttribute rather than ShaderComponents, and then discuss the
evolution of ShaderAttribute.
Okay I can try to refactor it, but I'm not 100% sure if I got you right.
Would the caching attribute (last_applied_shadercomponent) still be used
then?
Also do you mean by "get the last applied StateAttribute's from the
AttributeStack" to use the last_applied_attribute member?
cheers
Sebastian
Robert.
On 27 November 2013 10:43, Sebastian Messerschmidt
<[email protected]
<mailto:[email protected]>> wrote:
Am 27.11.2013 11:15, schrieb Robert Osfield:
Hi Sebastian,
Thanks for the details, still not 100% clear but clearer ;-)
The ShaderComponent class exists as an interface between
StateAttribute's and the ShaderComposer in a way that is
decoupled enough to allow fixed function pipeline style
StateAttribute's to provide a ShaderComponent to implement itself
in the shader realm. It sounds like this decoupling is a bit too
one way for you needs and that you want to be able to get the
StateAttribute/ShaderAttribute that owns the ShaderComponent,
holding a parent pointer in the ShaderComponent might be a quick
fix for this but this would preclude StateAttribute's sharing
ShaderComponents which really is desirable, the next alternative
would be pass in the StateAttribute directly tot he
ShaderComposer and let it get the ShaderComponents from the
StateAttributes on demand.
Thoughts?
I don't necessarily need the provoking ShaderAttribute, but right
now there are no means to set up the binding information (attrib,
fragData) whatsoever.
I see a couple of options here.
1.) let the ShaderComposer see the provoking ShaderAttributes
when calling addShaderToProgram.
This way one could transport custom information via ShaderAttribute.
2.) Extend the ShaderAttribute so it can hold the bindings to be
applied.
This would be the most fitting implementation, but would require
maintaining osg::Program alongside with ShaderAttribute if new
features are introduced. (Which I expect to happen with newer (>2)
versions of OpenGL)
3.) Add a callback mechanism which lets you inspect the Program
and shaderAttributes before it is pushed to the graph.
This seems more like a hack to me, as it is essentially 1) without
the benefit of letting the Composer decide.
So i'd really stick to version 1.) + 2.)
I'll try to explain what I want to achieve with ShaderComposer:
Imagine a multipass rendering scheme where a lot of rendering is
done to FBO.
The shaders for the passes are all like this:
#ifdef USE_TANGENT_SPACE
normal = ...
#else
normal = ...
#endif
,...
#ifdef FANCY_COLOR
color *= vec4(1,0,0,1)
#endif
So I derived the ShaderAttribute and gave it the means to inject
the #define tokens for different shader combinations.
This works very well, except for the fact, that I'm not able to
set the bindings to the osg::Program produced. So I'm stuck here.
That's why my next step was to inherit the ShaderComposer with the
hope that I somehow can access the ShaderAttribute to setup the
bindings.
Option 2) would help me to bind the default bindings
Option 1) would me allow to perform the binding on my own in the
composer and possibly other things derived from the ShaderAttribute.
cheers
Sebastian
Robert.
_______________________________________________
osg-users mailing list
[email protected]
<mailto:[email protected]>
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
[email protected]
<mailto:[email protected]>
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
