Hi Paul, Jan, and Shayne, Okay, so admitting we're dropping D3D... Will the problem be similar for OpenGL-ES/OpenCL (I mean raytracing and such for OpenCL)? This is not ironic: I don't know much about these. But I wonder if we would have the same "abstraction" problem with them. I was thinking that if OSG 3 would support these, then why not others (such as D3D)... However, if they're quite close to OpenGL, then yes, the situation is different. We thus could think about OSG not as "API agnostic", but as "Khronos API agnostic" or such. Thoughts?
Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Wed, 25 Feb 2009 23:45:01 +0100, Paul Speed <[email protected]> a écrit: > 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 _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
