In short: We are building a water system for Unreal Engine with two promises: water that looks right because light, color and foam are physically computed, not hand-tuned per scene, and water that behaves: drop any mesh onto the surface and it floats, tips or sinks correctly with zero setup.
The standard to beat. Note what makes this real: foam born from breaking waves, haze eating the cliffs, whitecap statistics across the swell: none of it hand-placed, all of it physics. That's the bar we've set.
Why another water system?
Most game water looks great in exactly one lighting condition: the one on the store screenshot. Move the sun, switch to overcast, put the camera half under the waterline, and it falls apart.
There is a second, quieter failure that matters just as much: almost every water system treats floating objects as an afterthought. You get a boat template, a page of pontoon-rigging instructions, and the unspoken assumption that nobody will ever throw a random crate into the sea. Players throw crates into the sea constantly.
We wanted two things that don't currently coexist in one package: film-quality looks that survive any lighting, and physical behavior that requires no setup. Neither is achievable by tweaking parameters until a screenshot looks nice, because a screenshot is a single frame under a single sun, and the moment either changes, tuned-to-taste water shows its seams. So the foundation of the project is not a feature list. It is an acceptance test that a human cannot argue with: a photograph.
Judged against photographs, not against taste
Development is gated by reference photographs with fixed camera and lighting contracts: physical light units, a locked tonemapper, and a perceptual difference metric deciding pass or fail, not an art-director's mood on the day.
Two references are canonical, and they were chosen to be opposites:
- A clear lake, camera in the waterline. Half air, half water, a wavy boundary with no artifact band; green coastal-type water whose color deepens with distance; caustics on the rocks that match the surface above them; submerged logs bending correctly at the interface. This one tests refraction, the waterline crossing, and underwater color absorption all at once.
- A storm coast under full overcast. No sun, no glitter band: the sea must read through soft sky reflection, desaturated gray-green, whitecap statistics and haze over the cliffs. A buoy rides the swell with a believable period and tilt; the behavior is part of the acceptance, not just the still image.
The overcast reference is deliberately one of the two. Sunlit water flatters every renderer on Earth: the specular glitter hides a multitude of sins. Take the sun away and the water has to carry the frame on reflection roughness, color and motion alone. That is the honest test, and it is the one most systems quietly avoid. An ocean that only looks good in sunshine does not ship.
The camera side is specified as strictly as the water side, because a photo comparison is only fair when the camera can't cheat. That means real physical light intensities (a midday sun around 100,000 lux, not an arbitrary brightness slider), a fixed exposure, and a fixed tonemapping and bloom configuration per reference. Change the tonemapper and any water can be made to match any photo, which is exactly why the tonemapper is nailed down first.
Drop-a-Mesh: floating without the homework
Drag any mesh onto a Numivo water body and it behaves correctly immediately. The system builds a physics proxy automatically, computes displaced volume per frame from the actual wave height, and derives float-or-sink from real density.
Underwater is a place, not a post-process. Color absorbs with depth, light filters down in shafts, and the interface overhead has to cross cleanly. The lake reference exists to keep all three honest at once.
A log floats and rolls onto its long side. A crate bobs. A stone statue sinks. No rigging, no pontoon placement, no scripts. Under the hood:
- the collision shape is voxelized automatically, asynchronously, and cached per asset so it only happens once, to measure the object's real volume;
- buoyancy is computed physically each frame from displaced volume against the water's density, and fresh water and salt water genuinely differ (salt water is denser, so the same crate rides higher in the sea than in a lake);
- float-or-sink comes from density, mass divided by proxy volume: there is no "should this float?" checkbox as the default, because the default is the physics;
- stability emerges from how the proxy's volume is distributed: top-heavy crates capsize, keel-weighted hulls right themselves, a plank lies flat;
- floating objects couple back into the surface: ripples, wakes, a foam ring at the waterline, and splash effects on impact.
There is a small panel on the actor for overrides, force float, force sink, a damping slider, wake and splash toggles, but an override scales the physics rather than replacing it. Force-float a boulder and it still bobs with the right period and leaves the right wake; it just behaves as if it were lighter. That distinction matters: forced results that ignore the solver look like props glued to a plane, and players notice instantly.
The design goal is blunt, and it is a demo we want to be able to run live: someone drags twenty random props onto the sea, and everything just behaves, without opening a single settings window first. If that demo needs a tutorial, the feature failed.
What it covers
Near water, open ocean, underwater and cave pools are all first-class: spectrum-based waves with separate swell and cross-sea, foam from actually breaking waves, caustics driving underwater light shafts, and stability under cinematic effects.
Specifics that matter if you care about water:
- Waves come from oceanographic spectra (the same statistical models used to describe real seas), with directional spreading and independently controllable swell. A sea state becomes a weather decision, "building storm, long swell from the west," rather than thirty disconnected sliders you nudge until it looks stormy.
- Foam is not a painted mask. It originates where waves actually break, ages over time, and streaks under wind. Painted foam is the single most common tell of fake water, because it doesn't move with the physics it's supposed to represent.
- Underwater is a real place. Correct color absorption by depth (red goes first, then green, leaving the deep blue everyone knows from dive footage), light shafts derived from the same caustic field that lights the bottom, and a crossing at the waterline without the classic hard artifact band.
- Cave pools get their own treatment: still or barely-moving water, dripping disturbances, reflections in near-darkness, because a calm interior pool exposes different failures than open ocean.
- Cinematics are acceptance criteria, not an afterthought. The surface must stay stable under depth of field, motion blur and film grain: no specular fireflies that only appear once grain is applied, no shimmer that a slow camera turns into strobing.
Why buoyancy is the part everyone skips
Looks can be faked with a good shader, but behavior can't. Convincing float-and-sink needs a real-time volume estimate and a stable solver, which is genuinely hard, so most systems ship a boat prefab and stop.
The uncomfortable engineering truth is that a beautiful water shader is a solved problem and a general buoyancy solver is not. Faking the look of a wave is a texture-and-normal problem; making an arbitrary, never-seen-before mesh sit in that wave correctly is a physics problem that has to run at frame rate, survive fast time steps, and not explode when a thousand-triangle rock meets a storm swell. That gap is why "water" in most engines means "a pretty plane you can't interact with," and why the interactive part, when it exists, is a hand-authored boat.
Closing that gap, making behavior as automatic as looks, is the reason this project exists and the reason it takes reference-photo discipline plus a real solver rather than a weekend of shader work.
When can you use it?
It's in development as an Unreal Engine extension, with a staged rollout: a kinematic floating preview lands before the full physics solver, so scenes can be populated early. We are not announcing a date; the reference images decide when it's done.
The staging is deliberate. A kinematic preview (objects follow the wave surface without full force simulation) arrives first, so artists can drop meshes and populate a sea while the heavy solver is still being hardened: you feel the result long before the physics is final. The full solver, auto-proxy and complete panel follow. Progress and milestones appear on the public roadmap, not in a launch-day surprise.
The toolkit it will ship alongside, scatter, mesh blending, grids, measuring, is free to try today. If you want to be notified the moment a public water build exists, the Discord linked from the site is where it will be announced first, and where the reference-image pass/fail comparisons will be posted as they happen.
Mini-FAQ
Will it require Numivo's other tools? No, it's an extension in the same family, designed to stand alone. It shares the same principle, though: results bake to engine-native data wherever physically possible, so you own what you make.
Which engine versions? Current Unreal Engine 5 releases. Specifics land on the roadmap as the extension approaches a public build, rather than being promised now and revised later.
How is this different from the engine's built-in water? Built-in water systems are strong at the look and weak at general interaction: buoyancy is typically a separate, hand-tuned component. The whole point here is that looks and behavior come from one physically grounded system, with the reference-photo gate keeping the look honest across lighting.
Why announce before release? Because the reference-photograph method is itself the point. We'd rather show the bar publicly and be measured against it than reveal a finished thing nobody could scrutinize. This post is that bar, in writing. Hold us to it.
