Man, there was some really great material written here. On Fri, Jun 23, 2017 at 1:38 AM, Robert Osfield <[email protected]> wrote:
> 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. > > On 22 June 2017 at 23:33, Andy Somogyi <[email protected]> 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? > > > > * 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 > > [email protected] > > http://lists.openscenegraph.org/listinfo.cgi/osg-users- > openscenegraph.org > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > -- Chris 'Xenon' Hanson, omo sanza lettere. [email protected] 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]
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
