I was originally attracted to OSG because it was "to the metal". There
are many scene graphs and "engines" that abstract away the rendering
engine. They either suffer from a least-common-denominator effect or
they are so high level to have abstracted all of the really juicy bits.
In the latter case, you tend to become beholden on them to implement
new features.
In OSG, when a new extension comes out, it's pretty straight-forward to
figure out how it fits in.
I'll admit that the last time I did any D3D programming was a while
back. (Maybe DX8 was still new timeframe.) Still, the mindset of D3D
programming was very different from OpenGL. I don't expect that this
has changed much with DX9/10.
For me, if I were to build my own engine versus licensing quake, unreal,
source, whatever... and if I cared about cross API support (why would
I?) then I'd abstract at the engine level and build my own scene graph.
Anything that isn't already "to the metal" isn't customizable enough.
Things like OSG really are very extensible but tied to an API.
Abstracting above the scene graph is not as beneficial. More likely,
I'd decide to be cross-platform and build to OpenGL. Or I'd decide to
be windows specific and build to D3D. (Xbox arguments aside for the
moment.)
There has to be a reason more of these cross-api scene graphs don't
exist... but a google search for api-specific ones yields plenty.
-Paul
Sukender wrote:
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
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
