What programming/technical projects have you been working on?

I'm still slowly working on my Vulkan voxel project when I can find the time. Since the last thread I've implemented a task shader. I also took the step of implementing indirect instancing. For context, instancing is not a feature of the task/mesh shaders pipeline at all, so it's a thing I had to design and implement myself.

Since they're so rarely talked about, I'll describe a little about what is "special" here. Mesh shaders and task shaders are basically both just specializations of compute shaders where each has one extra feature. In mesh shaders the extra feature is that it gets to dump small amounts of data almost directly into the primitive cache for the rasterizer step (like next handful of vertices and indices to render). In task shaders the extra feature is that it can dispatch mesh shaders (to my knowledge, the first vendor-independent implementation of shaders directly invoking other shaders without the CPU sitting between).

I think the reason I've become so interested in this specific project is that it sounds so much easier than it is. Voxel art weirdly feels retro, but isn't really because it is deceptively difficult to efficiently render. This is for a lot of reasons, but maybe the most obvious is that a lot of rendering techniques are related to simplifying the models and making up for the loss with more complex materials (ex. normal textures) but that doesn't work so well with voxels. There is a fair bit of literature about techniques for rendering voxels, but I didn't really like their tradeoffs wanted to try something different and not tied to the standard vertex+fragment pipeline.

One thing with task+mesh shaders though is that it is encouraged that if I'm going to take this route it should not be in service of basically rebuilding the standard pipeline. According to docs if I want something like the standard pipeline then the hardware is way better optimized if I just use it than recreate its features, so instead my data looks basically nothing like anything possible with a vertex shader to the extent that on average the inputs representing each vertex is ~1 byte. 4 bytes per face, plus some bookkeeping data for each group (ex. number of faces in group), emits 4 vertices.

I'm sure it'll change a lot as the project progresses, but as of right now my configuration is capable of drawing as many voxels as I could ever want in just one draw command. I'm not sure if it'll be optimal in the long term, but for now I'm leveraging that compute shaders scale on 3 axis. I'm using 2 of the 3 with one scaling against the size of the model and the other scaling against the number of instances. Long term I may find that this leaves my wavefront occupancy on small models low in a way that means I should redesign the scaling to address that, but that's a future me problem (and I don't think that hard, just a bit uglier).

My next step is to refactor it into not being an absolute nightmare though. I was more interested in seeing things work than doing things right so I currently have a massive main.cpp that also just leaks memory all over the place (although not per-frame, I just don't clean up anything from initialization).

Got a working 18650 battery enclosure that handles output and charging for my audio project. So I now have it fully working not connected to the wall for power, but not portable yet due to still being on a breadboard. However, since that battery is relatively large to incorporate into a case, I am waiting for a Raspberry Pi Zero 2W to arrive, as I need the space savings compared to my 3a+. This project has taken longer than I expected, due to waiting for parts, and returning parts that do not work for my project. I also have an issue with my display freezing, which I have figured out is due to the FBCP Porting setup I am using. I am going to try and set it up via SPI, I just need to figure out how to get openbox to use an SPI display.

A second project I have nearly completed is setting up a freelance website using Github pages. I even have a contact form working, using an HTML form, and then using a prefilled link and AJAX to submit the form as a Google Form. The only things left to do on this website is some minor tweaks, and I have a second person currently proofreading my grammar.

I recently had a big repair win with an eBay purchase. Caught an Agilent 34461A 6.5 digit multimeter as parts/not working status, offered $300 and the seller accepted. It had the 'white screen of death' that can result from a few different causes.

I had thought it would be the SPEAR MCU failure that is the known/common failure mode for when the screens do stuff like this, but it ended up being the actual screen itself, which was awesome since I had a couple replacements in stock I had bought for a different '61A repair a while ago that had been sitting in my queue.

The internals had been contaminated with the smoke from when the screen died, so I had a fairly anxiety-inducing cleaning session where I had to clean the mainboard by hand with tiny foam swabs and isoproply (there are areas normally covered under a combination of EMI/ground shielding that one should never so much as breathe on due to how sensitive the components are). Fortunately after cleaning and testing it, I did not appear to have damaged any high-sensitivity components and the meter is operating beautifully.

It is off by 390 microvolts when measuring my 5 volt precision source, which equates to about 78PPM drift, but the internal calibration data says it hasn't been cal'd since manufacture in 2014, so that much drift is potentially understandable - should just need to be calibrated.

Video of the repair.