Vulkan Instanced Rendering
Role: programming
Size: solo
Time span: 2 months
Engine: Vulkan
About
A self-made version of Vulkan where I try out multiple rendering pipelines simultaneously, and apply instancing to 3D
Following the vulkan tutorial to set up a baseline project, we got the opportunity to add an extra feature to our engine.
Short-form summary:
In this project I made Vulkan pipelines for 2D, 3D and instanced 3D rendering.
I talk about learning points and things I would tackle differently now such as putting instanced data in meshes instead of the pipeline, aswell as giving a short explanation on how the project works.
Why is this on my portfolio as a gameplay programmer?
It's because while I see myself as most skilled in gameplay programming, I do see myself as a versatile programmer who loves working on Graphics Programming and engine programming too!
Workin on this project was a ton of fun and learning in general is something that motivates me.
Introduction:
A project made throughout the course Graphics-Programming 2.
In GP1 we already made a rasterizer and raytracer. This taught us how to apply different maps, optimisation techniques, and cameras.
Now it's time to tackle a new and popular engine.
Why Instanced rendering?
Instanced rendering is something that piqued my interest. Games such as Ultimate Epic Battle Simulator use this technique to simulate an unbelievable amount of actors in 1 scene.
I wanted a topic that forced me to use a bit more hlsl to get me more comfortable with it.
Lighting and shadows are not something that interest me too much, but an alternative I was thinking of was a portal system using a camera-like system to display that view onto another plane.
The render pipelines
A core necessity to make the pipelines work is to have different buffers.
This was done through a simple inheritance system.
Github Buffer
In similar fashion I worked out a base pipeline having a create, initialize, record, cleanup function, aswell as some getters.
From here on out I split it up in a 2D and 3D pipeline, and eventually my instanced pipeline.
The key unique functionality of the instanced pipeline is the use of vectors of VertexInstances and InstanceBuffers, aswell as having multiple BindingDescriptions and AttributeDescriptions.
Github Pipelines
Looking back at it, I think some of these could be reworked into a more central class, and have the mesh class hold more data.
HLSL and linking
The pipeline holds information such as coordinates, different positions, and texture data.
This gets pushed to the GPU, where it applies it uses its UBO (Uniform Buffer Object) and a texture atlas to get to the final view.
What would I change?
I'm much more interested in gameplay programming, but now having worked on more group projects and entering my third year these are the things I personally think could use improvement:
- Use IMGUI or another framework for visually controlling the pipelines and especially instance count, can use fileio to also hold values over different sessions
- Refactor data to be in more appropriate places such as some buffers being part of a mesh, and the mesh holding instance data.
- Do deeper research into the sampling types to avoid the edges on my cubes
Relevant Links