Hi Sam, On 5 June 2018 at 17:30, sam <brko...@gmail.com> wrote: > Regarding SceneGraphTestBed are we looking to have a library to help > facilitate testing? What is the current vision for the test repository.
I am open to suggestions and support. My motivation is that both the OpenSceneGraph and VulkanSceneGraph need testing and doing it in one coordinated way could help both projects. OpenSceneGraph is feature rich and has lots of loaders but still needs testing. VulkanSceneGraph right now has no code, no features, no loaders, but over time these will be expanded and progress towards OpenSceneGraph feature wise. However, I don't plan for VulkanSceneGraph to have all the NodeKits and niche features that OpenScenGraph, these instead will be something for high level frameworks or add on libraries. As VulkanSceneGraph is developed it will be rarely useful to have a set of existing tests for it to use as concrete goals that we can work towards. I can envisaged creating an OpenSceneGraph test program that tests an OpenSceneGraph/GL feature set, then this test becomes a target for replicating as the VulkanSceneGraph is developed. For instance we might have a quad tree scene graph and we want to test culling performance of the scene graphs traversal and culling. Another test might be a specific render to texture technique like distortion correction or shadows. One could create dozens of different tests, or simply have one test program that loads many different types of data. One possibility I have been thinking of is to create a scene graph builder interface that has a lua front end that we can use lua scripts to build scene graphs and run tests. This scene graph builder interface would then have a scene graph builder backend, one for OpenSceneGraph, one for VulkanSceneGraph then at runtime one can select either or both and then test the resulting scene graphs. Another extension to this could be doing loading data and imagery using the OSG, but then pass this in as input into the scene graph builder than abstracts away from the OSG specifics. These are just ideas right now, nothing more than a git repo making intent as this stage. -- As a bit of background, in the early days of the OSG I was lucky to be using Performer for my day job so I got to test models like Performance town and just for fun set myself a goal of implementing all the features used in Performer town - so LOD's switches, sequences and a range of GL state that originally the OSG had none of. Once I could load and render the town so it looked the same of performer the issue of performance become apparent - the OSG was getting ~1fps while Performer got 60fps+, which then spured me to on to implement culling, state sharing, state sorting, lazy state updating until eventually the OSG performed just as well. This process of having a full featured scene graph to compare to was a really helpful yardstick to measure against. The OSG wasn't attempting to be Performer, it was headed in it's own design direction wise, but it still needed basic features to serve the needs of the vis-sim market, so knowing what these were was a big step up. As the OSG developed new challenges were brought forward by the community and clients that forced it to evolve in more scalable and flexible ways too. For the VulkanSceneGraph I'd like to use the same practical feature/performance benchmarks to aim for, measurable goals are so much more effective for software design than marketing bullet points. For the future VulkanSceneGraph user community being able to define in practical terms what features you'd like to see would be a good way to measure up progress against it. As we have a really powerful scene graph to work with already we should be in a good position to leverage it to provide such benchmarks. I hope this makes sense, Robert. _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
