Hi Robert, Reading your post, I'm thinking that if we forsee a failure in having an API agnostic OSG, then we may then change our mind and keep having a "close-to OpenGL" scenegraph, as for OSG 2. A good "OpenGL only" would be better than a bad "everything allowed". I hope we'll succeed in this "API agnostic OSG", but we should not be obstinated if we see it is not possible with our goals of having a good toolkit. In the case of the failure, maybe we could consider having an intermediate solution by supporting, for example, OpenGL-ES or OpenCL only (in addition to OpenGL).
Causes of the failure could be, as you mentioned: - Noticeable loss of performance - Noticeable loss of features - Unconvenient API And about the forecast: "Better sooner than later"... If we see it when planning or when in a prototyping phase, that would be - of course - much better. Thoughts? Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Wed, 25 Feb 2009 21:33:27 +0100, Robert Osfield <[email protected]> a écrit: > Hi Cory, > > On Wed, Feb 25, 2009 at 5:44 PM, Cory Riddell <[email protected]> wrote: >>I don't understand how anybody can think being OS agnostic is >> good, but renderer agnosticism is bad (ideologically). I do understand >> however, that development resources are scarce and the programmers get >> to work on whatever they want to work on. > > Being rendering agnostic is not ideal in terms of providing a thin > layer ontop of the underlying functionaliy, being rendering agnostic > requires you to abstract the interface from the implementation and in > doing so you loose the direct mapping which can help with both > performance and exposing underlying features in a flexible and > convenient way. The OSG has so far embraced the approach of this > very close mapping between OpenGL and equivalent OSG structures right > down to modes being direct pass through from osg::StateSet to OpenGL. > > By going rendering agnostic we loose this convenience and if we aren't > careful performance with it. It's really hard to get a good > rendering agnostic API that doesn't loose performance and drop > features to ensure a common denominator between APIs. Being rendering > agnostic is not free from cost, so it should be at all surprising that > one might be very wary of going rendering API agnostic. > > Once you do embrace being rendering API agonostic you carry the > overheads of this design approach for all time going forward, and > unless you really do need multiple rendering API's at the backend that > are going to be properly maintained they the costs of going agnostic > are far higher than that of sticking with the thin layer that the OSG > has right now. For us to make the move we have to ensure that we > both have a design that will work well, and we have the resources to > implement it and maintain it going forward. We also have to make sure > that we can carry the existing community with us on this journey. > > Robert. > _______________________________________________ > 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
