iiinova — where your digital self keeps evolving

Tomasz Stachowiak @h3r2tic.bsky.social · 14/05/2026

.. what an include might do, or indeed, what issues the including file might introduce in the includee. On top of that, Slang working with the language server in vscode (jump to def, autocomplete, etc) makes for an experience that feels like a real language - rather fresh in the shading lang space!

120

Tomasz Stachowiak @h3r2tic.bsky.social · 14/05/2026

Having modules + pluggable I/O is a huge win too. I was able to create a VFS that spans the Rust Cargo package manager, and can now import Slang modules across Rust crates. I've hacked something like that on top of HLSL before, but the lack of hygiene in the latter meant that you could never know..

120

Tomasz Stachowiak @h3r2tic.bsky.social · 14/05/2026

<3 Oh hey, thanks for (co)creating it! I also like how the language prelude is not completely magic, and the various intrinsics are still available in (careful) user code. That was handy for my bounds-checked RW buffer wrappers, so they can be transparently swapped for the built-in ones :)

110

Tomasz Stachowiak @h3r2tic.bsky.social · 14/05/2026

And, as a convention of ours, any loose resources in a Slang "entry point" module become those strongly-typed params at dispatch site, while param blocks declared in utility modules are supplied by a FrameGraph-like stack. This way you can "push" bulky read-only resources once and they auto-bind.

130

Tomasz Stachowiak @h3r2tic.bsky.social · 14/05/2026

So that's all fun for scene object draws that need to be as efficient as possible, but in many other cases, you want convenience. The Slang reflection API then enables us to codegen Rust glue for shader entry points so they don't need to rely on stringly matching for one-off dispatches/draws.

150

Tomasz Stachowiak @h3r2tic.bsky.social · 14/05/2026

Shaders don't need to worry about descriptor sets or bindings then, and the Rust side can cluster those any way it wants. For most of our scene rendering, we use the classic frequency-based grouping, but this way we can easily move bindings around by just changing the clustering on the Rust side.

130

Tomasz Stachowiak @h3r2tic.bsky.social · 14/05/2026

Instead, in the new backend, our Slang modules use a bunch of parameter blocks which get automatic descriptor set assignment. That creates potentially dozens of descriptor sets tho, so on the Rust side, we cluster those virtual/logical parameter blocks into <= 4 larger ones, and patch the SPIR-V.

130

Tomasz Stachowiak @h3r2tic.bsky.social · 14/05/2026

Last I checked, Molten could not consume MSL, so we take the Slang -> SPIR-V -> MolvenVK (spirv-cross -> MSL) path. It was mostly about the binding model - Slang's explicit `ParameterBlock` construct is pretty handy for that without having to pre-declare explicit numerical bindings ahead of time.

290

Tomasz Stachowiak @h3r2tic.bsky.social · 14/05/2026

Oh and _finalFinal2 but not the least_, Molten doesn't support robust buffer access, so we had to ensure that there were no stomps via any RW buffer writes. No off-the-shelf tool seemed to catch those, so I ended up implementing bounds-checked variants of RWStructuredBuffer and RWByteAddressBuffer

180

Tomasz Stachowiak @h3r2tic.bsky.social · 14/05/2026

FWIW winit is still the only backend for all our misc windows, e.g. the crash reporter and the standalone Vulkan settings configurator.

000

Tomasz Stachowiak @h3r2tic.bsky.social · 14/05/2026

On Windows, we had issues with winit's unusual handling of borderless mode (tho that was fixed by a light fork that just sets WS_POPUP on the window) So overall I had quite a list of reasons to try SDL, but didn't want to quite ditch winit, so made it load-time switchable instead.

110

Tomasz Stachowiak @h3r2tic.bsky.social · 14/05/2026

On Linux, the Steam Overlay doesn't work with winit because the former is naughty and hooks a bunch of C libs, which winit doesn't use. The SDL backend also had better animation smoothness on one of my dev machines - probably different compositor interaction.

110

Tomasz Stachowiak @h3r2tic.bsky.social · 14/05/2026

