[osg-users] Announcement: VulkanSceneGraph and SceneGraphTestBed!

[Robert Osfield]

Hi Sam,

On 5 June 2018 at 17:30, sam <brkopac at 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.