<div dir="ltr">Hello,<div><br></div><div>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.<br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 23, 2017 at 12:33 AM, Andy Somogyi <span dir="ltr"><<a href="mailto:andy.somogyi@gmail.com" target="_blank">andy.somogyi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi All,<br>
<br>
We're evaluating using OSG as a possible graphics backend for our real-time physics simulation project, and I've got a few questions:<br>
<br>
* We suport Mac, Windows and Linux, how good is cross-platform support with OSG?<br></blockquote><div><br></div><div>OSG runs on pretty much anything that has OpenGL implementation and working C++ compiler. At the very least Mac, Windows, Linux, & Android are supported. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
* 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.<br></blockquote><div><br></div><div>AFAIK, yes - there are examples for doing this in the OSG source code.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">* 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?<br></blockquote><div><br></div><div><br></div><div>osg::Geometry is what you want. Alternatively you could create your own shape type and do the rendering exactly as you want.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* 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?<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
* 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, <a href="http://www.openscad.org" rel="noreferrer" target="_blank">http://www.openscad.org</a>, 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: <a href="http://tomforsyth1000.github.io/blog.wiki.html#%5B%5BScene%20Graphs%20-%20just%20say%20no%5D%5D" rel="noreferrer" target="_blank">http://tomforsyth1000.github.<wbr>io/blog.wiki.html#%5B%5BScene%<wbr>20Graphs%20-%20just%20say%<wbr>20no%5D%5D</a></blockquote><div><br></div><div><br></div><div>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.</div><div><br></div><div>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. </div><div><br></div><div>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. </div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">* 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)?<br></blockquote><div><br></div><div>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. </div><div><br></div><div>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. </div><div><br></div><div>However, there has been a talk of a separate scenegraph implementation based on Vulkan. </div><div><br></div><div>Regards,</div><div><br></div><div>Jan</div></div></div></div></div>