A water surface has two jobs in a game. It must produce an image, and it must provide a physical answer when an object enters it. Those jobs share a description of the sea, but they cannot share an unrestricted dependency on the renderer. A headless authority still needs to know whether a vehicle is submerged when no graphics device exists.
The October water work began with an explicit comparison of the existing optical path and the missing pieces. Fresnel, absorption, refraction, filtered highlights, and authoritative buoyancy were already present. Richer wave detail, persistent foam, wakes, reflections, and an authoring playground needed further work. Treating that as a set of separate contracts was more useful than treating water as one large shader.
One sea state, different evaluations
The shared description includes physical units, a seed, authoritative time, and the parameters that determine the spectrum. The physical evaluator must return height, normal, and water velocity without a GPU readback. The visual path can spend more work on the surface because its result does not decide the authority’s next physics step.
Tessendorf’s course notes provide the spectral background: represent the surface through spatial frequencies, evolve their phases, and reconstruct a changing height field. A simplified mode has the form a cos(k·x − ωt + φ). The implementation question is which modes and sampling strategy a particular workload can afford. A bounded physical query and a camera-following GPU reconstruction need not execute identical algorithms to describe compatible motion.
This separation also limits a dangerous feedback loop. A client may render a more detailed wave field, but it does not send that local result back as a force. Buoyancy remains authority-owned. Otherwise, changing a device profile could change gameplay, or two clients could disagree about the same floating object.
Agreement is a measurable boundary
Shared parameters alone do not establish agreement. The physical evaluator and rendered displacement need comparisons at fixed world positions. Horizontal chop makes the problem less straightforward: a displaced surface coordinate is not necessarily the original query coordinate. The physical contract therefore calls for a bounded inversion and an explicit fallback when it does not converge.
Quality transitions introduce another boundary. Common frequencies should retain phase and amplitude when the visual resolution changes. Adding a fine band must not double the energy already represented in a coarse band. Camera-relative reconstruction should improve precision without moving the underlying world-space sea.
These are useful engineering checks because they expose disagreements that an attractive fly-through can hide. A screenshot shows appearance. A stationary probe comparison asks whether the renderer and physical evaluator mean the same thing by a particular position and time.
Optics begins where geometry ends
Once the surface is located, the image still depends on what the light travels through. Refraction needs valid scene depth and colour inputs. Absorption depends on path length through water. Fresnel weights reflected and transmitted contributions according to the view relationship with the surface; it cannot repair an invalid refraction sample.
The transmittance treatment in PBRT is useful background for this distinction. Attenuation belongs to a finite segment of a path, with a defined medium and distance. In a game renderer, the practical task is to maintain those boundaries through the available depth buffers, water volumes, and fallback paths. The reference explains the transport model; it does not imply that this renderer executes a path tracer.
A delivered milestone is a bounded result
The realistic-water milestone was closed on 27 October after its cumulative review. That is a dated checkpoint, rather than a promise that every later device qualification is complete. The subsequent tracker still has explicit work for Xbox Full-water execution and constrained-device cost. The later terrain and water branches also continue evolving.
The distinction matters to this journal. Research notes explain why a technique is interesting. Implementation evidence shows which path ran. A device capture documents a visible result. Performance acceptance needs its own workload, configuration, hardware, and timing evidence. Keeping those records separate makes the next water problem easier to locate.
References & further reading
Primary papers and documentation related to the techniques discussed here. Research references explain the background; the article describes implementation and validation at its dated checkpoint.
Have a thought or a question?
I'd love to hear it. ↗