Refactor of ShaderStage/GraphicsPipelineStates/ShaderSet/GraphicsPipelineConfigurator to add Mask support

[robertosfield]

As part of the my work on implementing shadow mapping support to the VSG I have been refactoring parts of the VSG to make it more flexible and for certain usage cases more efficient. The changes I have worked over the last few days will be utilized by the shadow mapping work but will be useful for other usage cases.

The changes are checked into the master branches of VSG which has the refactor itself, vsgXchange and vsgPoints that had to change to work with the API changes to vsg::GraphicsPipelineConfigurator and vsgExamples for the purpose of testing the new functionality.

https://github.com/vsg-dev/VulkanSceneGraph/pull/915/files
vsg-dev/vsgXchange@85b9782
vsg-dev/vsgXchange@2b213f5
vsg-dev/vsgExamples#245
vsg-dev/vsgPoints#12

The changes to vsgXchange, vsgPoints and vsgExample will illustrate how I had to update code that uses GraphicsPipelineConfigurator as it;s API has changed, removing the hardwired ref_ptr<>'s to the various GraphicsPipelineStates, replacing them with a std::vector<ref_ptr pipelineStates.

The key part of these changes is the addition a Mask member to the vsg::ShaderStage and vsg::GraphicsPipelineState, this is now evaluated when the GraphicsPipeline:::compile(Context&) compiles the vkPipipeline with the GraphicsPipeline::Implementation(). Each ShaderStage and GraphicsPipelineState is now only part of vkPipeline creation if the View,mask & state.mask/state,mask is non zero.

This might seem like a bit of obscure addition but it enables us to specialize the vkPipeline per vsg::View, this was already done but just for the vsg::ViewportState inherited from the vsg::View, but now we can select which ShaderStage and GraphicsPipelineState to apply for each View, without any added overhead to the run-time as we already have a per View buffered vkPipeline.

For shadows this will allow us to create a single scene graph that can be rendered for a 3d view or a shadow map uses separate sets of shades - for instance the shadow map fragment shader can be much simpler, so will help with minimizing the overhead for rendering shadows.

The approach avoids adding vsg::SwicthState and vsg::Switch node to the scene graph, instead you can just add the specialize vsg::ShaderStage and vsg::GraphicsPipelineState with the appropriate Masks to the vsg::GraphicsPipeline, so the overall scene graph structure doesn't change.

The next step to make this functionality easier to build into applications is the changes to vsg::GraphicsPipelineConfigurator so that it can handle vsg::ShaderSet that are setup with the additional ShaderStage and GraphicsPipelineState that utilize the Mask. Unfortunately I had to change the API enough that user code may well no longer compile if you are directly using the GraphicsPipelineConfigurator. Unfortunately this breaking API change was unavoidable, there wasn't any way for me to make the code more flexible and retain the hardwired vertexInputeStaet/colorBlendState etc.

Now user code needs use RTTI to determine the GraphicsPipelieState, but was they are all supported by the vsg::Visitor this doesn't complicate user code too much. Have a look at the vsg::Builder and vsgXchange::assimp changes to see what the new usage will look like.

What makes all of this effort changing your code worthwhile is that you can now load models that can be rendering differently in different views without having to post process them. The vsganalygphicstereo example used to have to post process models and use a custom code to handle the required differences in ColorBlendState for the left and right eye, but now it supports updating the standard PBR, Phong and Flat Shaded ShaderSets to automatically have two ColorBlendState with each one specialized to the left or eye by match the View::mask to the ColorBlendState::mask.

This is what it looks like in action, first up running vsganaglyphicstereo with no options which will load the models/lz.vsgt and then replace the ColorBlendState it finds in the scene graph with the left and right eye ColorBlendState:

vsganaglyphicstereo

Next up we'll load the openstreetmap.vsgt paged data, but rather than use the replacement we'll use a custom Phong ShaderSet that is the same as the standard one, but just adds the two ColorBlendState:

vsganaglyphicstereo models/openstreetmap.vsgt --no-replace

Finally we can use the same ShaderSet substitution for PhysicsBasedRendering ShaderSet is used by the vsgXchange::assimp when loading models from the glTF example repository:

vsganaglyphicstereo ~/Data/glTF-Sample-Models/2.0/FlightHelmet/glTF/FlightHelmet.gltf --no-replace

---

All these changes are checked in the respective masters, and will be part of the next stable release set I make, which for the VSG will be 1.0.9. VSG master already has it's version updated to 1.0.9 so if you need to use conditional compilation to handle the changes in the API then you'll be able to use this as a guide, or simply use the version in CMake when finding the VSG package.