[osg-users] Investigating using OSG as a graphics backend for our real-time physics simulation system

[Robert Osfield]

Hi Andy,

I would have thought the OSG would work fine for your task, you have
happily mix and match 3D and 2D subgraphs (2D is just 3D in a single
plane.)  Portability is excellent as most of the code is pure C++ and
OpenGL.

As for for Tom Forsythe's blog, I can only guess he's never used a
professional grade scene graph that is well designed.

Long term future of the OSG is tied to OpenGL as it's designed from
the ground up as an OpenGL scene graph.  If were to try and generalize
it to handle multiple back-end API's we'd have to radically change
large parts of the API and implementation, backwards compatibility
would be lost and with it we'd bificate the community between the
OSG/GL version and the OSG/MultipleAPIs.

Apple have been moving away from cross platform standards towards
their own proprietary standards.  Metal probably doesn't have a great
future, if Apple drop the ball on the iPhone and it looses market
share it'll be histoy.  I suspect Direct3D is also tied to Microsoft
remaining relevant, they've lost the phone market and desktop isn't
growing. Personally I think the API best placed for the future is
Vulkan as it's cross platform and provides good threading and low
level control support.

Long term I see a Vulkan scene graph as being a successor to the OSG,
and on the OSG community part I think the best route would be such a
scene graph be developed to fit in with OSG in such a way that
existing OSG users can migrate across without having to dump on API
completely and start a fresh.  I've discussed my thoughts on this
topic extensively over the last two years, have done quite a bit
design work, but alas haven't had the time get the next OSG stable
release out so I have clear run at starting a new scene graph.

Quite a bit of my work on the OSG in the last year has taken ideas
that I came up with for the new scene graph so cross pollination has
already started.  My plan for the OSG is for it's API to be evolved
whilst avoiding major API breaks, so it'll be a stable base for
application for years to come.  My expectation is the new dev work on
the OSG should start to slow down with the majority of work being
maintenance.  The OSG is already 18 years old, users still pop up from
time to time about porting from OSG versions a decade old, so my guess
is that the OSG will be still be relevant to many users for quite a
few years to come.

Robert.


Robert.

On 22 June 2017 at 23:33, Andy Somogyi <andy.somogyi at gmail.com> wrote:
> Hi All,
>
> We're evaluating using OSG as a possible graphics backend for our real-time physics simulation project, and I've got a few questions:
>
> * We suport Mac, Windows and Linux, how good is cross-platform support with OSG?
>
> * It looks like it’s pretty easy is it to hook up Magnum to an existing native window, just would like to confirm. Say on Windows, I create a new Win32 window, or on Mac I create a Cocoa window, is it possible to hook up OSG to that window. I know that I'll have to grab the window events (mouse, resize, etc...) in my app and forward them to OSG, that's not a big deal. We'll be using the native toolkit on each platform for the gui, i.e. WPF on Windows, Cocoa on Mac and GTK on Linux, so it's important that we can hook up our rendering code to native windows.
>
> * Much of our application will entail displaying highly dynamic deformable elastic surfaces and particle systems with programmatically generated textures, do you thing OSG is a good fit? Does OSG have mesh node types where it’s easy from the CPU side to update vertex positions and add/remove vertices?
>
> * We also plan to do a bit of 2D drawing (objects in a tree structure), How easy would it be to also use OSG for 2D trees?
>
> * I think a scene graph approach would be a good fit for us, as I’ve worked a lot with open inventor in the past. Part of what we'll be doing will be constructive solid geometry, similar to OpenSCAD, http://www.openscad.org, and a scene graph we think is a good way to represent this kind of geometry. There are however some criticisms of scene graphs, namely Tom Forsythe’s blog: http://tomforsyth1000.github.io/blog.wiki.html#%5B%5BScene%20Graphs%20-%20just%20say%20no%5D%5D
>
> I would tend to disagree with Jon, as I conceptualize things in space as all relative to the original, and things relative to each other (I worked with robotic arm manipulation before, so I tend to think in terms of transforms). How would you guys respond do Jon’s issues?
>
> * It would appear that Apple, in their infinite wisdom (sarcasm) is slowly deprecating OpenGL in favor of metal. In the future, do you think OSG could have different backends (metal, directx)?
>
> Thanks,
> -- Andy
> _______________________________________________
> osg-users mailing list
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org