Excellent news. Definitely keep me posted on this, as I have a client
that has funded this work and needs the functionality. I'll need to make
sure that any designs you have will fill their requirements. Sounds like
it will, but if it doesn't, I'll need to spend some cycles on an
alternate implementation.
-Paul
Robert Osfield wrote:
Hi Paul,
Just for clarification, osgUtil::ShaderGen isn't a prototype for
shader composition in the OSG. It just a utility visitor submitted by
Maciej Krol to help out getting fixed function pipeline scene graphs
to work with shaders. For the GLES2 I've used ShaderGen as a tool to
do testing, it's not something I'm planning relying upon for the long
term.
I don't know what form shader composition will make it into the core
OSG, but in whatever form it takes it'll have to enable similar
convenience to the current fixed function pipeline in that
enable/disabling and inheriting/overriding features will need to be
supported, as well as the ability to substitute individual shaders,
create custom configurations that can be enabled/disabled, and simply
replace the whole lot using user defined osg::Program. The CPU
overhead for all of this will have to be kept to minimum - we have to
avoid performance regressions as we migrate from FFP to shaders.
Once I've got pending submissions merged and a dev release out I'll be
spending some time just looking at how we might tackle shader
composition and provide default shaders that are equivalent to the
fixed function pipeline. Hopefully I'll be able to see some way
through the tangled maze. I'll keep the list informed of how I get on
with this.
Robert,
On Wed, Nov 18, 2009 at 5:53 PM, Paul Martz <[email protected]> wrote:
Mathias, J-S -- Thanks for taking me down this thread, it has caused me
to do some serious thinking about some upcoming work I have to do for a
client, and re-think what my real objections are to something like
ShaderGen.
OpenGL 3 gives developers a blank canvas with no restrictions, but
ShaderGen reimposes the restrictions of the FFP that OpenGL 3 removes,
by providing a way for developers to stay locked in an FFP-centric
mentality. By even having something like ShaderGen in OSG, it implies,
to me at least: "OSG is not forward-looking".
However, it is undeniable that functionality present in the old FFP is
useful, after all, it was around for more than a decade. So maybe if we
could find a way to enhance ShaderGen so that it exposes the freedom
available in GL3 but also provides shader-based FFP equivalents, then that
might be a very good tool.
I'm envisioning an infrastructure that supports modules of shader code
scattered throughout the scene graph, tagged to identity the functionality
they implement. It would have "slots" for all FFP features, but also the
capability to add custom features not present in the FFP. There would be
some reasonable FFP defaults like ShaderGen has, but the app could supply
its own lighting shader code module, for example, if desired. There would be
a default main() that would implement FFP, but the app could specify its own
main() to go beyond what is possible with the FFP, such as accessing custom
features.
Does this sound like it would be a good system? I'd be interested in hearing
your thoughts on this concept.
-Paul
_______________________________________________
osg-submissions mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
_______________________________________________
osg-submissions mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
_______________________________________________
osg-submissions mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
