This document is about: FUSION 2
SWITCH TO

Render Behavior

Fusion state is simulated with a fixed time step, which generally doesn't align with render and presenting would result in jittery character movement. To achieve smooth, precise and reactive movement, the KCC supports interpolation, extrapolation and full prediction render mode.

Following explanations are described from a local player (input authority) point of view.

Render Interpolation

The position/rotation in render is calculated as linear interpolation between states in last two fixed ticks. Following image shows render positions being delayed by exactly 1 fixed time step.

Render interpolation
Position (vertical axis) in interpolated between states in last 2 fixed ticks.

Pros:

  • ✅ Easy
  • ✅ Performant
  • ✅ Less error prone

Cons:

  • ❌ Increases input lag by fixed time step (~16.67ms on 60Hz simulation)
  • ❌ Can produce visual glitches, especially in fast-paced gameplay
  • ❌ Requires storing additional data and custom algorithm for correct interpolation of edge cases

Following image shows an example of reflected movement (bump on a jump pad) which results in bad experience. The sharper the angle of reflection and higher movement velocity, the more noticeable the problem is (less horizontal distance between positions in fixed ticks results in lower velocity in renders between fixed ticks, causing a stuck effect for up to X render frames). This is easily perceivable in 60Hz simulation and higher rendering rate.

Render interpolation on jump pad
Render interpolation on jump pad.

⚠️ Render interpolation is set as default KCC render behavior.

Render Extrapolation

The position/rotation in render is calculated as linear extrapolation of states in last two fixed ticks.

Render extrapolation
Position (vertical axis) in extrapolated from states in last 2 fixed ticks.

Pros:

  • ✅ Easy
  • ✅ Performant

Cons:

  • ❌ Incorrect extrapolation results in jitter (usually when direction changes)
  • ❌ Risk of undesired state (character pushed into geometry)

Following image shows an example of reflected movement (bump on a jump pad) which results in bad experience. The character may be incorrectly pushed into a geometry for a few frames and then teleported into the right position after the next fixed update.

Render extrapolation on jump pad
Render extrapolation on jump pad.

This effect is even more perceivable when the fixed update position is closer to the impact point:

Render extrapolation on jump pad
Render extrapolation on jump pad.

⚠️ KCC uses extrapolation only for render updates with very small delta time (less than 50us). Small delta times can lead to NaN propagation in fully predicted movement calculations.

Render Prediction

The position/rotation in render is fully predicted, ahead of last fixed tick.

Render interpolation
Position (vertical axis) is predicted ahead of last fixed tick.

Pros:

  • ✅ Immediate response without additional input lag
  • ✅ Precise movement (no extrapolation)

Cons:

  • ❌ CPU cost - executing whole KCC pipeline including physics queries
  • ❌ Requires careful implementation to not introduce accumulation of partial integration error (state after 16ms fixed update must be same as the state after 4x4ms render updates) which results in perceivable jitter

Following image shows an example of reflected movement (bump on a jump pad) which results in good experience. The stuck effect takes one render frame at max which is acceptable.

Render prediction on jump pad
Render prediction on jump pad.

What to use?

Render interpolation is more performant and easier to maintain, thus it is recommended for all characters not controlled by the local player.

Use render prediction if you need:

  • ✅ Full control over character movement (e.g. past paced platformer)
  • ✅ Immediate response (lowest input lag, targeting e-sport, shooters)

Render prediction/interpolation can be changed in KCC Settings - properties Input Authority Behavior, State Authority Behavior and Proxy Behavior.

Back to top