I was mostly suggesting POCO in terms of all of the support code that it provides for the parts outside the core scenegraph. But I understand that that's not what you're focusing on right now.
On Thu, Jun 7, 2018 at 11:55 AM Robert Osfield <robert.osfi...@gmail.com> wrote: > Hi Chris, > On Thu, 7 Jun 2018 at 17:24, Chris Hanson <xe...@alphapixel.com> wrote: > > I would like to throw out the concept of using something like Conan.io ( > https://conan.io/ ) to assist with 3rdparty package management. > > For the current phase of work I don't plan to look at package > management, my current focus is on Vulkan, C++ and scene graph design. > Once we actually have a prototype scene graph to play with we can > start to think about ancillary issues. > > For the initial work my aim is to only have C++11 and Vulkan as > dependencies. > > > I would like to do whatever is feasible to make this new scene graph > more easily approachable by new developers, as I think it speeds adoption > and spread. I applaud the idea of using things like language-core thread > features and possibly existing platform libraries like BOOST or POCO to > supply technologies that are already-invented. I think this will greatly > simplify the codebase and reduce the potential for novel error. > > I haven't seen any compelling reason to make Boost a dependency. > With C++11 there even less reason to think about Boost as all the most > valuable parts are parts are in C++. > > I'm not familiar with with POCO, but a quick search online makes me > wonder why you suggested it. It doesn't seem related to the core > issues scene graph design/implementation. > > For something to be made of dependencies of the core VulkanSceneGraph > it will offer very significantly level of value to the core scene > graph. > > > For example, Paul Martz, when he wrote a non-FFP scenegraph (called JAG > https://github.com/pmartz/jag-3d/ ) a number of years ago, utilized > BOOST, POCO and a math library named GMTL ( > http://ggt.sourceforge.net/html/main.html ). JAG also had linkage to OSG, > allowing it to use OSG to load a file, then a visitor to traverse the > loaded graph and rewrite it into a JAG graph. OSG's support for Performer > in the early days allowed this same sort of bootstrapping trick, I believe, > until OSG had its own diversity of native loaders. > > > > Jeremy Moles' Heirograph scenegraph (GL3+, GLES2+ and prototype Vulkan > support) used GLM ( https://glm.g-truc.net/0.9.9/index.html ) instead, > because the syntax of the math library is exactly the same as GLSL's. Not > sure if that's good or bad, but both those libraries are pretty bulletproof. > > I did look at GMTL a long while back, and recently looked at GLM. > While I can see some value in GLM for some users it's a huge set of > code for what it is, or at least what we'd need from it for doing a > scene graph. > > I strongly want to keep the scene graph small, coherent and focused, > not splurge all over the place with monster dependencies, each with > their own set of style/ > > > If you think looking at the Heirograph design would be helpful, I might > be able to make that happen. The concept there was to have a modular API > backend to potentially support GL3/4, GLES2/3 and Vulkan all on the same > library platform. I don't know if that's relevant anymore, but I think the > idea of decoupling the graph architecture from the graphics API backend > driver is compelling in that it would help adapt to any future API > evolutions as well, and could leave the door open to things like Apple's > Metal, DirectX (Microsoft's Hololens / UWP currently only supports the DX > platform for 3D), etc. And I think it's good abstractional architecture > decoupling too. > > Previously I've considered design and implementation issues of > supporting multiple API's in a scene graph and feel that it comprises > the design and complicates the implementation. > > Vulkan is very different from OpenGL, it needs a different way of > managing things, it deserves a dedicated scene graph to make the most > of its capabilities without compromise. > > Cheers, > Robert. > _______________________________________________ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > -- Chris 'Xenon' Hanson, omo sanza lettere. xe...@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 • Forensics • Imaging • UAVs • 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 osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
