Float on the campus water #116

New issue

Open

opened 2026-10-20 23:40:47 +00:00 by sermuns · 0 comments

sermuns commented

2026-10-20 23:40:47 +00:00

Owner

The campus water is a flat blue polygon. The ponds and the golf hazards bake as
AREA_WATER and draw through the decal pipeline, and the water issue asks for
a surface: a fresnel into the sky, a scrolling wobble, a sun highlight. That
is the look of water.

This is the other half of it: water you can be in. Buoyancy is a physics
engine's easiest trick — an upward force proportional to how deep a body is —
and it turns the ponds from scenery into a place.

What it buys

Swimming. A player in the water swims instead of walking, and the walk
speed drops to a stroke. The campus has ponds; some of them are shallow
enough to wade in.
Floating things. A thrown ball that lands in the pond floats instead of
sinking and bobbing out of sight. This is the cheapest possible payoff: the
thrown-body work already has a body with a density, and density against
water is the whole of buoyancy.
A boat. A canoe on the pond, floating with a bob that follows the wind.
This is the one that needs a whole new mesh, so it is the optional end of
the range.

How buoyancy works here

Rapier does not have a buoyancy primitive, so it is a force applied to a body
each step: the submerged fraction of the body's volume, times the density
difference, times gravity, applied at the centre of buoyancy. For a sphere or
a capsule — which is what a player is — the submerged fraction is a closed
form, so the whole thing is arithmetic rather than a simulation. That is the
same shape as the rest of liuverse-world: pure maths over a baked world,
testable without a GPU.

The player is a capsule today and stays one. A swimming player is the same
capsule with a smaller effective gravity and a different movement mode — the
MoveInput already has an up axis, so a swim is up plus the walk axes,
with the ground replaced by the water surface.

Where the water surface comes from

The bake knows where the water is — AREA_WATER is already its own bucket —
but it does not know the water level. A pond is a polygon with a surface
height, and the bake has the terrain under it, so the level is the terrain
height at the pond, flattened. The collision layer the physics engine needs
carries it: a height field per pond, or a plane.

That also means the ponds are not infinitely deep, and the bottom is the
terrain the bake already grades. A player can walk out of a shallow pond.

Related

#110 the physics engine itself is the blocker.
#91 the water surface is the rendering half of the same feature; the two are
separate issues because one is a shader and this one is a simulation.
#112 the thrown bodies float, which is the cheapest part of this.

The campus water is a flat blue polygon. The ponds and the golf hazards bake as `AREA_WATER` and draw through the decal pipeline, and the water issue asks for a surface: a fresnel into the sky, a scrolling wobble, a sun highlight. That is the look of water. This is the other half of it: water you can be *in*. Buoyancy is a physics engine's easiest trick — an upward force proportional to how deep a body is — and it turns the ponds from scenery into a place. **What it buys** - **Swimming.** A player in the water swims instead of walking, and the walk speed drops to a stroke. The campus has ponds; some of them are shallow enough to wade in. - **Floating things.** A thrown ball that lands in the pond floats instead of sinking and bobbing out of sight. This is the cheapest possible payoff: the thrown-body work already has a body with a density, and density against water is the whole of buoyancy. - **A boat.** A canoe on the pond, floating with a bob that follows the wind. This is the one that needs a whole new mesh, so it is the optional end of the range. **How buoyancy works here** Rapier does not have a buoyancy primitive, so it is a force applied to a body each step: the submerged fraction of the body's volume, times the density difference, times gravity, applied at the centre of buoyancy. For a sphere or a capsule — which is what a player is — the submerged fraction is a closed form, so the whole thing is arithmetic rather than a simulation. That is the same shape as the rest of `liuverse-world`: pure maths over a baked world, testable without a GPU. The player is a capsule today and stays one. A swimming player is the same capsule with a smaller effective gravity and a different movement mode — the `MoveInput` already has an `up` axis, so a swim is `up` plus the walk axes, with the ground replaced by the water surface. **Where the water surface comes from** The bake knows where the water is — `AREA_WATER` is already its own bucket — but it does not know the water *level*. A pond is a polygon with a surface height, and the bake has the terrain under it, so the level is the terrain height at the pond, flattened. The collision layer the physics engine needs carries it: a height field per pond, or a plane. That also means the ponds are not infinitely deep, and the bottom is the terrain the bake already grades. A player can walk out of a shallow pond. **Related** - #110 the physics engine itself is the blocker. - #91 the water surface is the rendering half of the same feature; the two are separate issues because one is a shader and this one is a simulation. - #112 the thrown bodies float, which is the cheapest part of this.

sermuns added this to the Play milestone

2026-10-20 23:40:47 +00:00

sermuns added the

medium

feature request

labels

2026-10-20 23:40:47 +00:00

sermuns referenced this issue

2026-10-20 23:41:18 +00:00

Add a physics engine (rapier3d) #110

sermuns added the

blocked