Slow month in the programming department in general. I’ve had books to read, music to listen to, and clouds to watch. Right now I’m mid-pivot so not that much to show but I’m excited!

Pivot

For a moment I had a hard time figuring out what I was even building. I went too deep on the tech side of things. Of course I need networking and physics, those things are cool! But they happen to be a pain in the ass as well. I’m not one to say no to a challenge but am I doing this because it’s a challenge or because it actually takes me to a place I want to be?

So I did what I typically do when I feel frustrated, I started a new repository. Tinkering with the basics always gets me in a good mood. Just typing out simple and handwritten glue code, mm, pure bliss. Now I’m back to where I was a month ago but with a new codebase and a new idea in my head.

Game

Not going into too much detail since it’s still just an idea in my head. But I wanted to constrain myself a bit and have been thinking of a more top-down style. I’ve played around a bit with using an orthographic projection to give it more of a pixel game style.

I’ve noted another benefit of this approach as well. Not only does it limit the scope of what you can do in terms of gameplay compared to a FPS, but it also simplifies a lot of the technical challenges I’ve encountered with my rendering.

Style

Now I’m playing around with the style. I feel it would be neat to target something that looks like pixel art, but that is in 3D. As an example I tried pixelizing the lighting:

But as you see if you rotate, it’s actually 3D.

As you can see, the regular light gives a bit of another feel.

So I have some experimentation to look forward to in the coming month. I think first order of business is probably to fix my foliage, which for now is full of artifacts.

Other

• Monk and Robot: I recently got introduced to solarpunk by a colleague and I was scrolling through some books. This was one of the few that didn’t seem to want to force a lesson on me so I bought it. It was actually an amazing read, very simple and like therapy for my overthinking brain.
• How rendering changed | Sebastian Aaltonen: Interesting interview with Sebastian Aaltonen.
• Goings-on in Ziglang with Build System Reworked and ELF Linker Improvements.
• Boards of Canada - Inferno: First album in 13 years and it was amazing!

Sadly not much to show in terms of screenshots but I’m slowly getting back to it. Spent some time on refactoring, multiplayer (dealing with third party libraries) and migrating to Zig 0.16. Look ma, std.log received some colors!

Refactoring

Old codebase was a mess of various types of update functions, we once per frame updates for things like UI, fixed timesteps for physics, etc. To make both physics and multiplayer a bit easier to implement I set out to clean that up. With some nice references in hand, like Fix Your Timestep! and Fixed timestep without interpolation I set out to perform this at first seemingly simple task. As usual it went a bit out of hand, but here I am with a new shiny foundation!

Multiplayer

Not much fun to show in this department, but it’s getting there. Not wanting to reinvent the wheel I’ve spent some time looking at third-party libraries for networking. The two contenders are Valve’s GameNetworkingSockets and Glenn Fiedler’s netcode + reliable. Though I appreciate Glenn Fiedler’s philosophy since GNS is somewhat of a mess, I’m still leaning towards using GNS. It’s tested and if I would ever release a game it would likely end up on Steam.

They both were a real pain in the ass to get building within the Zig build system though. GNS is a messy C++ project with a bunch of dependencies and doesn’t really provide a clean C API I can just hook up. Netcode on the other hand just straight up produced miscompiled code (Zig toolchain bug that seems to have been resolved now), and sodium vendored with the project is dated so I had to deal with that as well.

Now they both build (need some fixes for Zig 0.16) and next step is to actually write some code.

Zig 0.16

Zig 0.16 was released introducing a lot of goodies, one of them being the breaking I/O as an interface change. And thus, one of the goals for this month has been migrating existing code. This includes both mine and third-party libraries.

The migration wasn’t that bad, but there are spots that got a bit awkward and that I might want to revisit when I understand the new features better. This release also came with some fixes for bugs affecting me so I’m stoked that I’m finally able to remove some workarounds.

vulkan-zig also had some breaking changes so put had to do some maintenance in my RHI as well.

Cool stuff

• Bunch of talks from Graphics Programming Conference, most notably the one about teardown and beyond
• Introduction to Spherical Harmonics for Graphics Programmers
• Razor1911
• Fast and Gorgeous Erosion Filter
• Modern culling techniques with visualizations.
• The Future of Path Tracing | Best Practices, Optimizations & Future Standards
• Slang Shading Language Demo & Single-Source Graphics Pipeline Explained

Robots and the goblin

I don’t know if it was my ability to write reasonable prompts or if Claude just got worse, but one thing that is certain is that I was slowly losing my mind. Claude is great at quickly spewing out features. In fact, it’s so good that you wake that nasty goblin in your head that just wants more. Initially it wasn’t that much of an issue. I carefully reviewed everything and was always there to push the LLM in the right direction. However, as the codebase grew, Claude clearly got dumber. As I started questioning my decisions in life, the goblin took over. Now I have a bunch of experimental codebases that I despise and an LLM that probably dislikes me just as much as I dislike it.

I hereby declare, next month is no-LLM month. I’ve already started and who knew, programming is kinda fun! Sure, I won’t have the great power of AI at my disposal but I don’t see it as that big of a loss. The fact that I don’t have to manage the utter chaos spread by a bunch of mansplaining robots and a lazy goblin should give me more time to focus on something useful.

Things were not clicking and that fantastic high from doing something that is genuinely fun was slowly dissipating. I accepted my fate and didn’t force it. Instead I’ve watched countless reels, YouTube videos, explored new music, and even found myself staring at clouds through my window. I’m not gloomy, rather the opposite.

Since I’ve been, and probably still am, procrastinating; I don’t have much fun to show. So let’s take this opportunity to appreciate what other people are up to instead.

