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

Fri Jun 23 08:44:10 PDT 2017

Man, there was some really great material written here.

On Fri, Jun 23, 2017 at 1:38 AM, Robert Osfield <robert.osfield at gmail.com>
wrote:

> 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
> _______________________________________________
> osg-users mailing list
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>

-- 
Chris 'Xenon' Hanson, omo sanza lettere. Xenon at AlphaPixel.com
http://www.alphapixel.com/
Training • Consulting • Contracting
3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 •
GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL
Legal/IP • Code Forensics • Digital Imaging • GIS • GPS •
osgEarth • Terrain • Telemetry • Cryptography • LIDAR • Embedded • Mobile •
iPhone/iPad/iOS • Android
@alphapixel <https://twitter.com/alphapixel> facebook.com/alphapixel (775)
623-PIXL [7495]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20170623/84fe3ea9/attachment-0003.htm>