winit would also sometimes fail to set borderless mode, and claim negative window sizes at startup. I'm sure it's all fixable (and maybe already fixed, but updating winit is a pain). I have near zero Mac experience and just wanted to get it running - aaand also wanted SDL for the sake of Linux.

110

Tomasz Stachowiak @h3r2tic.bsky.social · 14/05/2026

Yes and no - the OG motivational issue with "winit" turned out to be a MoltenVK bug that triggered frequently under winit. But then SDL ended up working better wrt trackpad input (weird non-linearity w/ mouse grab on winit, scroll gesture detection out of the box w/ SDL)

210

Tomasz Stachowiak @h3r2tic.bsky.social · 13/05/2026

TBDR didn't give us issues, but our render passes always use just one raster pass. Tiny Glade is heavily deferred, so mostly benefits from making data as small as possible (textures, verts), and reducing barriers.

190

Tomasz Stachowiak @h3r2tic.bsky.social · 13/05/2026

There were also a bunch of Mac-specific workarounds in a few places, like shaders that miscompiled, or MoltenVK incorrectly handling swapchain recreation (PR filed and merged). And then finally, Mac uses SDL for window system interaction by default (we now support both SDL and winit).

2130

Tomasz Stachowiak @h3r2tic.bsky.social · 13/05/2026

The shadow changes made our brute-force volumetrics too expensive, so I rewrote them using froxels, and also added support for local lights therein for funsies. Oh and volumetrics get hybrid partially ray-traced shadow maps due to the aggressive culling of objects in the main cascades.

1140

Tomasz Stachowiak @h3r2tic.bsky.social · 13/05/2026

On the shader side, we've switched from HLSL to Slang. Then when it comes to higher-level stuff, shadows were a major bottleneck on the MacBook Neo, so they now use SDSM and precise culling (using a shadow visibility mask based on screen tile contents; no occlusion culling yet tho)

2190

Tomasz Stachowiak @h3r2tic.bsky.social · 13/05/2026

We now also precompute 99% of pipelines to avoid shader compilation stalls since compiling shaders via MoltenVK is much slower than on PC. I've also fixed a few validation errors that newer Vulkan SDKs started detecting, and fixed a swapchain misuse when the compositor hands us images out of order.

1150

Tomasz Stachowiak @h3r2tic.bsky.social · 13/05/2026

It was (initially) mostly about efficiently using the API - TG used OpenGL at the start, so our binding model was a huge anti-pattern in Vulkan (and thus Metal). The new backend uses descriptor sets as a first-class feature, deduplicates state changes, and does less bookkeeping of object lifetimes.

1293

Tomasz Stachowiak @h3r2tic.bsky.social · 30/07/2025

There's a Mac section in the Steam post 👀

040

Tomasz Stachowiak @h3r2tic.bsky.social · 14/03/2025

As long as it's not Intel (U)HD Graphics, it should still run decently well, especially with the new upscaling :)

000

Tomasz Stachowiak @h3r2tic.bsky.social · 14/03/2025

Aaaaalmost full - our GPU selection / driver warning screen doesn't support controller input yet

010

Tomasz Stachowiak @h3r2tic.bsky.social · 14/03/2025

Do you mean other devs? Tiny Glade has been Linux-native from the start :)

100

Tomasz Stachowiak @h3r2tic.bsky.social · 13/03/2025

