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

[Andy Somogyi]

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-...@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[Jan Ciger]

Hello,

I am sure Robert as the project's leader could give better answers, but here is what I have learned in my use of OSG over the years.

On Fri, Jun 23, 2017 at 12:33 AM, Andy Somogyi <andy.s...@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?

OSG runs on pretty much anything that has OpenGL implementation and working C++ compiler. At the very least Mac, Windows, Linux, & Android are supported. 

 

* 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.

AFAIK, yes - there are examples for doing this in the OSG source code.

 

* 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?

osg::Geometry is what you want. Alternatively you could create your own shape type and do the rendering exactly as you want.

 

* 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?

It can be done but OSG doesn't have much support for drawing 2D primitives, like lines, rectangles, text and such. You will want to use some toolkit on top of OSG for doing this unless your needs are really basic. E.g. the Qt library has good 2D support, if you want some really custom drawing then Cairo works fine.

 

* 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

Tom Forsythe's blog is both old and also coming from a totally different use case. Namely videogame and game engine development. That is very much a different environment, there it is common to write your own STL replacement, memory allocators, not use standard library functions and write as close to the metal as possible in order to squeeze every last drop of performance. He is railing not so much against scenegraphs but against using any graphic frameworks.

That is appropriate if you are writing a new engine for every game or at least significantly "optimizing" it (as it has been common at that time) but not so much appropriate when the resource constraints are not as tight and other factors are more important - such as longterm maintainability of the codebase. A typical game gets shipped and 6 months later nobody has heard about it anymore. So nobody cares that the code is full of dirty hacks and kludges because the team has long moved on to something else by then. 

With something like OpenSceneGraph or (SGI's Performer before it) it is common to support a project for 10+ years. So longterm maintainability of the codebase is a must. That doesn't mean that the code has to perform poorly only that squeezing out every last bit of performance is less important because 6 months later you buy a much faster graphic card anyway. 

In the end, I believe the market has proved him wrong. A lot of AAA titles today are based either on the Unreal Engine or Unity3D (not in the least due to the very liberal and cheap licensing which hasn't been available in 2011). And both of those engines use scene graph architecture, at least in part.

* 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)?

I believe the standard will be Vulkan, Metal is Mac specific, I don't see that getting much of a traction outside of Mac community so for a cross-platform toolkit it is a nonstarter. Microsoft has managed to get their DirectX out there at the time by both actively sabotaging OpenGL implementation in Windows and by dominating the market, so vendors didn't have much choice but to support it. Apple is nowhere near that position. 

I don't think OSG will get backends for different graphic APIs because it is too close to the OpenGL api. Bolting on OpenGL idiosyncrasies on top of something like Metal, Vulkan or Direct3D would be rather inefficient way to do it. 

However, there has been a talk of a separate scenegraph implementation based on Vulkan. 

Regards,

Jan

[michael kapelko]

Hi.

* Cross-platform support. In short, OpenSceneGraph runs everywhere
with only a bit of configuration. I currently work on the
cross-platform guide for OpenSceneGraph to cover major platforms:
https://github.com/OGStudio/openscenegraph-cross-platform-guide

* Embedding. OSG-Qt integration works on all desktops (I have not
checked other platforms).

* Back-end. There are rumors that Vulkan driven scene graph may appear
in the future.

* OpenGL deprecation. Apple is actively pushing Swift, but Swift still
has no stable ABI and most of Apple's own software is still in
Objective-C. I'm sure OpenGL is here to stay for at least a decade.

[Chris Hanson]

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?

  Excellent. We just ported a client's OSG application from Windows to Linux in about two days. Mostly it was dealing with instances where it was using standard library called via their Windows-bastardized names, with a lot of #ifdefs to call them by their industry standard names. We noted to the client that we could probably port nearly effortlessly to Mac, but Mac is not one of their near-term requirements.

* 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.

  Yes. I'm not sure what "Magnum" is, but OSG can bind to existing Windows very well, especially using the GraphicsWindowEmbedded class. There are interfaces and examples for using things like Qt as well, which many of my clients use and love.

* 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?

  Yes, and no. You may want to consider using buffer objects and shaders that bypass piping the geometry to OSG itself on each update and instead pass a dynamically updated buffer direct to the GOU where a tesselation shader constructs the desired mesh from the dynamic buffer data. This will be much more efficient than having OSG itself potentially restructure the scene graph on each update, if you kjnow the updates will be restricted and well defined.

  Textures are easy to update on the fly in OpenGL, or if they are programmatically generated, you might generate them on the fly in a GLSL fragment shader.

 

* 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?

  Not too tough. There are some nodekits and libraries that may help you do some 2D work more easily too.

 

* 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?

  I'd tell Tom F to go do his own thing. Yes, most of the issues he mentions are true. A scene graph is not a magical fairy wand that makes everything optimally wonderful. The OpenGL hardware and APIs we use today are hugely different from those of the years when OpenGL and OSG were first wed. But it doesn't change the fact that OSG still does some fantastic stuff. Structuring a graph is an important design decision that the Scene Graph can't decide for you. And state change minimization may or may not be that big of a deal (on mobile OpenGL ES devices it may be much more significant than desktop brutes). OSG is actually way more than a graph and traversal and render library. It has loaders, animators, pagers and a huge body of support code surrounding those core kernal components. Those accessories are almost more valuable than the actual graph. And OSG is so open, you can customize and override almost any aspoect of its operation that you dislike or need to change.

 

* 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)?

  It is unlikely that OSG will have multiple backends. Strategies for accomodating Metal and Vulkan have been theorized. We (AlphaPixel, led by Jeremy Moles) have done some work on a prototype successor design that implements OpenGL ES, OpenGL 3+ and Vulkan. It's not production ready, but it's wandering down that direction.

  For now, OpenGL is not going away at all, and continues to improve, so OSG is a damn safe bet. OSG continues to grow and improve and is the absolute best at what it does today.

  FWIW, we (AlphaPixel) and Robert Osfield have both worked on a CSG/CAD based application (the same one, even, though not at the same time) implemented using OSG and a commercial CSG CAD library. It works well, once you think about rendering structure as being sometimes different than CSG/CAD heirarchy. I don't think I'm supposed to name the app publicly, but you may have even seen it and be aware of it if you are skilled in the art of the industry.

  If you want to discuss this with more bandwidth and lower latency, I'd be happy to call you sometime, no obligation, just to chat about what working with OSG is really like.

