Andrew Helmer

"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.

Yup, always tradeoffs in the constraints vs quality. Even in the multiclass SOT paper (which is maybe SOTA for this problem?), they show that the quality you get depends on things like whether you only optimize for powers-of-two, or every sub-sequence, etc.

Well that was @bartwr.bsky.social's terminology!

Oh sorry, you meant progressive stippling. I don't think they combined stippling and doing it progressively, but I think that technique *can* do it.

Scalable multi-class sampling via filtered sliced optimal transport We propose a multi-class point optimization formulation based on continuous Wasserstein barycenters. Our formulation is designed to handle hundreds to thousands of optimization objectives and comes wi...

Yup, this paper does it as one of the applications. They treat sub-sequences as overlapping classes (Progressive Sampling in Section 7.2, also Figure 14)

arxiv.org/abs/2211.04314

Totally recognize that the memory, latency, and statefulness constraints of games are very different. But I do miss how easy that was to work with, and agree we should teach concurrency before parallelism and the low-level constructs

Google Search's main logic backend was largely a C++ dataflow graph, with support for timeouts and such. Code was super easy to read, modify, and debug, and no race conditions (because code is not executed until all the inputs are available).

Our #SGP25 work studies a simple and effective way to uniformly sample implicit surfaces by casting rays. (1/9)

“Uniform Sampling of Surfaces by Casting Rays” w/ @abhishekmadan.bsky.social @nmwsharp.bsky.social and Alec Jacobson

This is my favorite kind of paper. The ones that make everyone else go "why didn't I think of that?"

Yeah, could be! But sometimes things that are intuitive and seem obvious in retrospect, weren't actually obvious or widely known beforehand. Put another way, this may be an application of that fact, but there's a difference between knowing a fact and realizing that it can be applied to a problem.