Andrew Helmer

My first 3D software!

For anyone who's tried to use spherical harmonics for lighting and found the notation- and terminology- heavy definitions confusing, highly recommend this classic: grahamhazel.com/blog/2017/12...

I think Graham Hazel's blog was down for a long time, years maybe, but works now!

Computing the exact bijection of the optimal transport (OT) problem between very large point sets is completely untractable…

In our SIGGRAPH Asia 2025 paper: “BSP-OT: Sparse transport plans between discrete measures in log-linear time” we get one with typically 1% of error in a few seconds on CPU!

Ten Years of D3D12 For those of us that have been using it from the start, it can be hard to believe that Direct3D 12 has been around for nearly ten years now. Windows 10 was released on July 29th 2015, and D3D12 has be...

I've got a new blog post for all of you fine folks! It runs through the additions to D3D12 since it was released, and finishes up with some of the things that have changed for me personally in my code.

(And yes it's really been 10 years 👴).

therealmjp.github.io/posts/ten-ye...

That wouldn't surprise me, or at least Pixel chips haven't improved nearly as much as QC (and definitely not Apple). The Pixels have 50% more RAM than comparable iPhones though.

It's not a regression though, the 10XL is still faster than the 9XL according to Geekbench. Just that Pixels were never near Apple perf, which isn't new.

Paper here: diglib.eg.org/bitstream/ha...

YouTube video by High-Performance Graphics Spherical Harmonic Exponentials for Efficient Glossy Reflections

Highly recommend Peter Shirley's presentation of "Spherical Harmonic Exponentials for Efficient Glossy Reflections". As always, he makes notation-heavy math way more accessible, and it's an amazing technique: youtu.be/jN7FX5COASM?...

Great Siggraph 2025 presentation of Gran Turismo's tonemapping pipeline, which also includes a fantastic introduction to light perception and tonemapping, its origins and how it evolved over the years with display technology, recommended read: blog.selfshadow.com/publications...

"Hallucinations on the future of real-time rendering", High Performance Graphics 2025 keynote: c0de517e.com/023_hpg.htm

Your cone solid angle sampling post reminded me of this!

Always a great reference for generating an orthonormal basis from a unit vector: jcgt.org/published/00...

At SIGGRAPH 2025, Intel, Disney, & Chaos are doing a course on the nitty gritty details of implementing path guiding methods in 3 production renderers: Cycles, Hyperion, and Corona. I helped write the course notes: 80 pages of great stuff! Coming soon.

s2025.conference-schedule.org/presentation...

Announcing a port of Angband running entirely in-browser. Angband is a venerable roguelike dungeon-crawler set in the Tolkien universe.

There are a bunch of follow-ups, and the libdivide library to do this at runtime:

ridiculousfish.com/blog/posts.h...

libdivide.com

Or maybe do precomputation on a CPU and give the values to the GPU for the divisions? Maybe good for finding cells in a uniform grid that is not a power-of-two size.

Found this cool blog post explaining one way to optimize integer divisions by a constant divisor: ridiculousfish.com/blog/posts/l...

Could be useful for a lot of things. Eg hash-map with a prime number of entries, do the precomputation on initialization.

I don't think this is bad at all. In addition to being well documented, it's well contained. Hacks like these are often necessary, what really becomes problematic is when they're spread all over the place through the codebase and make other code brittle.

Oh this looks great! I've been looking for an easy-to-use C++ library parser.

All HPG 2025 papers are now available on the EG digital library.
CGF papers: diglib.eg.org/handle/10.23...
Conference papers: diglib.eg.org/handle/10.23...
It has been a huge honor to act as HPG papers chair and guest editor and I look forward to an exciting program in Copenhagen.

Yeah, me too. But that still doesn't support their statement that someone is interrupted "every 2 minutes". That's the most extreme assumption - that every message is an interruption. The opposite extreme is that only one single message each day is an interruption. Both extremes are wrong.

By their metric, one 30 minute conversation with 50 messages is the same amount of interruption as a unique message every ~10 minutes throughout the 8 hour workday. In one of these cases you get 7.5 hours of uninterrupted focused work, and in the other you get interrupted every 10 minutes.

Of course many async threads is terrible. But if I'm in an active conversation with a person (whether it's messaging, or in real life), yes it can be a distraction, but it's wrong to refer to every single statement that person makes as a unique "interruption".

Hmm looking at their absolute numbers, it seems like they are not distinguishing.

None of this takes away from your high level point at all, distractions have gotten way worse. But the "average 2 minutes" looks like a very misleading, arguably incorrect stat.

The mean time between receiving emails for me is probably a few minutes, and probably shorter for the mean time between Slack messages (DMs or tags). But the vast majority of those aren't interruptions.

It's totally possible MS is actually classifying which ones are interruptions in a sensible way.

I'm curious about a lot of these metrics. I get an email for every CL submitted into our codebase, but it goes directly into an archived label. Does this count as an "interruption by an email"? If I've already started a conversation with someone, does each new message count as an interruption?

Gigi Version 1.0.0 released!
This includes WebGPU code generation, and the dx12 preview feature cooperative vectors.

A gallery of a few Gigi techniques that you can run in your browser:
electronicarts.github.io/gigi/

Gigi:
github.com/electronicar...

Oh wait, sorry, the distance between two points would be the *maximum* CDF differences amongst projections. Not minimum.

Yup, that's why I mentioned it! I think you could apply this to make a distance measure for best candidate sampling.

Very similar to your number #2, but not the same. Possibly beneficial cause you can precalculate a large number of projected CDFs. Then you *could* make it reasonably fast to do the lookups O(klogn) for the n+1th point, where k is the number of projections you check.

The sliced optimal transport approach to this would be to calculate a CDF of your image along many projections. The "distance" between two points is the minimum CDF difference among all projections. Could also try something like the sum of projected CDF distances squared.