Youtube

Even if I might not dare to admit it, my most visited site is probably YouTube. It’s the first ocean of content I find myself in when my mind is drifting. There is however so much useful content on there nowadays that it might not even be fair to call it procrastination. Here are some of the things that I have watched recently.

PewDiePie’s training his own AI: The PewDiePie tech arc has been incredible to follow. A year ago he built his first PC and now he has his monster of an AI computer almost burning his house down. It’s a very inspiring story on perseverance and embracing failure. I definitely recognize his obsession as it’s the same thing I went through when first starting. You had no clue what you were doing but you get nowhere if you give up.

Jonathan Blow on Wookash Podcast: Wookash Podcast has a lot of great guests and this one I liked a lot. They discuss technical details of Jonathan Blow’s new game and the Jai programming language. There are plenty of Jonathan Blow’s rants out there but this provides some of these directly linked to the game he is currently developing.

Gorillaz - The Mountain, The Moon Cave and the Sad God: Gorillaz recently released a new album together with an amazing animated short film! It apparently took 18 months to complete and it’s very much a love letter to the craftsmanship of older animated films. Very refreshing to see in the era of AI.

Kamikaze_Shortbus: More on the art side but insane humor in combination with cool insights. I re-watched this video which provides another perspective on what I have dealt with the last couple of months, color and lighting. She also hosted an art contest recently where she and friends went through and gave constructive criticism to all contributors and now I feel a sudden urge to start drawing.

Gamedev

The algorithm knows me too well so of course my feeds are full of gamedev news. If you can’t progress yourself, be amazed at the progress of others.

Teardown multiplayer: Teardown is what inspired me to dig this deep into voxels and I’ve done my best to gather all knowledge about its inner workings. This makes me appreciate how complicated something like multiplayer can be to implement, but they did it! This write-up by Dennis Gustafsson was an amazing read.

Texel Splatting: This work has started showing up in my feeds and it’s really cool. Stable 3D pixel art! I’ve never thought about this problem before but this was a thought-through approach for another interesting way of rendering.

Tangy TD: Twitch streamer cakez77 released his game after working on it on stream for years. I have followed him on-and-off and it’s very cool to see him finally release the game.

Reading

I’m not great at reading books but I finally started reading Ted Chiang’s Exhalation (with included stories). I picked it up with the intent of reading it during Christmas, but then I got stuck with FRA puzzles or something. I read Stories of your life and others a long time ago and really enjoyed it. He presents cool ideas with a human touch and the fact that it holds short stories makes it easier for a scatterbrain like me.

And finally some other note-worthy reads:

• Library of Short Stories: Found this on hackernews and it’s like fate is mocking me. Now I just need to find time reading.
• Determinism: Been doing some reading on game physics and this is a very interesting topic. You would expect same code and same data to yield the same result but there is more to it. I fear a major screw-up in my future if I attempt this myself, but that hasn’t stopped me before.
• Nobody gets promoted for simplicity: It’s sad because it’s true. This is something I fight daily at work and there were some good lessons in there. Complexity bad.
• Optimization ladder: Another topic that frequently comes up at work. This talks about how to make Python go wroom.

What now?

The month might have felt a bit unproductive but I haven’t been bored. I attribute the cloud watching to the slow and steady return of daylight. Can’t say the same about the reels though, but I can tell you that I now know a lot about beavers.

The benefit of these hobby projects of mine is that the only value I see in them is having fun (and maybe learn something). Taking a break is basically free and the alternative is burning out on something I don’t even value. With that said, back to it!

Last post I mentioned that I am terrible at denoising, so what better way to spend this month than with denoising.

Noise

One obvious challenge with Monte Carlo methods is the trade-off between accuracy and computational cost. This is a real-time application so we have our deadlines and casting rays is crazy expensive. The characteristics of the noise are a bit different depending on the signal we are trying to reconstruct. Here I will write about ray-cast shadows produced for the direct lighting and the incoming radiance for the indirect lighting. There is a lot of good material on this topic, such as this blog post by Alain Galvan.

Direct light

I will not go that deep into the specifics as there already is much freely available material out there (like the PBR book), written by smarter people than me. But let us assume you light your world only using direct lighting.

Not that exciting, is it? Any surfaces not facing the light source would be completely dark. This is also an important aspect of direct lighting. Naively applying just analytical lights would not account for shadows cast by objects. There are multiple approaches to estimate these shadows (e.g. shadow maps) but what I have opted for, and the source of noise, is raycasting.

Since the sun is not a true point light we get soft shadows. This means the shadow is not actually binary, but rather a function of how much of the light is occluded (see penumbra). This is where the noise comes in. We treat the sun as a disk and for each pixel we cast a ray at a random point on this disk. If you do this enough times and keep track of the fraction of rays that reach the sun you will end up with a soft shadow. However, we do not have time so we cast a single random ray towards the sun per pixel.

Above is what we get from the shadow tracer each frame. A binary mask telling us whether the ray hit the light source or not.

Indirect light

Direct lighting on its own is not that exciting. Neither is just adding a constant ambient term to the output like seen above. Global illumination is all the rage nowadays and it is one of these things you did not know you were missing until you actually see it in action. In short, global illumination is about simulating the indirect lighting in a scene, so light that has bounced around the scene before hitting the object.

Global illumination is tricky though and there are many ways of solving it (e.g. DDGI, LPV, Lumen). Inspired by the full potato GI in Tiny Glade I went out to make an even more potato solution. We cast rays randomly in a hemisphere to determine the incoming radiance and then we pray the denoiser can clean it up.

Denoising