Thanks, maaan :D *dances around* (That's some crazy company to be in xD)

010

Reposted by Tomasz Stachowiak

Tiny Glade 🏰🌿 @pouncelight.bsky.social · 13/03/2025

This is pretty insane 😳😳

1620814

Tomasz Stachowiak @h3r2tic.bsky.social · 17/12/2024

One of the benefits of a microscopic team, but also kind of a necessity; maybe the real thing would actually work better if we poured more time into it, but we can't quite afford the time to find out ^^; In the end we still piggy-back on the research done by grown-ups to pull off our silly hacks xD

020

Tomasz Stachowiak @h3r2tic.bsky.social · 16/12/2024

Yes, but poorly xD bsky.app/profile/h3r2...

110

Tomasz Stachowiak @h3r2tic.bsky.social · 16/12/2024

And this right here is why ye olde tiled lighting would never fly in Tiny Glade :D (build by Omayli)

2701

Tomasz Stachowiak @h3r2tic.bsky.social · 09/12/2024

Cause the contribution weight contains noise that you multiply into the otherwise potentially noise-free radiance (noise-free if you manage to discover all the lights to evaluate)

010

Reposted by Tomasz Stachowiak

Mikkel Gjoel @gjoel.bsky.social · 07/12/2024

Finally online, the brilliant talk Pondering Orbs by Mikkel Svendsen on the rendering of the similarly brilliant game Cocoon youtu.be/8kS17jt38XQ?...

youtu.be

Pondering Orbs: The Rendering and Art Tools of COCOON

YouTube video by Graphics Programming Conference

16316

Tomasz Stachowiak @h3r2tic.bsky.social · 08/12/2024

Oh, and thank you for the kind words <3

000

Tomasz Stachowiak @h3r2tic.bsky.social · 08/12/2024

Hah, well, falling back to ray tracing would likely be great, but even if the potato geometry was sufficient, we likely couldn't afford it. But hey, there's probably use cases where that's juuust fine :)

000

Tomasz Stachowiak @h3r2tic.bsky.social · 08/12/2024

I've used a lot of ReSTIR before in my toy rendering engine - which I'd made specifically to mess around with global illumination algorithms. It's all about trying a bunch of techniques (for many years), and then mixing & matching in strange new ways.

120

Tomasz Stachowiak @h3r2tic.bsky.social · 08/12/2024

Glad you found the content density to your liking :D We'll see, I would need to get a HDR monitor first xD I've been eyeballing some for a while, so it's plausible.

020

Tomasz Stachowiak @h3r2tic.bsky.social · 08/12/2024

I'll get on that Infected Mushroom licensing deal right away.

040

Tomasz Stachowiak @h3r2tic.bsky.social · 08/12/2024

Nope, I've had enough clicking :P Have this instead. It's a bit broken of course; needs a denoiser, and likely a shadow cache, as screen-space stuff breaks apart at this scale.

130

Tomasz Stachowiak @h3r2tic.bsky.social · 08/12/2024

Thanks dude :) Glad to hear that the game works like hypnotoad for rendering folks too xD My guess is that we'll keep evolving the renderer to cope with the kinda craziness that players throw at it :D (assuming the game remains popular) Should be fun!

020

Tomasz Stachowiak @h3r2tic.bsky.social · 08/12/2024

The probabilities of the losing lights are used in the math, so that the expected value is the mean of all the lights, not just the chosen ones. Standard importance sampling stuff, with picking from a PMF, only realized in a streaming fashion via reservoir sampling.

010

Tomasz Stachowiak @h3r2tic.bsky.social · 08/12/2024

Indeed :) It's about designing the failure mode, and for UGC stuff, bias (or even noise) is possibly better than terrible performance, tile-shaped artifacts, or harsh limits. I'm can't wait to see what kinda trickery you come up with for HypeHype! :)

030

Tomasz Stachowiak @h3r2tic.bsky.social · 06/12/2024

Thank you! I think it might be one of the benefits of hyper-specializing tech for our game. This would likely be way trickier for the devs of a larger engine to pull off ^^;

170

Tomasz Stachowiak @h3r2tic.bsky.social · 06/12/2024

:D "Ummm yeah, can you elaborate a bit on slides 50 to 130?"

010

Tomasz Stachowiak @h3r2tic.bsky.social · 06/12/2024

(But I've also just realized that there's 16 spare bits in each reservoir, which could be used to encode depth, and cheaply reject poorly fitting reservoirs, reducing the bias)

070

Tomasz Stachowiak @h3r2tic.bsky.social · 05/12/2024

They all come in the same radius and intensity. If we unlock that at some point, we'll see if the data structure needs adapting :)

020

Tomasz Stachowiak @h3r2tic.bsky.social · 05/12/2024

Hahha, wow, at least I bet Gilbert and Sullivan would have been proud. [cue I Am the Very Model of a Modern Major-General]

110