Prototype Phase Work Plan

The aim of the Prototype Phase, October-December 2018, is to fill out prototypes for main elements of the core VSG scene graph library, add-on libraries and test programs. These prototypes will help solidify the choices in supporting technologies used and the design and implementation approaches used.

General project infrastructure

We need to flesh out the following high level project infrastructure:

• Layout used in core, add-on and supporting applications/examples.
  • Follow FOSS Best Practices
• Conventions (naming, coding style etc.) used in core, add-on and supporting applications/examples.
  • Follow CppCoreGuidlines
• Website(s) - what requires dedicated websites, vs embedded in git-hub repositories.
  • Initial approach to see how rich the experience can be with just README.md etc.
• Developer/Community discussion forum(s)
  • Create googlegroup VulkanSceneGraph Developer Discussion Group
• 3rd party tools used in development and testing
  • Static code analysis (cppcheck added 19.10.18)
  • Dynamic analysis such as LLVM sanitizers and valgrind

Core Scene Graph development

Core scene graph work will be primarily tackled by Robert Osfield.

• Support for object serialization and reading/writing to native ascii/binary format.
• Creation of vsg::Array2d (completed), vsg::Array3D (completed) classes to mirror the existing vsg::Array class to enable more streamlined support for texture data.
• Create a unified memory allocator interface to enable custom memory allocation for both scene graph objects and Vulkan objects. Need to bring together the current vsg::Allocator and VkAllocationCallbacks
• Flesh out more RecordTraversal class that traverses the Command Graph recording commands into a CommandBuffer, integrating culling.
• Investigate unifying the vsg::QuadGroup and vsg::Group classes using a small size array optimization approach. Currently vsg::QuadGroup with is fixed size children array is faster than vsg::Group for creation and traversal, but is less flexible. Can we avoid the user space complexity of having two classes using small size optimizations?
• Restructure the scene graph level Vulkan object creation to use on-demand Vulkan object creation to enable handling of multiple logical devices and scene graph creation prior to viewer/logical device setup.
• Restructure the viewer/window level Vulkan object creation so that it uses a more standard MyClass::create(..) API and returns a vsg::ref_ptr rather than a vsg::Result. Use exceptions to handle errors.

Cross platform support

The initial development work has been done under Linux, with support for additional platform to be tackled in the prototype phase. Cross platform work to be led by Thomas Hogarth.

• Initial Windows support was added in October, this will be refined to provide as straight forward developer experience as we can achieve.
• Development of platform specific Windowing support to replace the dependency on GLFW (done.)
  • Win32_Window native windowing class for Windows
  • Xcb_Window native Windowing for Unices
• Port to Android : completed with vsgExample/Android example illustrating how to create an Android application
• Port to macOS near completion (just key events left to resolve) with native windowing provided by MacOS_Window.mm

Add-on library development

Add-on libraries will provide image and 3d model loaders, and integration with 3rd party software.

• osg2vsg OpenSceneGraph/VSG integration support library:
  • Convert existing osg::Image loading/vulkan object creation to use vsg::Array2D(completed)/3D
  • Basic support for converting osg::Node scene graph objects to vsg::Node equivalents
• vsg*Image - possible integration of the 3rd party image readers/writers
• vsg*Model - possible integration of the 3rd party model readers/writers
• vsgGLSLang - possible integration with the GLSLslang library for reading GLSL shaders and converting to SPIRV shaders compatible with Vulkan/VSG.

Example/Testbed development

All the software developed above needs testing, so we need to continue to expand the list of test applications that can test both the API usage and runtime behaviour/performance. Testing software is the primary focus during the Prototype Phase so applications developed during just as examples will not be attempted. The test programs can still serve as examples for others to learn from. Two main places for testbed development will be:

• vsgExamples - a set of test programs that will later evolve into our example set. Unit tests will likely need to be spawned off this project, possibly integrated into core VSG repository.
• vsgFramework - an experiment with using CMake to find external dependencies and if they aren’t available fallback to using ExternalProject_Add() to check out and build 3rd party dependencies.