That slightly guilty feeling of adding even 0.05ms to rendering time per frame, when you're constantly worrying about and managing performance.

rendering the brick "backfaces."

I'm then scrolling the distance discard threshold, which creates an interesting "ribboned" appearance.

It could in theory be (almost) zero, but I'm leaving it above that to fill in what would otherwise be small cracks at LOD transitions.

/end

computing the normal, fetching the material, and writing to the G-buffer.

This is sort of a per-pixel "backface cull."

In the video, I clip into the surface to show what this looks like, as otherwise it's invisible. The blocky initial appearance is without the optimization,

2/

Another interesting small optimization to SDF brick rendering:

I'm already tightly fitting bricks to the surface and doing occlusion culling, but this is another small win on top.

If the camera ray intersects the brick at an "inside" point, discard the fragment to avoid ...

1/

Yeah, that definitely sounds cool, but also a bit out of my wheelhouse right now and also probably pretty perf-intensive.

Yeah, everything is dynamic so you can definitely do stuff like that. Fluid dynamics would be a whole separate system, though. Were you imagining anything in particular?

Now that I've added support for "strong" materials, I'm experimenting with interesting underground structures to dig around.

These metal "pipes" (or alien tendrils?😱) snake around, forcing you to navigate around them and leading you to resources. Future tools will destroy them.

Got my copy of the newest GPU Zen book (4).

Recommend this series, they are high-quality!

It's also nice to see the grand tradition of sequentially-numbered books containing collections of graphics articles continue :)

You can easily have hundreds of thousands or more, the limit is more in the spatial density of them, so you will run into issues if you have hundreds or thousands in a very small space.

It's still kinda wild to me how much tweaking the easing function changes the feel of what kind of materials and tools you're working with.

This video demonstrates "quintic" vs. "elastic" vs. none. The easing function controls the scale of the SDF subtraction.

Funny, I will add that on the list next to custard and mustard

It's funny how easy it is to make stuff look kinda gross in this engine. Already knew that but I sometimes forget when I am too deep in SDF la-la land :)

Planning to lean into grossness for some things but certainly not everything.

Noted :)

TBD 😄

Playing around with a different style for embedding resources underground. This is giving me more ideas - easy to forget there is so much possibility in different ways of combining SDF edits.

Raytracing Voxels in Teardown and Beyond YouTube video by Graphics Programming Conference

At long last, the Teardown talk from the 2025 Graphics Programming Conference has been posted 🎉

youtube.com/watch?v=IM1D...

(as well as another drop of some other great-looking stuff, check the channel)

Yeah, I actually did single-pass stereo rendering on my VR app from a number of years ago. It does save on draw calls, but for my current project the expensive part is ray-marching the SDF, not the draw calls

Thanks. Yeah, I agree that it will be tedious to spend a lot of time waiting for stuff. So either resources will be pretty scarce, or I may add a vacuum type of thing, TBD!

Yeah, I bet it would be pretty neat. I have a lot to deal with regarding perf already though, without VR :)

Thanks!

Isowulf v1.0 was released a week ago:
www.moddb.com/mods/isowulf

The tunnel gun returns! Added a "probe" tool to assist in finding resources when mining.

The idea is to reveal what's beyond walls - and also aid in extraction if you use gravity!

Feels satisfying, and I think it will also be cooler when I add more underground stuff like caves.

(I say this having just found myself considering implementing a general system for an N=2 situation :) )

A programming lesson that's been hammered into my skull is to not try to create a general system until you've implemented AT LEAST a handful of one-offs the system is supposed to support.

Otherwise you waste endless time fighting with and refactoring your "general" system.

Visual Studio's C++ hot reload was kinda-sorta working but with various glitches/limitations, and a bit slow.

I've now switched to Live++ and so far have been very happy, quite an upgrade in both speed and robustness.

(This is also for perf, as I was previously recalculating changes to collision mesh every frame for animations, which is usually pointless and can also lead to physics glitches.)

Currently 5-levels-deep in the refactoring mines, making it so arbitrary SDF edits can be visual-only (no collision) or collision-only (invisible).

The things you need to do for gameplay. For example: a probe that sees into into the SDF surface without affecting collision.

We noticed ;)

image showing demo tracker in use, in an obvious case where one program is using more GPU than the machine has.

I am not sure I can overstate how useful this tool is. Not sure if your game is paging out GPU-memory to system-memory? Well now you know :)

github.com/jonasmr/demo...

In the hacks-for-WebGL mines, I just saw this in the clustered-lighting article for Babylon.js (using additive blending to set per-light bits in a bitfield, in lieu of atomic-OR on a storage buffer).

Cool hack, don't think I had seen it before.

doc.babylonjs.com/features/fea...