Now we have two very noisy signals we need to denoise but we also have two properties we can exploit. The signal has both temporal and spatial coherence. The lighting is unlikely to change for a pixel over time and pixels on the same surface will likely have similar incoming light. Thus, a temporal filter allows us to accumulate samples over time if the camera does not move too much, and a spatial filter allows us to utilize samples from neighboring pixels if they belong to the same surface. The tricky part is the two IFs though. All the filters see is a 2D image so we need to be careful about what samples we actually can use.

Temporal filter

If the camera has not moved too much we can likely accumulate new samples on top of the samples of previous frames. The tricky part here is that the camera is expected to move so you will need to reproject the history of samples on top of your current frame (such as in TAA). This is simple enough if you have motion vectors for each pixel, but you are bound to get pixels where there is no valid history, such as edges of the frame or disoccluded areas.

In a perfect world the reprojection would only produce valid history; then it is just a matter of picking some strategy for accumulating the samples. I went for an exponential moving average. I record the number of samples collected and blend the history and the new samples according to lerp(old, new, 1 / num_samples). I also have a constant MAX_SAMPLES for clamping num_samples which allows me to control how fast we accumulate samples.

However, the world is not perfect and a big part of this filter is actually determining whether history is valid or not. Edges of the screen are straightforward, we just check if we try to sample outside the history texture. The tricky part is that it is a 3D scene, and as the camera (or objects) move, we get disocclusions (surfaces previously not seen). Thankfully we do deferred rendering so I have a lot of information about the scene at my disposal and can compare the depth and the normal in an attempt to detect disocclusions.

This is a typical trade-off. Collect a large set of samples and you get less noise but you will also react slower to changes in the scene. If this is slow enough you will get a lot of noticeable artifacts for areas where the history is reset rapidly.

Spatial filter

This filter is more like a blur filter. As mentioned, neighboring pixels likely hold the same incoming light (or lack thereof for shadows) and here we attempt to exploit this fact by aggregating together neighboring pixels. Here I went for two different approaches. The principle is the same but the two signals are a bit different so I will talk about this below.

Sadly we do not live in a perfect world and just as with the temporal filter it is not as simple as just blurring the image. You also need to consider how much to blur to not lose details and to make sure you do not blur across edges. The assumption is that a surface might have the same incoming light but the image contains many surfaces.

Shadow mask

Here I tried a bit of everything and in the end I ended up with something similar to SVGF. For the most part it is identical but I took some short cuts.

The temporal part is similar to what I have already described but with one addition. We also track the variance of the signal. The idea is that we can use the variance to guide the spatial filter.

The spatial filter then uses a hierarchical À-Trous wavelet filter which uses our normals and depth to avoid filtering over edges. The variance we have collected is also used to control the degree of filtering. The idea is that areas with low variance, such as the shadow umbra, need less smoothing than areas with high variance (e.g. the penumbra). The first iteration of this filter is then what we keep as the history in the temporal filter for the next frame.

The tricky part here and with denoising in general is that there is a lot of tweaking involved. It all depends on your input signal and your scene and you have to tweak everything from your temporal accumulation to how to weight your spatial filter to get decent results.

The penumbra looks a bit weird when looking at it like this so it might require some more tweaking. In the final render that is barely noticeable though.

Global illumination

The GI signal is a different beast. I tried the SVGF approach here as well and it looked straight-up terrible. One valuable thing to note about indirect lighting though is that it tends to be lower frequency. Visually I am way less worried about losing high frequency details and I am happy as long as I get a stable signal that is approximately correct.

One key aspect of denoising the GI is that I first project it into first-order spherical harmonics, which lets us preserve directional information, and this is what we feed into the denoiser. This is also what Tiny Glade and Metro Exodus did. The denoiser itself is also a bit more convoluted compared to SVGF. What I ended up with is similar to ReBLUR but with some simplifications.

The temporal filter is as described before but with some blur of the input before we accumulate it. This is due to the high number of outliers in the GI signal.

The spatial filter is a bit different though. We no longer use the variance to guide the spatial filter since the variance does not tell us much when it comes to GI compared to shadows where we have clear high and low variance areas. Instead we use the number of accumulated samples to control the size of the filter. The sampling for the filter is a bit different as well, we use a randomly rotated Poisson disk and we sample in world space as opposed to screen space. Similar to SVGF we also use the blurred image from the previous frame as the history in the temporal filter.

There are also some tricks to deal with disocclusions since the lack of samples is very noticeable in those areas. The ReBLUR paper suggests using a mip-chain but I went with just an ugly hack where I just collect neighboring samples. In principle it is the same, just more stupid.

Putting it together

Until now we have been rendering everything at half-resolution just because the raytracing is fairly expensive. So the first thing we need to do before actually putting everything together is to upsample our denoised targets. Here I use a simple bilateral filter. Using the normal and depth of the scene we can reliably upsample the image while keeping the edges.

After all tracing, denoising, and upsampling we can finally composite the scene. We can compare our path traced reference (left) to the new render (right) and see that we are getting fairly close.

A visual difference is the ambient occlusion. One drawback of the heavy denoising is that we lose a lot of detail in the lighting so I am still relying on SSAO which lacks the visual depth of RTAO. I actually collect the hit distance during the GI trace so I could potentially attempt to denoise and reconstruct RTAO separately from the GI but that is something for the future.

The old render (left) with the constant ambient term looks very dull in comparison to the new (right).

Coolest thing though, is that you can even see the bounce light in a Cornell box!

There is still better benchmarking needed but looking at some preliminary numbers, rendering the ball scene spends about 1.5 ms per frame on the GI trace and 0.5 ms on denoising at 2880x1620 (full res) on an RTX 3090. The sun shadow is about 0.5 ms in total (raycasting and denoising).

