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

[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. 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/8dccb323/attachment-0003.htm>