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

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

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20170623/8d9d5354/attachment-0002.htm>