Limitations

It is worth nothing that even if we get some cool bounce lighting like in the Cornell box above, we still only do a single bounce so it will never look as good as a proper path tracer. This is not a deal breaker though as it can still look great. The issue is with noise and denoising artifacts. This whole thing was the result of a lot of experimentation and I expect that I will have to continue experimenting. The biggest issue now is dealing with indoor scenes.

Indoor scenes are especially tricky due to the low amount of useful signal. While it is cool to see that I can now light a scene just using light-emitting voxels instead of analytical lights, you definitely see the lost details of the shadows caused by the denoiser.

In the reference, the shadows, just like the previously mentioned AO, are a lot more defined.

It is hard to spot in screenshots but there are also clear cases where the denoiser fails due to the low signal. Like in the image above you see some odd shifting patterns in the roof and this is even more noticeable when not looking at a still image. One issue here is that we rely on our random hemisphere rays actually hitting the light-emitting voxels. We might be able to reduce the noise by using importance sampling like they did for the Quake 2 raytracing demo.

AI

There are of course modern AI-based approaches for denoising out there such as NVIDIAs DLSS or AMDs Neural supersampling and denoising. However, I decided against them for now since you limit yourself to specific hardware. I might look into this more in the future.

Claude

In parallel to the work on the lighting I have continued experimenting with Claude Code with some mixed results.

Physics

I hinted briefly at Claude implementing a physics engine last month. Well, I made Claude implement it again, and again… After some micro-management and a detailed plan outlined by myself it actually managed to implement something that resembles actual game physics. There is a lot of weird dancing going on though.

It implements physics similar to how Teardown does it, with per-voxel collisions. Objects are just occupancy masks in 3D telling whether a voxel is solid or air. Then thanks to some ideas from Dennis Gustafsson it is actually feasible to calculate collisions per voxel (spoiler: you do not actually have to).

Have not had time to stress test this or anything but it is nice to now have the skeleton to actually be able to do so.

What’s next

I am happy with how it turned out for outdoor scenes but there is still some work to do indoors so I will fiddle around some more with the denoising. I have some ideas on what to try next. Other than that I might actually look a bit more into the physics. I recently read this captivating blog series by Glenn Fiedler so maybe I should add networking as well!

I also have this half-insane fully vibe coded project related to my previous synth project which I might continue directing. I will cover this in the next post if it actually goes somewhere.

Plenty of stuff to showcase this month so lets jump straight into it.

Voxel structure

New year, new me. New me realized old me had no clue what he was doing. It might be fairer to say that the requirements have changed but I’m also the one setting the requirements. I started thinking about how to do LODs using my old system and after trying some different approaches I started feeling like I was fitting a problem to a solution rather than the other way around. And here we are, a somewhat new solution to a new problem.

On the CPU the voxels are structured like this:

World
→ Grid of Chunks
    → Grid of Bricks
        → Voxels

Loading and streaming to the GPU is done per chunk, but the brick map approach allows me to save some memory by not wasting space on too many empty voxels.

For editing in the world I request a view of the voxels, where I perform my changes to an intermediate buffer before committing them all at once to the storage. This allows me to be a bit more efficient in how I manage chunks and bricks:

var view = world.beginEdit(begin, end);
view.set(pt, .stone);
world.endEdit(view);

To actually render this I stream any changes to the GPU. This step also includes compressing the chunks into a sparse 64-tree to make them smaller and more efficient to traverse. The rendering then has a top level acceleration structure (TLAS) which is just a grid of chunks. The raycasting traverses the TLAS in a DDA manner to determine which chunks are relevant to traverse. This might look like above if you get it wrong.

This is very similar to what I did before, just some minor tweaks. The main addition is the LODs. Taking some inspiration from Mike Turitzin’s great video on a game engine based on SDFs, I decided to try out geometry clipmaps. What this means is that I now have a nested set of chunk grids, one for each LOD. Each grid is centered at the camera and contains the same number of chunks. You then have a different scale per level, trading resolution for larger coverage.

And Bam! We have LODs. Don’t mind the artifacts, nested ray traversal is difficult, okay? Traversing the TLAS was a bit tricky to get right. The main issue is that since chunks are streamed in and we always want to display something, we need to pick the best chunk available for every cell during traversal.

Did I mention it’s difficult to get the traversal right at times?

To make my life a bit easier I have limited editing and foliage to LOD0 (closest to camera). But the neat thing about this is that for lighting I can just hook up the new TLAS traversal and it just works. I will have to look into the performance later since it is a bit wasteful to do full lighting for pixels we barely see though. But I’m doing an overhaul of the lighting so that will come later!

In the end I got something that looks good enough. It’s way cheaper to render, generate, and stream to the GPU.

Lighting

One thing that has been frustrating is lighting. It’s fairly easy to get something that looks good enough outdoors if you don’t care about realistic lighting. However, the moment you step indoors, such as into caves, all immersion is gone. That constant ambient term you lazily set to simulate indirect lighting screws you badly in a cave that is supposed to be pitch black.

In the past I have used ray-based occlusion which kinda works. But in true stochastic fashion it’s a battle between spending time taking samples (casting rays) and dealing with low quality output. Noise like above is my nemesis, not only does it look bad in itself but it affects other filters along the pipeline (such as TAA) making things even worse. Let me tell you, there were times when I would rather let the player run at 5 fps than having to deal with more noise. In short, I’m terrible at denoising so let’s try fixing that.

