How I learned Vulkan and wrote a small game engine with it

[eliasdaler]

New article which explains how I wrote my Vulkan engine: https://edw.is/learning-vulkan/
Free free to leave comments and provide your thoughts!

[conorpo]

Very nice work! I am also in the midst of learning a graphics API (WebGPU) via the process of making a big project, but I'm focusing more on post-processing effects and compute shaders. Please mention me if you end up implementing the bloom shader, WebGPU (and I think Vulan aswell..?) does not allow changing the render target mid-pass, so the bloom implementation I used which involves successively downsampling and upsampling across different miplevels required 2n render passes to fully use, and compute shaders weren't usable since none of the texture formats that would work are supported by storage textures in WebGPU, and I would love to see if you come up with a cleaner solution in Vulkan. But congrats on the work done so far, I agree completely with "trial by fire" method of learning graphics programming and starting some project that requires you to learn as you go.

[eliasdaler]

Thank you!

I think I'll end up doing something similar for bloom, to be honest. Something trickier can probably be done with some compute shaders, but I feel like doing a bunch of draws for downsampling/upsampling is completely fine and probably won't have a big performance impact. :)

[mrehayden1]

Looking really nice. I'm going through a similar process right now but with OpenGL.

I notice you were computing all your skinned meshes in a separate compute step and outputting them to a buffer, I guess to be used later by the vertex shader.

I think you already have your joint matrices for each instance of a mesh you're rendering, so why not compute the meshes in the vertex shader?

[eliasdaler]

I think you already have your joint matrices for each instance of a mesh you're rendering, so why not compute the meshes in the vertex shader?

To clearly separate the skinning part and make the remaining steps easier to reason about.

It would be a bit surprising if drawing into a shadow map (the first vertex shader executed) would also produce a new vertex buffer which you would have to use instead of the original mesh.

[mrehayden1]

My question is why didn't you transform the vertices in the vertex shader using the joint matrices? It bypasses needing the SSBO.

Granted you'll be doing skinning for every render pass that way, but it's the most natural and easy way to do skinning. What was the logic behind separating it?

[eliasdaler]

Mainly to not have a distinction between skinned and non-skinned meshes in later rendering stages. It just makes everything much easier - you don't need to ever think about skinnes meshes again if you pre-process them in compute shader as I did.

Granted you'll be doing skinning for every render pass that way

That's another reason I chose not to do skinning in vertex shader. Don't want to do it for every shadow map drawn etc.

Also vertex shaders become much simpler as you don't need to pass joint matrices to them anymore.

[huangwei4478]

Looks real good! I'm going to learn Metal on macOS with your study path!

[sndels]

This was an interesting read and congrats on the vk renderer!

One thing that jumped out to me was you mentioning a frame graph as a potential way to automate synchronization. I've found that tracking the 'current state' on the resource with some utility functions and enums that wrap common groupings of layout/state/usage is a really nice in-between for ergonomics and simplicity. So for image barriers for example, I have more or less

    someResource.transition(commandBuffer, ImageState::TransferDst);

or grouped barriers

    array<VkImageMemoryBarrier2> barriers{
        input0.transitionBarrier(ImageState::ComputeShaderRead),
        input1.transitionBarrier(ImageState::ComputeShaderRead),
        output.transitionBarrier(ImageState::ComputeShaderWrite),
    };
    vkCmdPipelineBarrier2(...);

The synchronization is still manual and inlined with the pass recording, but it's much less verbose and it handles dynamic changes to before states from e.g. toggling passes on and off. It can also skip redundant barriers on a single resource. Frame graph could make the whole synchronization automagical and it would allow fancy stuff like moving barriers over passes to combine the calls or drop globally redundant memory barriers, but it's also a lot more complexity and can make it more difficult to figure out why some barrier is/isn't emitted.