Mike Turitzin

There's a lot to say about that, but at a high level, I'm using a "brickmap" that stores a pointer in each cell (which can be null) to the brick, which is allocated from an atlas. And then I use a clipmap centered around the camera with a number of levels for LOD.

Making an animation illustrating sparse allocation of SDF bricks:

- White line is the analytic SDF curve.

- Sparsely-allocated cells (and distance samples) are shaded.

- Yellow line in the reconstructed SDF curve from cached samples (via bilinear interpolation of distances).

Just learned that the equivalent of "warp"/"wave" in ispc is a "gang".

"Gangs of Program Instances" has a certain menacing ring to it 😁

Yep, my engine is SDF-based.

(In case you were wondering, the character depicted is Sir Potato Face.)

My foes when I confront them

Indeed

A lesson I've learned: digging holes into shiny red stuff always ends up looking pretty gross🤨

It works! The dumping code is very short, and no loading code is needed (other than the code I copy/paste).

I want to save/load scene data in my engine, but I don't want to implement a real system for this yet (partly laziness, partly don't want to commit to a design).

So my quick solution is to dump literal C++ code that creates all scene objects. Then copy/paste into my init code😂

Sadly I don't think I will be able to model exactly Mr Potato Head as I removed ellipsoids from my engine.

From my notes about stuff to add in the video about my engine (lol)

Another funny thing is that the overlay in the UI here looks intentional but is actually just the debug rendering of the capsule shape :D

Playing around with a "tunnel gun" that can open a tunnel in front of you that can be looked into or moved through.

This type of thing is really simple in my engine - just spawn an SDF capsule subtraction that is locked to the player's view.

Good ideas. I haven't thought about the "mound" part too much yet but you're right there is definitely interesting design space there.

Ha, good question. The end game is ... a game. This started as a technical exploration, and right now I'm putting together a video on what I've built so far, so I'm re-exploring some older stuff for the video.

Then it's full steam on game dev!

Playing around more with the Donut County vibes - but this time you have both a portable hole and a portable mound.

And the hole grows bigger when it consumes cubes, because that's what holes do (obviously).

Feeding the hole.

Herding cubes, HD remaster.

Anyway, I'm glad this is done, as it was a pain in the ass to implement :)

/end

It's also worth mentioning that the clipmap LOD I use for SDF rendering added more complexity to this and I had to rethink my approach a couple times.

Basically, you can only render LODs to the cached shadow map that are guaranteed to be available within its footprint.

7/

YouTube video by Rendering Engine Architecture Conference REAC 2025: Pushing 60hz. Shipping Indiana Jones and The Great Circle.

The general approach I took was inspired by this recent presentation on Indiana Jones and the Great Circle (link is to the relevant timestamp):

youtube.com/watch?v=0QYE...

They also time-slice updates to the shadow map, which I don't do currently.

6/

I'm not currently rendering any non-SDF geometry, but the plan is to render that on top of the SDF shadow maps each frame, as it will be much cheaper to render. The SDF shadow maps thus don't need to be re-rendered even if other parts of the scene are changing.

5/

The net effect of this is that shadow map rendering is generally taking less than 0.5ms per frame.

I was worried about the cost of shadows because ray-marching 3D textures (as the SDF is rendered) is not particularly cheap. This solution makes shadows quite cheap.

4/

When the camera moves, the cascades are re-rendered in chunks. I could scroll the new chunks in smoothly, but for now they just pop in.

Any modifications to the SDF are projected into cascade space, and only the affected rectangle is re-rendered.

3/

This video shows the world-space cascades centered around the camera. If the camera hasn't moved outside of the current shadow chunk and the (SDF) scene hasn't changed, no shadow map rendering happens at all.

2/

Finished work on directional light shadows (for now!).

This took a while because I didn't implement "normal" cascaded shadow maps (via frustum slices) but rather world-space cascades that are updated in chunks as the camera moves, and incrementally when the scene changes.

1/

Good to hear.

I haven't used either of these but I am intrigued in particular by NVRHI.

GitHub - NVIDIA-RTX/NRI: Modular extensible low-level render interface (RHI) with higher level extensions Modular extensible low-level render interface (RHI) with higher level extensions - NVIDIA-RTX/NRI

things like synchronization for an easier dev experience.

NRI: github.com/NVIDIA-RTX/NRI
NVRHI: github.com/NVIDIA-RTX/N...