Numbers have grain

1A tolerance fattens every shape

A ray marching towards a surface (chapter 2) stops once it is within the tolerance: it has hit. So every shape is traced as if it were that much bigger all round. For a large shape that changes nothing anyone sees. For a glowing disc 1 cm in radius, 2 cm across, at its scene's automatic tolerance of 0.91 mm, it does. In the flat world here, rays from the camera that pass within the tolerance of the face count as hits too (red), and the face, seen 37° off the disc's own axis (the dotted line square to it: the floor in the bench's test sees the lamp at that angle), is traced 1.11 times as wide. In 3D, face on, the disc is traced as one of radius 1.091 cm: 1.091² = 1.19 times its area. Seen 37° off its axis its outline is an ellipse, narrower by cos 37°, and the same margin all round adds more to a narrower shape: 1.22 times (Steiner's formula: an outline grown by a margin gains the margin times its perimeter, plus a circle of the margin; computed). A glowing surface sends light in proportion to its area, so the disc put 1.22 times too much light on the floor.

ShadyTracer's bench found exactly that. One of its tests compares the same lamp two ways: as a light, whose rays start on the disc itself and so are not fattened, and as a glowing object that rays must find, which is. The ratio of the two, the light's brightness divided by the glowing object's, read 0.80 to 0.84, where 1/1.22 = 0.82 was predicted (measured on the user's Ampere card, 2026-09-29: the user is ShadyTracer's developer, who runs its tests, and Ampere their newer NVIDIA card; docs/TESTING.md).

At 10 µm, the fattening is 1.002, a ratio of 0.998 predicted; the pair read 0.994, about where the test's other pairs read, 0.995 (the user's Ampere card, 2026-10-02). Nothing about the lamp changed: only the length that decides when a ray has arrived.

Another of the tolerance's jobs makes thin gaps vanish. Where a ray meets glass, the renderer must know what lies beyond the face, since how much a ray bends depends on how much each material slows light, its index (chapter 10). It asks for the material twenty tolerances past the face (the table of every use, section 4, its row "two steps off"). Two slabs of glass 0.5 mm apart, at a tolerance of 0.1 mm (a metre-sized scene's automatic one): at the first slab's back face the question lands 2 mm across, inside the second slab, and the answer is glass. Glass against glass is no face at all, so the light goes straight on: the two slabs are traced as one, with two faces instead of four. The pair then lets through 0.923 of the light, one slab's share, where two let through 0.857 (each face reflects some, Fresnel's law, chapter 10, by optics/fresnel.js). The bench's row for it was expected to fail at its scene's automatic tolerance and did, reading 0.9228 (the user's Pascal card, 2026-09-27).

At 10 µm the question lands 0.2 mm across, in the gap's air: two slabs, and the bench's row at 10 µm passed. A shape or gap thinner than twenty tolerances is not traced as it is: the scene's tolerance has to be chosen for its smallest part. Making the probe independent of the tolerance is an open item of the plan (roadmap/PLAN.md, "Thin air gaps").

2Never finer than the grain

The tolerance at a point is the largest of three lengths:

• the scene's setting: one it sets itself, or else an automatic one, a ten-thousandth of the scene's size, kept between 10 nm and 1 mm;
• a nanometre, so that the tolerance is never zero, even for a setting typed smaller (the automatic one never goes under its own 10 nm);
• the floor of chapter 4: 128 × 2⁻²³ × the point's distance from the origin, which is 128 to 256 steps of an f32 number there, since below about a hundred a surface's normal is the numbers' own pattern.

The RGBW mixer, an LED optic whose size is estimated at 105 mm, gets 10.5 µm automatically (lib/pathtracer/PRECISION.md); 5 cm from the origin, where its parts are, the setting is the largest.

