<div dir="ltr"><br>I'm going to avoid discussing header extensions, because it's a dead dog. I will say, that more tools and processes than just VS rely on file extensions.<div><br></div><div>I would like to throw out the concept of using something like Conan.io ( <a href="https://conan.io/">https://conan.io/</a> ) to assist with 3rdparty package management.</div><div><br></div><div>As we all know, OSG's breadth of appetite for third-party dependencies has made it daunting for people to build throughout history, and I'm sure that while VSG will be narrower in scope, it will still have the same issue.</div><div><br></div><div>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.</div><div><br></div><div>For example, Paul Martz, when he wrote a non-FFP scenegraph (called JAG <a href="https://github.com/pmartz/jag-3d/">https://github.com/pmartz/jag-3d/</a> ) a number of years ago, utilized BOOST, POCO and a math library named GMTL ( <a href="http://ggt.sourceforge.net/html/main.html">http://ggt.sourceforge.net/html/main.html</a> ). 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.</div><div><br></div><div>Jeremy Moles' Heirograph scenegraph (GL3+, GLES2+ and prototype Vulkan support) used GLM ( <a href="https://glm.g-truc.net/0.9.9/index.html">https://glm.g-truc.net/0.9.9/index.html</a> ) 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.</div><div><br></div><div>I am excited to look at the potential of bringing other OSG nodekits and tools to VSG.</div><div><br></div><div>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.</div><div><br></div><div><br></div><div><br></div></div>