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. Robert. On 27 November 2013 10:43, Sebastian Messerschmidt < [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 > [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