I first thought that maybe I could cheat the noise by trying another approach, DDGI and light probes. Like shown above, you place a set of probes around the world and sample the light through these. This seemed to have been successfully implemented by Douglas in a similar engine to mine. However, I gave up quickly. To be fair, I didn’t spend that much time on it. It’s a neat idea but there are a lot of caveats, like where to place probes. I might continue on this track later but I got slightly distracted by Tiny Glade.

There is a certain elegance to throwing around rays like a madman and if you know what you are doing it looks really good (e.g. Teardown and Tiny Glade). Back to noise I go! I have gathered a handful of references for better denoising so let’s see if there is something I can do. The Tiny Glade GI solution seems particularly interesting.

Before ripping out the whole rendering pipeline I implemented a very simple path tracer that I can toggle to use as reference. It looks great but it’s completely useless for a game since it takes several seconds to converge to something that looks good. I don’t necessarily need to mimic it completely but it’s still good to have an understanding of what to expect.

Now I’m deep into an overhaul of the lighting pipeline, taking some inspiration both from Tiny Glade and Metro Exodus. Let’s see where that takes me.

Misc

Sound

I also tasked Claude with implementing a system for audio. It required some supervision, like telling it to use zaudio and exactly what API I wanted. But now I have sound in the game!

“Gameplay”

Here’s a short video to showcase the game aspects. Sorry for the quality though, my screen recorder went haywire and I have probably not touched video editing since I made a frag movie for CS 1.6.

Models

I implemented “models” into the game. A model in this case is just a small voxel structure not bound to the voxel terrain, such as something produced in MagicaVoxel. It can be transformed arbitrarily and I will need it to render things such as characters. Just as with the terrain, they are raycasted and they are integrated with the raycasting TLAS (kinda), meaning lighting and such just works as expected. The implementation is stupidly naive though and I will have to revisit this if I want more models in the world, like using a proper TLAS. The Vulkan ray tracing extension might help but that’s a big step.

Terrain generation

I wrote a small framework for describing scenes based on an SDF, so now I write them something like this:

pub fn scene(p: Vec3) Sample {
    const floor = plane(p, 4.0).as(.grass);
    const spheres = sphere(
        opRep(p, .{16, 0, 16}) - Vec{0, 16, 0},
        4.0,
    ).as(.dirt);
    return opUnion(floor, spheres);
}

The chunk generator then automatically handles determining what chunks to build, etc. This makes it really quick to test stuff.

Above I recreated my old procedural test terrain with this new system. I really should spend some time trying to make a terrain I might actually want to use in a game but procedural generation is such a deep rabbit hole.

Physics

For fun I tasked Claude Code to implement a physics engine while I was working on the graphics. It took a few tries but it actually produced something that almost works! The remaining work to get it functional should not be underestimated though.

Graphics

While restructuring my voxels I took the opportunity to also do some general graphics improvements, working on things such as TAA, SSAO, fog, and sun lighting. I basically rebuilt the rendering flow, from outlining the pipeline to slowly integrating the new voxel structure, so below you see a neat timeline of screenshots.

First thing I wanted to improve was TAA.

I think this was just a simple test scene while I was setting up the gbuffer. No lighting yet though.

Putting the voxel pass back in.

Added sunlight and shadows again, and SSAO from the looks of it.

One significant change from before is that I now store voxel materials separate from the chunk BLAS and here I was setting that up.

I think I made some attempt for fancy terrain, and failed.

To control the color of voxel materials I have a big texture atlas which the rendering samples. Here I was setting that atlas up.

And finally, I added the foliage back. This was actually slightly easier than before as my new voxel structure made it easier to place grass billboards as this is all done on the GPU.

What’s next

As mentioned, I’ll definitely look more into the lighting. I think something to prioritize is to make sure caves look good in terms of lighting. Then I think I have everything to be able to try out some gameplay ideas. And I will definitely let Claude continue trying things out. Maybe not physics or lighting (I tried…) but I have other ideas. I have noticed that as long as it’s high level tasks and you provide a solid foundation it gets things mostly correct.

Highlights

• Made progress on the “game”. It has been a lot of iteration on the voxel systems, but it’s moving in the right direction. Most fun has been learning more about all the graphics aspects (foliage, lighting, denoising, etc.).
• zynth was a cool side-project. It actually works and I learned a bunch of stuff: audio, drivers, Wayland, immediate mode GUIs, and more.
• Went full-time Linux for the desktop at home. Games have always been the big blocker but Valve has solved that for the most part. I still miss the Visual Studio debugger and I guess there are better tools than GDB but it’s enough for now. Looking forward to the RAD Debugger coming to Linux though.
• Made some very minor open source contributions (zgui, zglfw, zig-vma, simeks-zig). It’s an area where I want to do more, but I tend to focus on contributions that help myself and not doing it just because I can.

AI

I’ve experimented a bit with various AI tools that exist nowadays and here are some brief thoughts:

Auto-complete

This isn’t for me. It just makes me lazy and slow. You do that mental pause to wait for the autocomplete way too often and when I’m at the stage of writing code I tend to already know what to write.

Agents

I’ve tried Cursor, Claude Code, and Codex. Cursor was mostly annoying and it felt like I spent most of my time trying to make it not fail on simple project setup stuff (likely due to my own skill issues). I also really don’t feel like using yet another editor. Claude Code and Codex are more my taste. They are great for quick prototypes but the code quality is lacking. The code it produces tends to have a very limited shelf life and after a point you can’t really iterate on it without too much handholding. Another thing I noticed, if you want to use it in an existing project; you need a critical mass of existing code for it to learn your conventions, but if you have too much it tends to get overwhelmed. For now I might let it prototype but I will likely go in manually and refactor or pick the things I like.

ChatGPT/Claude

