noah

this is the best resource I’ve ever found; it explains the abstract concepts (turning a PDF into a CDF, etc.) but also walks through actual code

I don’t learn things from videos but I learned so much from this one

my hobby engine’s bidirectional reflectance distribution function (tldr: Where The Light Go) was super fucked up in ways that weren’t obvious in the scene that I’d been working on everything else in the engine with. I finally tried it out with a more standard test scene, saw how fucked up it was, went through Crash Course in BRDF Implementation and the Frostbite PBR paper, and seem to have successfully un-fucked it. hooray!

never talked myself into learning WebGL because GL is such a messy API and Javascript is such a messy language, but WebGPU addresses at least the first half of that¹ and Safari is starting to support WebGPU so I’ve finally been getting into it.

GPU programming can be fun as hell but Metal (my preferred environment) is only on Apple platforms and DX12 (which I gather is broadly similar) is not on said platforms so there’s been nothing² that I could use to make something people could play with that worked everywhere; WebGPU seems like it’ll be the answer to that.

this image is basically a “hello triangle” but with a twist: the render pass is using data that’s populated by a preceding compute pass. it was surprisingly straightforward to set up which makes me very excited to build something real.

1. the second half of that is supposedly addressed by TypeScript but I have an irrational distaste for Node so I cannot compile TypeScript

2. no, not Vulkan—my distaste for that is extremely rational because life is too fucking short

been getting back into my hobby renderer / engine project and have done basically nothing to the rendering itself for a week or two (after fixing a fun GPU race condition that caused memory faults and flickering); I’ve been all in on infrastructure and editing, turning it into less of a “one viewport to look around in” toy and more of a workbench.

the mildly interesting data-model thing I’m doing, which is also a source of some grief, is that the entire world state is a value type: it’s a struct containing more structs, so there’s no lifetime stuff to handle—if you have a World then you can do what you want with it without affecting anything else. this makes concurrency kind of a non-issue since I can just hand the renderer a copy of the current World to chew on. it also makes editing the world—dragging things around, or editing properties in the inspector panel—a little funky because somebody has to own the “real” world and handle propagating changes between that and the UI. which adds a little complexity compared to just handing around reference types, but hopefully will produce fewer bugs.

there’s still lots to do on this editing infrastructure—those inspector fields aren’t editable yet, obviously, and they also don’t yet respond to changes in the world like moving the camera around—but once that’s done I’ll be able to get back to the fun part, and will hopefully have some more interesting pictures.