Learn VulkanSceneGraph from scratch

[artemkulyk]

Hi all,

Could you please suggest me how to learn VulkanSceneGraph efficiently without previous experience with OpenSceneGraph?
Does it make sense to start from learning OSG before starting with VSG? There are a lot of documentation and even books about OSG.

Documentation in https://github.com/vsg-dev/VulkanSceneGraph/tree/master/docs is mostly focused on differences of VSG from OSG and explains some architectural decisions, but it contains very limited information about library usage.

I have a limited experience with OpenGL, and I have no experience with Vulkan. Does it makes sense to start from learning Vulkan and only then switch to learning VSG?

Best regards,
Artem Kulyk

[robertosfield]

There are some similar concepts between the OSG and the VSG, but also some fundamental differences due to OpenGL vs Vulkan and also the VSG just being new ground up scene graph. For a new user I don't think learning the OSG will help accelerate learning the VSG.

W.r.t learning Vulkan then the VSG, I don't think this will be speed things along too much. Vulkan requires a huge amount of setup before you can even render a simple texture quad, this is a huge hurdle for new users, something that I'm hoping that the VSG can short cut as most of the setup is done for you, to achieve the same result the VSG can do it with a fraction of the code.

However, the VSG has been designed to a scene graph for Vulkan, VSG class naming and members are chosen to be the same or very close to the Vulkan to make it easier to look at Vulkan examples and documentation and know what they map to on the VSG side and visa vera. So learning the two together is what I recommend.

The VSG has only just reach it's first stable release, it's design and implementation evolved over the past 4 years with it converging towards what 1.0.x right up to release. There hasn't been been a general purpose scene graph for Vulkan before so how to go about implementation one is something we didn't have any prior art for. Unfortunately this means there isn't a body of work that we can point to as inspiration/what guided the design and implementation. This is really just the nature of R&D, you can't build everything at the same time.

For learning the VSG from scratch today the best resources you'll have will be the VSG code base itself, the vsgExamples set and the last 4 and half years of discussions on the old vsg-users google group, and ancillary projects like vsgXchange, vsgImGui, vsgQt etc. Increasingly this new Discussion forum should also start filling out with discussions that will help inform new users about to tackle things.

Vulkan resources will also come in very useful, search engines will be able to point you are the right places, just typing in VSG class names can often bring up to the appropriate Vulkan API docs thanks to the consistency of naming.

This Discussion forum will also be invaluable. Open ended questions are the hardest to answer, Specific questions are often the easiest and ones that will help you get to a solution the quickest. A good measure of how effective a question is, is how many question you get in reply that are trying to figure out what you are actually asking about, If you get an answer right away then it's a good sign that you are asking questions in ways that are helpful to the ones that might be able to answer.

In the case of how to "learn the VSG" this is quite open ended, the answers will depend greatly on your own level of experience in C++/CMake/Vulkan/OpenGL/Scene Graphs/Shaders and what your own project goals are.

What you are wanting to achieve with your project is really helpful in the case of knowing how best to help you and what resources will be useful, and what strategy would be best for breaking down what you should learn first . The pathway through will be different for each application class.

[artemkulyk]

Hi Robert,

Thank you for your answer.

Actually, my every day job is related to development of automotive navigation system, map viewer part. The project is quite big and I am responsible only for some isolated parts of the app (like rendering using distributiled rendering engine from OEM or displaying traffic flow on the map).

I am interested in self development and deeper dive in maps visualization. So I started working on my pet project - simple map viewer for mapbox / openmaptiles / HERE / cesium vector tiles. It's just a task for my self development, currently I have no plans to publish it. During research I found that VulkanSceneGraph can be useful for my work.

Best regards,
Artem Kulyk

[robertosfield]

The VulkanSceneGraph is will suited to this type of application, with others in the community already working on application in similar domains.

We don't have out of the box support for "mapbox / openmaptiles / HERE / cesium vector tiles" so to visualize these you'll need to write loaders for them. The vsgpagedlod example is one you've already come across, this is certainly a useful resource, though it's in the deep end right away as it handles state, geometry, PagedLOD nodes to enable paging of IO.

The vsgpagedlod example predates the new vsg::ShaderSet class that makes customizable state setup of scene graph easier, the vsg::tile ReaderWriter is derived from this example and has made it into the core VSG. Recently I updated the vsg::tile ReaderWriter to use vsg::ShaderSet. So you could consider this another more example in which to learn from. It's not written as a training resource, so you'll be learning from C++ code rather than a tutorial. Comparing vsgpagedlod to vsg::tile would likely be insightful.

One of the important tricks that vgpagedlod and vsg::tile do to avoid precision issues with handling large datasets is to place a MatrixTransform node above each tile, this transform places the tile subgraph into world coordinates, and allows the subgraph to have a local coordinate frame with a origin for the vertex data within the tile.

The reason why this works to handle precision issues, the VSG use double matrices for the Camera and transform nodes in the scene graph, accumulate as double matrices these during the cull/record traversal then covert to float matrices before passing to Vulkan. This approach preserves precision for as long as it's required. On the GPU when you are close to a tile the Camera position and the world position of the tile are similar so the double translations largely cancel out so you don't get jitter as your move around on/near a tile.

For tiles in the distance the offset is larger so the rounding errors associated with multiplying vertices by the modelview matrix exist but before the vertex is immediately transformed into clip space where the position is divided by the distance so any round errors become very small and sub-pixel so they are never apparent. This means tiles in the distance also a rock solid.

If you are new to GLSL, a C like language used for shaders, then I'd recommend searching online for resource that can teach you. As long as the VSG is compiled against GLSLang the VSG automatically compiles GLSL to SPIR-V before passing to Vulkan so you needn't worry about manual conversions to SPIR-V. Later on you can learn more about SPIR-V that Vulkan uses when you need to.

The maths classes in the VSG are all based on GLSL conventions, if you've come across the GLM library (also based on GLSL convention)s) then maths code you'll need to do in the VSG will be similar. I considered using GLM for the VSG's maths, but decided it's just too big to justify - it's almost as big as the whole the VSG codebase!

For here my recommendation would be to pick one of the file formats that you would like to load and have a bash at writing a loader for it. The community can probably help with pointers how to go about implementing it even if we aren't experienced with the format. If there is a public data repository for that format then this would likely help too.

Creating a test project and making it open source would help others in the community review your code and provide input, this can short cut much of the issue of trying to explain a problem to others that are not familiar with the code, the data or have 1st hand experience seeing the problem. Such a body of work can also serve as an example to others coming after you.

Best of luck,
Robert.

[artemkulyk]

Hi Robert,

Thank you for the detailed answer.

Best regards,
Artem Kulyk

[MasonAlice]

I am trying converting vulkan-example reporsitory to vsg example as exercises. I found it's a good way to learn vulkan.