A wind rose, a sailing label, and a boat controller can disagree even when all three look plausible. The problem is often duplicated coordinate assumptions.
In Sloop in Open Water, the sailing module keeps these calculations independent of Three.js. They accept numbers and return numbers or named states, making their conventions visible outside the rendering loop.
Name the direction convention#
The wind vector expresses motion toward a direction. Sailing instruments usually describe where wind comes from. The helper reverses that vector before comparing it with the boat's bow and starboard vectors.
Using an angle function over those two projections preserves which side of the boat receives the wind. A single dot product could describe alignment, but would lose the distinction between port and starboard.
Use one boundary table#
The point-of-sail calculation classifies the relative angle through one set of thresholds. The HUD and wind rose can consume the resulting classification instead of defining their own beam-reach or in-irons ranges.
This gives boundary checks a useful purpose: a value just below a threshold and a value just above it should produce the intended neighboring states. It also makes a later tuning change affect all consumers consistently.
Normalize before labeling#
The cardinal-direction helper normalizes degrees into a nonnegative full turn before rounding to an eight-direction index. A heading of minus 45 degrees and a heading of 315 degrees should therefore receive the same label.
Depth under the keel uses water depth minus draft, clamped at zero. That clamp gives the instrument a defined lower bound; it does not make the seabed model a surveyed navigation chart.
Connect the calculation to the scene last#
Pure functions make conventions and edge cases reviewable before adding waves, camera motion, or display animation. Rendering still needs runtime evaluation, but a visual glitch no longer has to be the first sign that two instruments disagree about the wind.