Probably what I use the most. It’s great for confirming things you already kinda knew, or to search for literature on topics. It manages to find odd blog posts I would never have found otherwise, and they are usually right on the money. You still need to be wary about what the LLM tells you though. It’s not too uncommon it misinterprets the references it collects.

Month in screenshots

This year I started doing monthly posts where I mainly focus on showing screenshots. This was a great idea and I will definitely continue. It’s a bit difficult when you work on less visual stuff but these posts are a lot quicker to write than technical posts. This is mainly for my own sake anyway.

Above might be screenshot of the year. Working on the grass was a lot of fun and this part was implemented while visiting Gotland for the summer vacation.

Puzzles

December is nice; not only did I get Advent of Code, but I also saw that FRA posted a puzzle. It was released earlier in the year, but it seems only one person had solved it. I managed to do parts 1-4 without that much of a hassle, but I hit a brick wall on the last part, so I gave up. It sucks, but I have learned a lot about hiding data in a certain medium so I will see that as a win.

I feel puzzles are a great thing. You tend to practice the same part of your brain as with your other projects but the objective is far more concrete. Hopefully you manage to solve it and not only did you learn something but you also got a feeling of success! The danger is of course that you won’t let it go if you ever hit that wall.

Side quests

I also like to get side-tracked and it usually starts with some idea in my head that I can’t let go of, and then it just continues on with me exploring the idea. I learn a lot during these periods and they tend to keep the spark going. Struggling with the same problem for too long isn’t great for motivation. But the rabbit holes are endless so you must be careful to avoid going all the way to writing your own OS…

Motivation

The large boosts of productivity or creativity I get tend to come at a price, and that debt was due in December. You are hyper-focused, the brain is working at 100%, and all of a sudden, all that energy turns against you. It’s like hitting a wall. You question everything and nothing seems fun anymore. I managed to direct my focus on some easy wins at work to keep me going, but even then it’s not a great mental state to be in. Christmas helped a bit with draining that surplus energy, and I can feel my motivation is coming back. I have another week off from work now so that’s a week of doing everything, or nothing. It’s all up to me!

What’s next?

I’m hyped for 2026. I’m a better programmer and problem-solver than a year ago and I hope I’m able to say the same thing next year. I haven’t set any long-term plans for the year but short-term I’m back to voxels so I’m hoping for some cool screenshots next post!

This month I managed to align quite well with the goals I setup for myself last month. I released a package of goodies that I can use for prototyping and I gave my synth an actual GUI. But there were plenty of side quests this month.

Wayland

Thanks to updating some packages I hit a very frustrating issue with GLFW. I use Wayland on my machine and GLFW deals with all window related stuff. For some unclear reason I got a weird stretchy letter box, which I figured must be related to the window management.

I consulted ChatGPT which wasn’t much help and it ended up blaming me and my code instead. I also tried out SDL, which didn’t have the issue, so I started to suspect some bug in GLFW. It tickled that part of the brain and I got curious whether I would be able fix it. However, I quickly realized I knew nothing about Wayland,

What better way to learn about something than doing it yourself? After reading about protocols, compositors, scanners, etc. I managed to piece together my own window handling. It’s not as nice and feature complete as using something like GLFW, but it works!

Someone managed to figure out a workaround for the GLFW issue so I could revert back to GLFW again. It’s very nice feeling to understand the code underneath you though, so I will probably stick with my own solution (until the day I need to support more platforms).

GUI

One issue solved, on to the next. I continued experimenting with my own immediate mode GUI. It’s very rewarding to work on as you see the results directly in front of you, but some things sure looks easier than they actually are.

One problem I looked into was layouting. The prototype I had before was a lot of just hand-feeding absolute positions to into a draw list. I wanted something more automatic, but how do you layout something without knowing the full picture beforehand. One example I encountered was determining the size of a panel. You queue a panel, then you queue the contents of the panel, and not until this is done do you know the size of the panel. I just opted for a 2 pass approach where I don’t render things directly, so I can update the panel command as soon as I know its actual size.

Talking of order of draw commands, another challenge is dealing with popups like dropdown menus. Luckily I know beforehand that I only need to support one level of overlapping elements so I went with just having a separate command queue that I ensure is drawn on top of everything else.

This blog post was a very interesting read on the subject.

Fonts

Initially I just had hardcoded bitmasks representing characters. It was fine for just uppercase letters and some special characters but it quickly got messy. Since I wanted to use the GUI in the game as well, I figured I should add proper fonts.

I didn’t really feel like writing my own truetype rasterizer or even depending on an existing one in the library itself so I added a pre-baked atlas instead. It’s basically just a TGA image and a ZON file. I picked TGA because its one of the simpler parsers to implement but I can still use it in most other software the deals with images. ZON I picked mostly because I like being able to just @import the data file.

Fonts are tricky, I’ve went for pixely font hoping it would be a bit simpler but there were still some challenges getting it to look right, like aliasing.

Zig Package

All this work went into an package I just call simeks-zig (in lack of a better name). This package is basically a set of tools mainly for myself to implement things like the synth. It’s provides a set of modules

• core: Various core tools
• gpu: Vulkan wrapper for graphics, it provides some high level concepts on top of Vulkan, such as a less verbose API and limited resource management.
• gui: GUI libray mentioned above.
• math: Math library
• os: For now only the window wayland wrapper.

They are far from complete but it’s a place for me to collect various things that I might need.

Synth

Using the package I managed to get a GUI going for the synth project with ease. I also played around with adding an envelope for the volume and some filtering. It was nice to have a smaller project to work against when setting up the package.

Game

