Nested support and submitOrder added to vsg::CommandGraph

[robertosfield]

Hi All,

As part of my work on Shadows I have introduced greater flexibility and control into the vsg::CommandGraph, vsg::RecordTraversal and vsg::RecordAndSubmitTask classes. Nesting of the vsg::CommandGraph is now supported, so you can place a CommandGraph that will record the commands beneath it to the vk/vsg::CommandBuffer and then place this command buffer before or after the parent CommandGraph/CommandBuffer based on the new CommandBuffer::submitOrder member variable.

The new CommandBuffer::submitOrder member variable is an int which is to order the command buffer from lowest value submitOrder to highest to control which order the vkCommandBuffers are passed to vkQueueSubmit. This would typically be used with a submitOrder < 0 used for pre-rendering work, and a submitOrder > 0 for post rendering.

Previously the order submit was order was implicitly the order that you added the vsg::CommandBuffer to the Viewer::assignRecordAndSubmitTaskAndPresentation(..) call. The new scheme is based strictly on the submitOrder so if you have previous code that relied upon the implicit ordering being maintained you will need to update your CommandBuffer code to add an submitOrder setting to specify the order which you wish the command buffers to be submitted in.

The changes are now checked into VSG master:

  VulkanScenegraph Nested CommandGraph changes

And I have update the vsgrendertotexture and vsgdynamictexture_cs examples vsgExamples to illustrate the use of nesting of CommandGraph and setting of the CommandGraph::submitOrder:

  vsgExamples Nested CommandGraph changes

This new capability may seem a bit obscure but is actually a pretty profound feature:

1. Allows us to embedded render to texture work into the scene graph, rather than having to explicitly add it at the viewer level when configuring the high level CommandGraphs. This means viewer setup is simpler and needed change as you add new effects and techniques to the scene.
2. Allows to dynamically cull or select when CommandGraph to traverse during the main 3D RecordTraversal, so we implement techniques like render to texture on-demand, or in round-robin style.
3. The complexity of implementing rendering techniques required for a scene can be encapsulated by custom scene graph nodes, hiding much of the complexity from users lowering the barriers to implementing high quality visuals.
4. Decouples the traversal order from the submission order, allowing rendering techniques to gather information during a RecordTraversal then use the results to decide what other settings or traversals are required for the render rendering tasks.

All these general purposes capabilities are well beyond the specifics if the Shadows work, which is why I've implemented it as a dedicated task and checked it into the VSG master, so it'll be in the next stable release of the VSG 1.0.9.

It's worth emphasizing how these new capabilities are really helpful for shadows work - it will allow me to hide all the complexity of recording and setting up the shadow maps within the vsg::View's ViewDependentState object. Previously the ViewDependentState class just provided the viewport dimensions and lightData as DescriptorSet that shaders like the Phong and PBR ShaderSets could use, but with these changes it'll encompass all the shadow maps required for the lights as well with no changes required to user code.

What I'm aiming for, is for end uses to be able to just load PBR models from GLTF etc, put their vsg::Light into scene graph at the appropriate places, specify the shadow settings on each vsg::Light and the VSG's ViewDependentState with work with the PBR or Phong ShaderSet (or your own ones) and automatically have multiple lights with multiple shadows provided for you out of the box.

For developers moving from OpenSceneGraph to VulkanSceneGraph this new nested & submitOrder capability broadly parallels the Multi Stage rendering support built into the OSG's rendering back-end and control by the osg::Camera. The VSG variant is more general purpose as you can use it for compute as well as graphics work, and Vulkan/VSG allows support recording commands to a vkCommandBuffer multi-threaded, something that OpenGL prevents the OSG from doing.