package.ali3nsystems.lib-atmokinetic_assets

Camera-water state supplied by a non-Atmokinetic volume implementation. This keeps camera presentation local without requiring the fallback volume to create tiles, buoyancy, reflections, or network state.

Upstream candidate: games can bridge existing water-volume authoring into Atmokinetic camera presentation without constructing a full WaterController.

Every WaterController in the scene, cached on awake so consumers (e.g. GraphicsSettings) don't re-scan the scene.

True when the given water should render planar reflections. Static mode uses the water's own configuration and ignores GraphicsSettings; Dynamic mode follows GraphicsSettings, falling back to the water's Static configuration when no GraphicsSettings exists.

The texture size divider the given water should use. 1 = screen, 2 = screen/2, 4 = screen/4. Static mode uses the water's own value; Dynamic mode resolves the tier selected by GraphicsSettings, falling back to the water's Static value when no GraphicsSettings exists.

The reflection render rate the given water should use. Static mode uses the water's own value; Dynamic mode resolves the tier selected by GraphicsSettings, falling back to the water's Static value when no GraphicsSettings exists.

Pushes each water's resolved Planar/Cubemap choice to its own tiles and releases the reflection texture of any water that isn't rendering planar. Static-mode waters keep their own choice and are unaffected by this setting.

The scene's GraphicsSettings. There should only ever be one.

THIS IS PRIMARILY USED FOR THE MODELPHYISICS TO GENERATE WATER SIMULATIONS/RIPPLES WITHOUT COLLIDING WITH THE CHARACTER CONTROLLER'S BOX/CAPSULE COLLIDER. IT USES THE STEAMID AS AN IDENTIFIER.

Blood! a small, fixed-cap set of generic world-space color influences for water surfaces. The library owns only the rendering primitive and games decide what creates an influence (pollution, blood, oil, w/e).

If the distance between the center of the bounds and the camera goes beyond the selected value then the camera will be disabled and the cubemap will be used as fallback.

True when this water is actually rendering planar reflections right now. Planar has to be the resolved mode AND the water has to be on screen AND the camera has to be within the distance-culling range - when any of those fail there's nothing to reflect into, so the reflection is shut down and the tiles fall back to the cubemap.

How heavy the fluid is. Higher values make things float more. Water is 1000, oil is around 900, something very heavy like mercury is 13600.

Direction and speed of the water current.

How much the fluid slows down movement.

How much the fluid slows down spinning.

Moves the water surface up or down.

How tall the waves are. Set to 0 for calm water.

How fast the waves move.

Objects with any of these tags won't be affected.

Upstream candidate: Colliders with any of these tags do not generate simulated surface ripples.

Hard ceiling for active simulated ripples. The water shader loops over every active ripple per vertex and pixel, so this keeps rendering cost bounded.

Upstream candidate: replaces the fixed tint set and uploads it once. Callers own the lifetime and networking of records; the water renderer only consumes a snapshot.