Robert Osfield wrote:
Even more complex would be making it easy for developers to integrate their
own shaders with the fixed-function-over-shaders later, so that their own
shaders could simply call a function to compute per vertex lighting values,
for example.
I think we should just bite away at this issue bit by bit.
I guess this really falls into the "new feature" category, as it's not
possible with OSG today on GL1/2 to mix FFP with app shaders. Therefore
not a requirement for OSG FFP-emulator shaders to mix with app shaders.
But definitely something to work towards.
> I think we should just bite away at this issue bit by bit. The first
> is to get the basics compiling without any cleverness w.r.t fixed
> function pipeline, then as we get more experience and understanding of
> the issue start introducing better support. I believe we do need to
> start providing reasonable equivalents for the fixed function pipeline
> as otherwise we'll be just pushing far more complexity down on to the
> application developers - they already have enough on their plate
> without expecting them to recreate the whole fixed function pipeline
> as well.
I think there are always going to be some developers that "just want OSG
to do everything" for them, without having to think too much about it,
and they will make heavy use of OSG FFP-emulator shaders. But there are
also developers that want full control, more direct access to the
hardware, with OSG used primarily for structure. Their numbers will grow
as the paradigm shift away form an FFP mentality continues. As long as
OSG can serve both groups' needs in an elegant manner that does not
inhibit performance, the community will be happy.
-Paul
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
