Post-Computational Processing

It's been awhile, but I figured out the hubbub behind compute shaders!

In all honesty, based on its taking of information and creating a pipeline to read in data and output a stored image, it's essentially post-processing. It's interesting how a quad no longer has to be rendered separately at least; it makes it a little more convenient (and heavily not so to have to create compute pipelines but it's all about the graphics processing, not necessarily readability).

Shown are a few simple effects, including edge sharpening and detection from previous projects and an embossing shader.

The Same Thing, Only Harder

Man, progress certainly goes by a crawl when you only make work on the side on the weekend.

It's been awhile, but Vulkan sure knows how to up the ante on 3D models. The basics are very similar to 3D extrapolation of the 2D I was already doing, and I used a .ktx model for the satellite.

The difference? Well, the triangle was originally a set of points, so automatically loading VertexInputStates, buffers, device memory, and storing the information such as vertices and indices in contiguous memory structures was key. Definitely more than a triangle's worth!

And it's worth it; I'm also quite grateful to the creators of Assimp to make the mesh loading side so painless, even with model types like .ktx:

3D models covered! Now to see what else I can do.

Hiatus

Apologies for the late (really late) reply; work has been in full swing and nothing is allowed to be bloggable.

What will this mean? Progress will be down to a crawl (couple of hours on the weekends; I gotta enjoy life as well) but will continue. Keep posted for any progress! I promise it will be visual.

Until then, I'll be working on a base application class for Vulkan.

Nearly There

Whew! Managed to construct all the basic components necessary for the example. Now I just need to create a base class for that example (and any others that may follow).

It's mind-boggling to see how much a low-level API really requires from people in terms of not just knowledge, but sheer self-structuring and (3000+ lines of code). Seems like the input wasn't anything special though; the direction just looks like it's following basic keycodes.

Ah well, I liked using them anyways.

UI Is Its Own Beast

Yeah, I forgot that. The big components for today were the mesh loading class (which uses assimp, always a top open source choice) and the UI text overlay, which simply does thinks like update for FPS and the like. Thing is, it also requires its own set of buffers, descriptors(especially for the changing text), image objects, command buffers, the works. Seriously, the only thing we could really take out of the thing was composing the device on as a reference.

Soon we shall be back to a main program of sorts at hand! I'll also see what secrets lie in input for this application as well (moving around). It may even be better than DirectInput!

The Parts Add Up

Construction continues! Mainly parts on a swap chain and debug tools. The example I'm following also supports linear tiling instead of using a staging buffer, but it's heavily unlikely I'll be using it.

I'm also concerned if using C-style casts is a good idea for void*; I hear a lot that reinterpret_cast isn't a good idea, but I'm also hard-wired to prefer the new C++ casts.

And now working on a texture loader class! I'm actually quite happy that such complex details like image, image memory, and samplers can all be wrapped up in a single object. If only Vulkan followed a similar structure; it seems that they have the parts all there but they could use to be wrapped up nicely.

Component by Component

One of the main reasons why I had to start over from the ground up instead of carefully find out what the problem was (other than just not knowing how) was me not slicing the application (Vulkan) into enough components.

Some of the main ones I focused on today was a buffer object to hold things such as the buffer, device memory, and a reference to the device in question. This was linked to the object that I was also working on, an instance that holds both physical and logical device instead of keeping them separate.

One of the more interesting and helpful methods I learned was to actually make up for the heavy code writing for setting up structs by actually creating initializing functions for them. They had none of their own, so instead of

struct s = {};
s.a = 1;
s.b = 2;
s.c = 3;
...
Or {1, 2, 3}, since the members got a bit tricky to understand and a constructor (not present for the structs) would come in handy.

This is still a fairly lengthy process, so I definitely won't get anything on the screen until I'm absolutely sure it works.