Freeze a game. Follow one pixel.: sources & model

Drive an original little rover behind an arch, turn the camera, and open one pixel of the actual picture. Discover which triangle wins, where its color comes from, and what changes when you add more samples.

What supports the explanation?

What this model assumes

1. All park geometry, materials, dimensions, light coefficients and motion are original teaching choices. There is no commercial game footage or captured GPU telemetry.
2. Only opaque surfaces and a simple directional diffuse response are modeled. No transparent sorting, cast shadows, indirect lighting or physically calibrated display is claimed.
3. The top-left fill rule and 1/256-pixel grid are specified model choices, not a bit-for-bit promise for all graphics hardware.
4. Wireframe shows hidden as well as visible edges. The depth picture uses an explicitly contrast-expanded display; reports retain actual window depth.
5. The original checker uses nearest sampling, clamp-to-edge and no mipmaps. Fine patterns may alias. Four-sample supersampling does not eliminate every texture or silhouette artifact.
6. Disabled depth and affine mapping are deliberate broken comparisons, always labeled. Equal-depth order dependence remains possible even with correct opaque testing.
7. Candidate counts and the target frame interval are not render timing measurements. No device score or unsupported FPS claim is shown.
8. The paper grid teaches geometric sampling. It is not a model of the full eye or the physics of a camera sensor.
9. The coordinate contract: This renderer uses a right-handed camera looking along negative Z, an OpenGL-style homogeneous clip volume −w ≤ x,y,z ≤ w, and top-left image coordinates. Near and far distances are 0.5 and 35 authored scene units. Those choices are stated rather than mixed with another API’s conventions.
10. Clip first, divide second: The implementation clips all six homogeneous planes and linearly carries vertex attributes to newly created intersections. It preserves original triangle IDs and separately numbers generated pieces. Dividing a behind-camera vertex and clamping its image position would give a different, incorrect result.
11. A reproducible shared-edge rule: Image vertices are snapped to 1/256 of a pixel for this teaching rasterizer. Positive-area triangles include an edge when its vertical difference is negative, or when it is horizontal and points right. This stated top-left convention gives a shared sample to exactly one adjacent triangle.
12. Depth is not distance in meters: Window depth maps the selected perspective projection into [0,1]. It varies nonlinearly with camera distance. The buffer starts at 1 and uses strict LESS. Equal-depth candidates keep the first submission; a sample exactly on the far plane can fail against the clear depth of 1.
13. Perspective-correct attributes: For screen weights λ and clip values w, a surface attribute is Σ(λa/w) divided by Σ(λ/w). Already-projected window depth instead uses the straight weighted sum Σ(λd). Applying perspective correction to that depth again would be a mistake.
14. Why a surface normal needs special care: A normal is perpendicular to a surface. Under a nonuniform object scaling, inverse-transpose transformation preserves that relationship. Treating it like an ordinary direction can produce plausible-looking but incorrect shading. Interpolated normals are normalized before use.
15. A bounded diffuse response: Linear base color is multiplied by 0.1 + 0.9 max(0, n·l). The constants are authored dimensionless coefficients. Physical Lambertian reflection has a ρ/π BRDF; this simple ambient shortcut does not solve full environmental light transport or cast shadows.
16. Linear light and sRGB codes differ: A linear value of 0.5 encodes to about sRGB byte 188, not 128. This renderer averages linear sample colors before applying the piecewise sRGB transfer function once. The ramp’s two original colors are specified directly in linear RGB.
17. Supersampling is a specific algorithm: Four-sample mode evaluates coverage, depth and shading at quarter-offset positions. It is supersampling, not a claim to implement hardware MSAA. Four points do not exactly integrate the covered area of every possible edge.
18. Counts answer a different question from timers: The counters count work actually performed by this software renderer: input and clipped triangles, candidate tests, covered candidates, successful writes and final visible samples. None is a GPU shader-invocation count. Doubling width and height quadruples pixel count, but it does not establish a universal fourfold runtime.
19. One auditable image: The pixel report and lossless image are calculated by the same rasterizer. Optional wire edges and contrast-expanded depth are inspection overlays, and their differences are labeled. Source screenshots are separate graphics tests; their pixels are not substituted for the original scene.
20. A useful subset of rendering: Modern games may use ray tracing, physically based materials, level-of-detail systems, temporal reconstruction and many other techniques. Our opaque triangle pipeline explains a concrete mechanism without claiming that every game uses only these steps.

What has been checked

Analytical reference cases, conservation or transition invariants, finite drawing commands, bounded setup parsing, discovery and route integrity are checked automatically. These checks do not establish anatomical fidelity, learner outcomes or browser/device compatibility. Independent subject review, learner trials, comprehensive accessibility review and browser video encoding checks remain pending.

Each source supports the associated claim. Sources do not certify this implementation or its visuals.

About the cover illustration

Actual output of Brytalearn’s original opaque triangle renderer: a rover, arch and checker ramp. Authored geometry and matte lighting, not a commercial game screenshot or GPU benchmark.