Failure Once More

Yeugh, that's what I get for following a tutorial that doesn't have an established project. I get all the way to model construction and nothing shows.

Turns out I'll have to start from square one, but by following some more proper examples that work. Who knows? Maybe it'll work out better this time. But right now, I nor the source code can explain why a blank screen shows instead of a model.

Texturing in the Deep

Today managed a couple more simple topics through the excessive complexity of Vulkan.

First off, texture mapping! The image is a bit different from buffers, which required a different set of functions for copying, creating, and transferring image objects. I also had to create a sampler object and combine the layout with the uniform buffer object to make sure it got read through the shader. Luckily enough, the texture coordinates weren't too difficult to add to the shader. Voila!

I also added some quick linear filtering and texture addressing for repeating textures:

We can even quickly multiply a color! But this is simple enough once we get past setting up the proper image object, memory, and view:

But wait! What's this:

The left object is actually behind the right; this means I need to setup depth calculations, which includes testing for the correct depth-stencil format and setting up the proper depth image view along with the swap chain image views when presenting to the screen. That way, we can use the z-buffer to show the correct pixel at the correct depth:

We need some 3D models, though! Time to tackle some model loading.

A shout out to the stb library and the tinyobjloader library for containing single header files instead of static library linking! It definitely makes it easier for multiple platforms and configurations.

In Space

Phew, the information is nearly overloading my brain with how much Vulkan requires to even get a proper world-view-projection matrix setup in the uniform buffer. The uniform buffer follows a similar setup to the vertex and index setup, but a resource descriptor has to be created for data that updates frame by frame. This also requires an in-depth setup with the pool of memory in which the descriptor set came from. Yikes!

However, this means that we can now present an object moving in space! I also found a tip to use std::chrono to easily use that as frame-time when measuring time-based movement. Though a flipping square doesn't need too much adherence to time-based movement, it is a helpful method:

As for actual textures, watch out! I'm now working on an image object. The image object works much like a buffer, but has slightly different bindings and setups. I will keep using the stb library they recommended; it works very well and only requires a header file (instead of that static-linked SOIL).

Wait, a Square

Such wonders a buffer can hold! Today was mainly spent working with buffers; these objects are similar to the DX11 buffers, except we can use a staging buffer to allocate them from high performance memory then transfer them to longer-lived buffers. In this way, I can change input data without having to re-do the whole shader and compilation process:

However! Not all is set for buffers; the index buffer is also available in a similar format, which works very much so like index drawing for DX11:

What's next? Resource descriptors! They are required to setup free access to resources during drawing such as buffers and images. What buffer? A uniform buffer, which means world/view/projection fun times!

Actual Imagery

Phew! After all these days of setting up the framework, I finally got a thing going on the screen!

It's also resizable, which means I had to properly setup the GLFW callback and recreate the swap chain (along with all other things connected to it) after the swap chain images were invalidated by a resize.

After creating the command buffers, I also had to create synchronization objects. With Vulkan, we could either use fences or semaphores, so I used a semaphore for image availability and render finishing. This also requires waiting if anything (like swap chains) in the system had to be changed during program running.

And with that, the image is finally presented to the screen! Let's try actual input data this time.

Piping that Line

Phew, the extra components required to setup graphics programming never ends! I'm getting much more in depth to the process of drawing a triangle than I ever felt possible!

I pulled in the necessary components for fixed functions (input assembly, rasterization, color blending) and also had to make a render pass that would inform Vulkan about the framebuffers it would be attached to.

Then I had to make the framebuffers! And the whole pipeline object. Everything's static for now, as a dynamic array would be necessary to specify to the pipeline what would change over time. Otherwise I'd have to recreate the pipeline.

And now onto command pools and command buffers! Because an API known for multithreaded wonder has to setup the render commands with a specific pool of multithreadable memory somehow.

Rising From the Ashes

Wowza, I totally forgot that because I was using educational software, they had to RIP it away from me in a computer wipe. I did manage to come back, though! I keep most of my big projects intact so they may live on through my website, and I did a similar gesture for my current Vulkan work.

As for my current Vulkan work? Since today was a lot of installations, I mainly had time to setup image views (which were also encapsulated in RAII objects, but I totally forgot) and start working on the shader pipeline.

Very interesting tidbit - shaders are actually read in as bytecode through Vulkan programs. The actual compilation of the shaders into .sfv bytecode (SPIR-V's the name) is actually done separate from the code. This ensures much quicker loading than kid-friendly GLSL/HLSL. However, I can still use GLSL shaders as long as they are compiled into SPIR-V format.

According to this pipeline, I can fully program vertex/geometry/fragment shaders and tessellation, and also control quite a bit of the color blending/rasterization processes.