The Lake That Isn't Really There
You're standing at the edge of a lake in an open-world game. The sky ripples below you. Trees sway in their mirrored doubles. A boat passes and the reflection distorts beautifully in its wake, and the whole thing feels live, continuous, real.
It isn't.
Most of what you're seeing is a snapshot, frozen fractions of a second ago, stretched and wobbled to look current. The engine is running a quiet con on you, and it's one of the more elegant tricks in real-time graphics.
So how does a game engine decide when to actually refresh a water reflection versus when to fake it? The answer involves a surprisingly human kind of laziness: only update what the player will notice.
The Cost of Honesty
A physically accurate water reflection would work like this: every frame, the engine renders the entire scene from a virtual camera placed below the water surface, mirrored on the vertical axis. That render gets projected back onto the water mesh. At 60 frames per second, that's 60 full scene renders just for the reflection.
Double your rendering workload. On complex scenes, that's a non-starter.
So every major engine, from Unreal to Unity to proprietary studio tech, uses some version of a planar reflection or a reflection capture combined with a set of update rules. The question isn't how to render the reflection. It's when.
The core mechanism is called a reflection probe (Unreal calls them Reflection Capture Actors; Unity uses Reflection Probes by name). Think of it like a disposable camera hidden inside the world: it takes a panoramic photo of its surroundings and stores it as a cubemap, a six-sided image that can be sampled from any angle. Water surfaces sample from these probes to fake what they'd reflect.
The probe can be set to update in three ways: once on level load, at a fixed interval, or every single frame. The first two are cheap. The third is where framerates go to die.
The Decision Tree Running at 60Hz
Modern engines don't just pick one mode and stick with it. They run a priority system, and water specifically gets special treatment because it covers large areas and its surface is constantly in motion.
Here's roughly how the logic works in practice.
First, the engine checks whether the water surface is even on screen. If you've turned your back to the lake, the reflection probe freezes entirely. No player, no update. This is called frustum culling applied to reflection sources, and it's one of the first budget-savers.
Next, it checks how much of the screen the water occupies. A lake filling 40% of your view gets more update budget than a puddle in the corner occupying 2%. Some engines express this as a screen-space coverage threshold: below roughly 5 to 8% of screen real estate, the probe stops updating and holds its last frame.
Then it checks whether anything significant has moved inside the reflection's field of view. This is the clever part. The engine maintains a simplified list of "reflection-relevant" objects: the sun, clouds, large dynamic characters, vehicles. Static geometry like mountains and buildings almost never changes, so the probe ignores them. If none of the tracked movers have shifted by more than a small angular threshold (often around 1 to 2 degrees from the probe's perspective), the reflection holds.
Finally, the engine applies a temporal blend. Even when it does update, it doesn't slam in a fresh render instantly. It blends the new capture with the previous one over several frames, typically 4 to 8 frames at 60fps, smoothing out the visual pop that would otherwise telegraph every update.
The result: on a calm lake with distant mountains and a static sky, the reflection might genuinely only update a few times per second. Your eye never notices because the water's normal-map animation, the ripples and caustics, masks the stillness of the underlying reflection perfectly.
Two Players, One River
Consider two players running the same river crossing in a fantasy RPG. Player A is on a high-end desktop with reflection quality set to "Epic." Player B is on a mid-range laptop set to "Medium."
Player A gets planar reflections: a dedicated render pass, updating every frame, capped at half resolution. The reflection shows other players crossing behind them in real time. Total reflection cost: roughly 4ms per frame.
Player B gets screen-space reflections layered over a static probe. SSR works by reflecting what's already on screen rather than rendering a separate pass, so it's cheap but limited. Objects outside the camera's view simply don't appear in the water. The probe underneath updates every 12 frames. Total cost: under 1ms.
Both players look at the river and think it looks fine. That's the entire goal, and honestly, achieving it this consistently is a small engineering miracle that deserves more credit than it gets.
What People Consistently Misread
The common assumption is that higher-end reflection settings mean the reflections update more often. Sometimes that's true. But the bigger visual jump isn't update frequency. It's source quality.
A planar reflection updated every 3 frames at full scene complexity will look dramatically better than a real-time SSR pass, even though the planar one is technically more "stale." SSR can only reflect what's already rendered on screen. Walk up to a reflective surface and look straight down at water near a wall, and SSR will show nothing but a smeared approximation, because the wall behind you isn't in the frame buffer. The technique is fast precisely because it's blind to half the world.
This is why some studios ship hybrid systems: SSR for small dynamic detail, cubemap probes for broad environmental color, and ray-traced reflections as a premium layer for players with the hardware budget to afford them. Each layer runs its own update cadence, then everything gets composited together in a single frame. It's less a rendering pipeline and more a confidence trick assembled from spare parts.
So if you've ever spotted a reflection that seemed a beat behind reality, a character's arm mid-swing while the water still shows the rest position, you weren't imagining it. You were seeing the update interval. The engine made a judgment call that you probably wouldn't catch it.
You caught it. Which means the threshold was set just a little too loose.
The tell isn't the stale reflection itself. It's the stillness around it. Water's normal-map animation, all those ripples and caustics, exists partly to cover for the reflection's laziness. When you spot the lag, it means the surface wasn't turbulent enough to do its job. The engine's con didn't fall apart because the reflection was old. It fell apart because nothing was moving fast enough to distract you from noticing.