--

Chris 'Xenon' Hanson, omo sanza lettere. Xe...@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 facebook.com/alphapixel (775) 623-PIXL [7495]

[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.

[Chris Hanson]

Man, there was some really great material written here.

> osg-users@lists.openscenegraph.org

> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list

osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[Andy Somogyi]

Wow, thanks, that's some great information indeed.

The OSG community seems really great, and is a huge selling point.

I guess I'm going to have to write a prototype of my engine using both OSG, and Magnum, http://mosra.cz/blog/magnum.php

They both seem like great choices, but with different philosophies, going to have to try both to see which ones a better fit.

Thanks again for all the great info!

_______________________________________________

[Chris Hanson]

Magnum looks pretty cool. I'd be a little worried about the maturity of the codebase, but if it does what you need, try it out and let us know how it compares.

> osg-...@lists.openscenegraph.org

> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list

osg-...@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

--

Chris 'Xenon' Hanson, omo sanza lettere. Xe...@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 facebook.com/alphapixel (775) 623-PIXL [7495]

_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[Jan Ciger]

On Mon, Jun 26, 2017 at 4:07 AM, Chris Hanson <xe...@alphapixel.com> wrote:

Magnum looks pretty cool. I'd be a little worried about the maturity of the codebase, but if it does what you need, try it out and let us know how it compares.

I have looked at it as well, but it looks very much like a one-man project. Most of the 18 Github contributors have submitted only a patch or two. It could be a very nice engine but I would be worried about its longevity - the moment the principal developer moves on to something else it will likely die. May not be a concern for a one-off project but I would have to think very hard before getting invested in it too deeply - one could end up maintaining that project too or face another migration to a different engine.

J.