Included in Oceanology Pro and Oceanology Lite.

Niagara water data interface

Read the real water surface directly inside Niagara — spawn splash, spray, foam or debris that sit on the actual animated waves without Blueprint round-trips.

Oceanology Pro ships a Niagara Data Interface, listed simply as Water, that lets a particle system read the live water surface. Add it as a user parameter, point it at a water body, and any module in the system can ask for the water plane position, the animated surface position, the surface normal, the water velocity, the depth and whether the point sits inside an exclusion volume - per particle, at whatever position that particle cares about. Effects stop being decoration painted near the water and start being driven by it.

The functions

• IsValid returns whether the interface is currently bound to a live water component, so a system can bail cleanly instead of emitting at the origin.
• GetWaterSurfaceInfo is the main call. Inputs are an ExecuteQuery switch, a query position and three flags for depth, waves and simple waves. Outputs are the water plane position and normal, the animated water surface position, the water depth, the water velocity and an in-exclusion-volume flag.
• GetWaveParamLookupTableOffset returns the bound body's water body index - the same value the water material instance receives as a scalar parameter, so an effect can line its per-body data up with the rendering.
• GetWaterDataAtPoint is the older signature, kept and soft-deprecated so existing systems keep working: world position and time in, wave height, depth, velocity, surface position and surface normal out.

Binding a water body

There are three ways to tell the interface which body to read. Set Source Actor Or Component directly, which accepts either an actor or a water component. Enable Find Water Body On Spawn and let it pick the closest body by water plane distance, iterating every water actor in the world and skipping any whose query lands in an exclusion volume. Or set it from Blueprint at runtime with Set Oceanology Water Component, passing the Niagara component, the user parameter name and the water component. Changing the body bumps an internal change id, so every running system instance re-resolves on its next tick rather than clinging to the old body.

One query path, shared with gameplay

Every function funnels into the same water body query the rest of the plugin uses, with the appropriate flags for location, normal, velocity, depth and waves. That matters more than it sounds: the spray emitter, the character's swimming component and the buoyancy path all resolve the surface through that single call, so a splash sits exactly where a swimmer's head breaks the surface, and a debris particle snapped to the surface position sits exactly where a floating crate would. There is no second copy of the wave maths in a Niagara graph to drift out of sync when you change wave systems. Ocean, lake, river and custom bodies all answer the same query.

Depth, large worlds and cost

Water depth is treated carefully. By default the interface evaluates depth once per frame at the system instance's own transform on the game thread and hands that single value to every particle, because a genuine per-particle depth query reaches into landscape proxies that stream in and out underneath it. Per-particle depth is therefore available but gated behind a console variable that is off by default and documented as unsafe. Positions travel in and out as Niagara positions and are converted through the system instance's own large-world-coordinate converter, so the interface stays correct far from the origin. When the Niagara debugger is open, the bound water component is printed on the debug HUD, which makes a mis-bound user parameter obvious immediately.

What you can build with it

• Spray and mist that spawn from the animated crest rather than a flat plane, using the surface position and normal.
• Foam, debris, lily pads and floating props snapped to the surface and tilted along its normal, riding the same waves as everything else.
• Current-driven and wake particles advected by the sampled water velocity, which follows river flow along the spline.
• Bubbles, murk and underwater dust gated on the sampled depth, fading out as the bed comes up.
• Shoreline and impact effects that respect exclusion volumes, because the query reports when a sample point is inside one.
• Systems that dodge cost by driving ExecuteQuery from a Niagara condition, so a particle that cannot see water never pays for a query.

Versus Oceanology NextGen

This is one entry on the Galidar roadmap. For what already shipped in each release, see the Changelog.