I moved over the game project so that it now runs without zglfw and zgui. This is really nice as I’ve learned that trying out new Zig features is a bit tricky when having dependencies. I’ve helped a bit trying to keep them up to date with new Zig releases but sometimes you just want to quickly try something out on a Zig dev build. I’ll likely migrate back when things get more stable but I will enjoy the freedom while I can.

Migrating wasn’t that difficult, I only had a few contact points for third party libraries and the gpu module is basically the same one as I was using in the game already.

I did however decide to rehaul my hot-reloading a bit. It was a bit of a long shot and I haven’t gotten so far to determine if it was a success or not. The issue with my previous system was that it got very frustrating to deal with the layer between the host (executable) and the game (reloaded .so). It was an annoying barrier and putting something on the wrong side would cause a lot of pain down the line.

The idea I had now was to put as much as possible within the reloadable module. Just allocate the memory in the host and as you reload you just patch the memory in the new module. Can’t be that hard as long as I never change the memory layout?

Boy was I wrong. I spent a lot of time getting it to work, and I still have random failures every now and then. Some of the issues I encountered:

• Function pointers: VTables are commonly used with interfaces in Zig, such as in the Allocator, and they are problematic since they might point to functions in the library you just unloaded.
• Global variables: This is mostly my fault, but if you have global variables in a module you will have to patch these as well.

So we’ll see how this goes. There are more clever ways of doing this but not sure how much time I’m willing to put into this.

What’s next

Sebastian Aaltonen is currently working on a hobby project very similar to mine and he posts about it on X. This has really re-ignited the voxel flame so I hope to work more on that. But Christmas and Advent of Code is coming up so I’m certain I won’t be bored!

I started the month with a bit of a break. Given that the full-time job that I have sometimes can be quite demanding, it’s nice to be able to just let go of any expectations you have on yourself when you get home. Even if my hobby projects all are driven by genuine passion, sometimes nothing beats doing nothing.

Synthesizer

I quickly got the itch back though. One thing I have been spending my morning walks to the office thinking about is fun ways to integrate music into a game. And what do you need to make music? An instrument! This lead me into exploring software synthesizers. This was a fun project, I (re-)learned some signal analysis, I learned about pulseaudio, read up on the WAV file format, and I even learned about the fun stuff you can do with a terminal.

GUI

Another thing I learned is that a synthesizer is no fun without the knobs. You want to hear the sound change as you turn a knob, and this was hard to capture through the terminal. This pulled me into my next adventure, GUI! I’ve used a lot of Dear ImGui in the past and it’s great! I contemplated using it here as well, but I needed something way simpler and to be honest, I got curious… So I started prototyping my own immediate GUI library.

Screenshot above is an early iteration. I got simple text rendering working and imlemented some common widgets and of course, knobs. It’s not fancy, it’s not fast, but it actually renders correctly and the input works!

Given that I want to use the GUI for a synth, I also implemented actual keys. Don’t mind the missing #.

In the end I actually got something that I think might be useful. It has not been hooked up to anything yet but the library is simple enough to use, just some final tweaks then I will try to implement it with the synth. I’m working on packaging this library and the underlying Vulkan wrapper to make it available on github. This is mainly to make me able to still keep the synth repo open, but more on that in a later post.

Codex

I also tried out Codex for the first time. In general I’ve been underwhelmed by AI tools. I use ChatGPT every now and then to get a second opinion and the thinking models are actually good for finding references. But other tools, such as Github Copilot and Cursor have mostly been annoying. I installed Codex CLI and got impressed how smooth it was to get running. It immediately started chugging along on the first task I gave it. It checked compile errors, it ran tests, and produced actual functioning code.

It was not all great though, as complexity grew it required a lot more handholding and it frequently got stuck in “Fix A, Break B -> Fix B, Break A”-type loops. You also get a bit lazy. Initially I had such a flow with the prototyping that I didn’t even check the produced code but when I did I realized I’ll have to rewrite large portions of it. One fun example was a text renderer it wrote, it had a comptime function that translated every character in a string into actual draw calls, and it created one draw call for every pixel in the character…

Voxels

I didn’t completely forget about the voxels. I’ve been working a bit on setting up a sandbox for prototyping. It was a bit tiresome having to rewrite certain game systems every time I wanted to prototype a new idea for the voxels, so I ripped out the rendering part of it. Now I can more quickly prototype and profile some ideas I have.

What’s next

In order of level of commitment:

• Package and release the GUI + Vulkan backend.
• Actually hook up GUI with the synth.
• Put GUI into game.
• Back to voxels.

This month has been a bit of everything just to keep the ball rolling. I have mostly focused on small annoyances, some where maybe lower hanging than others.

Lighting

As I left the lighting half-finished it was time to pay the piper. Previous implementation traded performance for quality by just having a high number of lighting samples. This means there was naturally less noise but the cost was very high. So I set out to improve the performance by reducing the sampling and implement better denoising.

Above his how it looks with the noise. This is with 2 samples for the ambient occlusion, 1 sample for the sun light, and with lighting applied at half the resolution.

And after the denoising applied. Here I just compute the lighting of a pixel by averaging over a neighborhood, taking the surface normal and depth into account to not blur edges (bilateral filtering). Samples are also accumulated over time to make it even smoother (temporal filtering).

This made everything run smoothly on my macbook. It also made the job easier for the temporal anti-aliasing and now the world is more pleasant to walk around in. There are some subtle issues left though, like low frequency noise and small artifacts in corners due to the raycasting.

Grass

To put some life into the picture I set out to add some simple animation to the grass.

This is how it started. As always, ordering when applying transforms is important!

And this is how it ended.

Hot-reloading textures