Two metres from the origin, the floor has passed it: 30.5 µm. One f32 step is between 2⁻²⁴ and 2⁻²³ of the number (2⁻²³ is about 1.2 × 10⁻⁷; which, depends on where the number sits between two powers of two), so 2⁻²³ × the distance is one to two steps, the floor 128 to 256, and it grows in step with the distance, and passes any setting at a distance the setting fixes: 10.5 µm / (128 × 2⁻²³) = 69 cm here. For an automatic tolerance below its cap that is always 1e-4 / (128 × 2⁻²³) = 6.55 times the scene's size (computed): far outside the scene. (One f32 step is a share of the number because a float keeps 24 binary digits, 2⁻²³ being the last of them.)

A room 10 m across gets 1 mm: a ten-thousandth would be exactly that, and it is the cap. The cap is there because a scene's size counts everything in it, a ground slab too ("Menger's is 424 m across", the code says, which would make 4 cm); so the automatic tolerance only ever makes a scene finer than the 1 mm every scene had before it, never coarser. Its floor passes 1 mm at 65.5 m. For a capped scene bigger than that, Menger's 424 m, the floor takes over inside the scene, where the numbers are coarser than 1 mm anyway.

Before 0.36.0 the engine worked in the scene's own unit, and the floor was 1e-7 of that unit: in a millimetre scene, 0.1 nm, "which is no floor at all", the code's comment says. A tolerance typed as 10 nm, used 10 m from the origin, was then about a hundred times finer than one step of the numbers there (2⁻²³ × 10 m is 1.2 µm, one to two steps): a point moved by it does not move. In the figure the old floor is flat: it did not grow with the distance, as the numbers' steps do. Today's floor keeps the tolerance where the numbers can follow.

3Metres inside, and a check that holds it

The GPU's programs, its kernels, are two kinds of code put together. The engine is ShadyTracer's own: marching rays, shading, sampling lights. The scene is code the builder writes for each scene (chapter 24): its distance function SDF, its materials, its lights, in the scene's own numbers. Since 0.36.0 the engine works in metres whatever unit a scene is written in, and the two meet only at a boundary: sceneAt hands the scene a ray with its lengths turned into the scene's unit, and turns the lengths of the answer back into metres. Two factors do it: scene units per metre on the way in (1000 for millimetres), metres per scene unit on the way out (0.001), each multiplied by, never divided by. A multiplication rounds by at most half a step, while the GPU's division may be off by 2.5 steps (its rules allow that); and in a metre scene both factors are 1, so its numbers come through unchanged. These lines of an engine kernel ask the scene only that way, and the lint that checks them says nothing.

An engine line that asked the scene directly would compile, run, and be right in every metre scene, and wrong by a thousand in a millimetre one: "the bug this repository keeps having, true for the only caller there was", the lint's own comment says. So unitlint.js reads every kernel built against every scene, in the shader check's second pass (chapter 29), and names the line. This figure runs it, on these few lines, against the real boundary.

The scene's own tolerance, marchEps, is a length in the scene's unit: read by the engine, a millimetre number taken for metres, a thousand times too large.

SCN_TOL is a variable the boundary sets for the scene while it is asked (a global: one every function can read): the engine's tolerance in the scene's unit. Read by the engine, it is again a length in the wrong unit.

A helper of the engine's that asks the scene's side is the same mistake one call away. The lint follows the calls: here farAway calls metres, and is named for it. metres(x) is the scene's helper for saying a length in metres in its own unit (it multiplies by 1000 in a millimetre scene); the engine's lengths are metres already, so from engine code it would multiply them by 1000 again.

And the unit itself, read anywhere but in the engine's few unit functions (this line also divides by it, which the boundary never does). The rule came from bugs of exactly this shape. One: light-traced photons each carry their share of the light to the camera, divided by the square of their distance to it. While the engine worked in the scene's unit, in a centimetre scene those distances were in centimetres, their squares 10,000 times what they are in metres, and nothing divided that back: "the lit spot came out 10 000 times too dark, invisible, while a metre scene was right" (optics/index.js; the arithmetic here inferred from its comment).