Part 4 of the Metal PathTracer Architecture series, based on the renderer documentation snapshot created on May 14, 2026.

There is a particular kind of path-tracing problem that appears after the first exciting milestones have passed. The image is correct enough to be interesting, the direct lights are behaving, and the renderer can move around interactively—but diffuse indirect light still consumes a large part of the budget. Every bounce has to discover the useful directions again, and many paths spend their time in places that contribute very little to the image.

I have been exploring two ways of making that search more informed: a path-guiding prototype and a radiance-cache prototype. They address different parts of the problem. Guiding changes where a diffuse path looks next. Caching changes whether a sufficiently deep path needs to continue at all. Both are deliberately conservative, experimental features. They are disabled by default, and the renderer keeps the ordinary sampling path available as the reference behavior.

Learning a directional preference

The path guide divides the world into hashed cells. Each cell stores a directional distribution over the upper hemisphere, represented by an 8 by 8 set of bins. Directions are encoded with an octahedral hemisphere mapping, which gives the prototype a compact way to accumulate and look up directional information without maintaining a large geometric structure.

Training is based on quantized luminance and sample counts. A bright contribution gradually makes its direction more likely to be useful, while the sample count provides a simple measure of how much trust to place in that observation. This is intentionally a modest representation. It is not trying to model every detail of the scene or replace the BSDF; it is trying to answer a narrower question at a diffuse surface: “Which parts of the hemisphere have shown evidence of carrying light?”

That question only makes sense for the right kinds of paths. The guide is restricted to eligible diffuse-style events. It rejects specular-only modes, delta samples, BSSRDF and transmission or exit-point samples, medium events, non-diffuse lobes, invalid PDFs, and non-finite weights. Those exclusions are important because a directional histogram trained on incompatible events would look plausible while quietly changing the estimator's meaning.

When the lookup is valid, the guide does not replace the BSDF proposal. The renderer forms a mixture between the ordinary BSDF sample and the guided proposal. The probability of choosing the guided side is limited by both a user-controlled strength and the confidence learned for that cell. The selected direction is then reweighted through BSDF evaluation. In other words, the prototype is allowed to suggest a promising direction, but the material model remains part of the decision and the weighting.

This mixture is also useful while the guide is learning. Early in a render, a cell may have only a few observations. The confidence term keeps that sparse information from dominating the established sampler. As more samples accumulate, the guided portion can become more useful, but the control remains explicit. I want a bad or stale guide to be easy to turn off and easy to identify, rather than an invisible influence on every result.

Remembering an indirect answer

The radiance cache takes a different approach. It is a rough indirect-termination cache stored in the same kind of hashed world-grid domain, but its key includes more than position. The prototype distinguishes world-space cell, path depth, material type, and lobe type. That extra context helps prevent an observation made at one depth or for one kind of material from being treated as interchangeable with another.

Each entry stores quantized RGB radiance accumulators, a luminance-moment proxy, and a sample count. It also keeps normal and roughness metadata, material and lobe metadata, a frame tag, confidence, and invalidation state. The metadata may seem excessive for a rough cache, but indirect light is exactly where an attractive shortcut can introduce a difficult-to-see bias. A cache needs enough context to decide when an old observation is still relevant.

Queries are therefore gated. A path must be deep enough, the material must be cacheable, the sample must be diffuse and eligible for the intended reuse path, and the BSDF sample must be finite and non-delta. A hit still has to pass matching metadata, sufficient normal agreement, a bounded roughness difference, finite radiance, an acceptable bias-risk check, and a confidence threshold.

If all of those tests pass, the current path can terminate by adding the cached value multiplied by the current throughput:

throughput * cached_radiance

That equation is compact; the conditions around it are the real feature. A miss is not an error. A rejected hit is not forced through by a clamp or a guessed value. The path continues, and the current BSDF sample may train the cache. The cache is consequently allowed to be incomplete while it is learning, and it can remain conservative in areas where its evidence is weak.

Why keep both prototypes?

Guiding and caching improve different failure modes. Guiding can make the next sample more purposeful without ending the path early. Caching can avoid a long, low-value tail when the renderer has enough contextual evidence to estimate the remaining contribution. Used together, they might reduce wasted work in diffuse-heavy scenes, but their boundaries need to remain visible so that one experimental mechanism does not conceal a problem in the other.

That visibility is part of the architecture. The renderer treats the guide and cache as named, gated state with explicit confidence and invalidation behavior. I can inspect whether a feature is active, whether a lookup was accepted, and whether the path continued. This makes an image easier to reason about than one produced by an opaque “fast mode.” It also makes it possible to compare against the baseline sampler when an improvement looks suspiciously good.

For now, I describe these as prototypes rather than finished solutions. They are focused on diffuse indirect paths, guarded by eligibility checks, and subject to the usual concerns around history, scene changes, and bias. The interesting work is not only making a cache hit or a guided sample happen; it is defining when those shortcuts are trustworthy and making every other case fall back to path tracing honestly.

The longer-term question is how much structure a real-time renderer should retain about the light it has already seen. A directional guide remembers where to look. A radiance cache remembers an approximate answer. Both are small experiments in giving the renderer a useful memory without letting that memory become an unexamined source of bias.

Continue the series

Previous: Reservoir Sampling Without Overclaiming ReSTIR.

Next: History Is a Rendering Resource.