Skip to content

Physics quality modes

The BuoyancyComponent exposes a PhysicsQuality enum with three values: Async, Mixed, and Runtime. They trade smoothness, latency, and responsiveness against each other. This page is the decision guide.

ModeLatencySmoothnessBest for
Async1 frame behindHighestNetworked play, large vessels, most production cases
MixedMostly currentMidSingle-player with high responsiveness needs
RuntimeCurrentLowestPlayer-character buoyancy, gameplay reads

Buoyancy is sampled non-blocking from the GPU. The result lands one frame after the sample is queued, which means the physics tick uses heights that are very slightly stale. In return: zero main-thread stall and consistent CPU cost regardless of how many buoyant actors you have.

Pick Async when:

  • You’re shipping multiplayer or expect to.
  • You have large numbers of buoyant actors (10+).
  • You’re on a content-driven schedule and just want it to work: this is the recommended default.

The one-frame latency is invisible at typical wave speeds and never desyncs replicated state.

A blend: the buoyancy tick uses a same-frame estimate where possible, falling back to async sampling otherwise. Smoother than Runtime but spikier than Async: good when you specifically want a single hero vessel to feel ultra-responsive without paying for it everywhere.

Pick Mixed when:

  • You have a small number of player-driven vessels (1–4).
  • The single-player feel matters more than worst-case CPU consistency.

The buoyancy tick samples heights synchronously each frame. Fully current, but the cost lives on the main thread.

Pick Runtime when:

  • A player character needs swim-state to be exactly current (e.g. for a tight underwater traversal).
  • You have very few buoyant actors and want zero perceptible latency.

PhysicsQuality is editable on the BuoyancyComponent and can be changed in Blueprint, but in practice, set it on the actor and leave it. Mid-gameplay swaps cause one tick of jumpiness as the sampling pipeline re-warms.