As I did some work on the grass, including using my limited artistic talent to shape and color it, my frustration with having to restart the game over and over grew. So why not just do the same as with shaders, lets hot-reload!

I used the Zig build system and the handy --watch feature to create a build step for assets that automatically builds assets as they are changed. Then the game listens for changes in the built assets and reloads if needed. Now the actual build step is very simple, but I wrote a simple parser for the OpenRaster format (basically just unzipping a .png) as a proof of concept.

Misc

Here are just a collection of smaller things I worked on.

For the actual game part I have implemented tools as a way for the player to interact with the world. I took some time to reimplement this system to make them easier to implement. For now they don’t provide much in terms of gameplay but I have the basics for modifiying the voxels and I made myself a marker/ruler tool for some debugging purposes.

Implementing the tools above I identified some problems with the raycasting and to debug those I quickly put together rough grid view to visualize the voxel data structure (chunks and bricks). Lines are frickin’ hard to deal with.

What’s next

I have two goals in mind for the near term:

• Procedurally adding objects like trees to the world.
• Setup a file format for the voxel world. Mostly motivated by me wanting to play around some more with writergate, but there is also a point to being less dependent on the procedural generation when testing stuff.

First I need to deal with some annoyances when working with the voxel structure. I got the ball rolling with the tools system but there are still some loose ends.

This month my objective was to further work on the procedural world generation. There were still some loose ends when it came to the foliage system and I wanted to improve upon the framework I have for experimenting with procedural generation. The hot reloading I implemented initially has been very valuable, especially for things like the world generation. I make a change, save the file, and the change pops up live in my game. However, the issue is that so far the world generation has been slow, which delays the feedback loop.

Voxels

I have mentioned in past posts that I use a 64-tree to represent my voxels. This is great for the GPU side of things. It is a pain for editing voxels though, since you need to traverse the tree a lot. So I made some changes. Instead of having to deal with one 64-tree per chunk (64x64x64 voxels) on the CPU, I opted for keeping a big brickmap for the whole world, holding 16x16x16-sized bricks, which makes edits and generation a breeze. As I stream things to the GPU I build the trees on the fly hierarchically. If a single brick has changed, I only need to rebuild the sub-tree representing that brick. As a bonus this worked very well for foliage as well, I just tell the system to rebuild the foliage for a brick by providing the root node of the corresponding sub-tree.

Now with everything working I can say it was well worth it, but it was an adventure to get there. Here is some screenshots of my journey:

I think most of my bugs was like the ones above, you have weird bit shifts all over the place. If I remember correctly there were 2 main causes, either me providing incorrect offsets when writing the 64-tree (which in reality is just a stream of bytes). Or, the fact that GLSL provides a horrible developer experience, I utilize 64 bit integers a lot, and they are a bit wonky.

Since I now also pack everything into a single tree, there were also some issues getting that thing right. Transforming world positions into brick index, into voxel index, etc.

Then I needed the foliage system to place nice as well.

Now on to the fun stuff! Previously, I’ve mostly used a SDF scene I wrote myself because I haven’t bothered to go back to actual procedural terrain. Here is a buggy view of some 3D noise. The bug itself is not really related to previous bugs, it just had to do with the noise being too high frequency for the “smart” parameters I setup to not generate more than what is needed.

Here is a more reasonable example of procedural terrain. In this case it’s just a heightmap.

Some ridged fractal noise. In the screenshots all the procedural terrain is just rock but I have some code setup for the coloring as well. It is still a bit slow though so I really want to tighten that feedback loop first.

Profiler

One important aspect of making things faster is actually knowing how fast (or slow) something is. So another thing I worked on this month was a very simple low-overhead profiler. It is similar to tracy but without all the features. I just mark a block of code like this:

{
    profiler.beginZone("load_chunk");
    defer profiler.endZone();
    // Do stuff
}

and it collects statistics on how long that block of code ran. It works in a multi-threaded environment as well, which was needed since I generate chunks in a background thread.

I have no fancy visualizations yet, but we’ll see if I ever implement those. Tracy is a lot better for that. But I do get some nice live stats, and a summary when I close the program.

I also started collecting some more stats on memory usage for my voxels, a bit messy but has been very useful:

Slang

Did I mention that GLSL isn’t great? One thing that has gotten more and more frustrating as the shaders get more complicated is dealing with GLSL. Using Buffer device address in Vulkan is a lot of boilerplate, which was fine up to a point. Even more frustrating is that I have found myself often wrangle the language to make the compiler produce the SPIR-V I want. Since I develop on Mac sometimes I use MoltenVK, which has its owns set of quirks that I need to work around.

In comes Slang. It’s a more modern language for shaders that also compiles to SPIR-V (amongst others). I wanted to see if it could make the developer experience a bit better so I ported all my shaders to Slang. I haven’t dared to touch all the shiny features it provides compared to GLSL but I’m already very happy with it.

Ironically I haven’t been able to fully get it to work on macos yet. I did the mistake of updating the OS so now Xcode has blocked me out of using the graphics debugger until the new version of Xcode releases. I might be able to solve this by changing the build process to target older macos but my first attempts failed so I gave up.

Summary

This type of refactor can be a bit soul crushing but it’s also very exciting. You get the chance to actually do some problem solving and learn from your past mistakes. It’s a balancing act though, having visual feedback helps a lot in keeping yourself motivated but if you get stuck with code that won’t compile for too long, you just feel like giving up.

So, what’s next? Vacation ended in August and the autumn is closing in so I will probably try to focus on something high reward for next month to keep the motivation up. This means I should probably not spend that much time on the procedural generation. Adjusting parameters to get something you are happy with is a never-ending struggle and it tends to drain you, but we’ll see.