<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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>  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.</div><div><br></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><br></div><div>  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.</div><div><br></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>  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.</div><div><br></div><div>  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.</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>  Not too tough. There are some nodekits and libraries that may help you do some 2D work more easily too.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* 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><br>
<br>
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?<br></blockquote><div><br></div><div>  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.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
* 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>  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.</div><div><br></div><div>  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.</div><div><br></div><div><br></div><div>  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.</div><div><br></div><div><br></div><div><br></div><div>  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.</div><div><br></div></div><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div style="text-align:center">Chris 'Xenon' Hanson, omo sanza lettere. Xenon@AlphaPixel.com <a href="http://www.alphapixel.com/" target="_blank">http://www.alphapixel.com/</a></div><div style="text-align:center">Training • Consulting • Contracting</div><div style="text-align:center">3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 • GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL</div><div style="text-align:center"><span style="font-size:12.8000001907349px">Legal/IP •</span><span style="font-size:12.8000001907349px"> </span><span style="font-size:12.8000001907349px">Code Forensics •</span><span style="font-size:12.8000001907349px"> </span>Digital Imaging • GIS • GPS • osgEarth • Terrain • Telemetry • Cryptography • LIDAR • Embedded • Mobile • iPhone/iPad/iOS • Android</div><div style="text-align:center"><a href="https://twitter.com/alphapixel" target="_blank">@alphapixel</a> <a href="http://facebook.com/alphapixel" target="_blank">facebook.com/alphapixel</a> (775) 623-PIXL [7495]</div></div></div></div></div>
</div></div>