Forecast Physics in Fusion Shared Mode

This page accompanies the Photon Fusion Forecast Physics Explained with Volleyball: Smooth Networked Rigidbody Objects video and explains how to configure smooth, interactable networked Rigidbody objects in Fusion Shared Mode.

Use this page when players need to push, drive, collide with, or otherwise interact with physics objects from different clients.

If you want to take a deeper look at the documentation about Forecast Physics, you can do that here.

Overview

Networked physics objects can appear delayed on clients that do not control them.

Without local forecasting, a proxy may display the most recent state received from the network. Because that state represents an earlier point in time, fast-moving or interactive Rigidbody objects can feel delayed or unresponsive.

Forecast Physics addresses this by extrapolating networked physics objects into each client’s local time.

Fusion runs local physics and forecasts where the object should be now, then reconciles the result when newer network state arrives.

This video builds a small volleyball-style sample in which:

• multiple players connect through Fusion Shared Mode;
• players look toward a physics ball;
• a SphereCast detects the ball;
• the closest player requests State Authority;
• the authoritative client applies a Rigidbody impulse;
• Forecast Physics keeps the ball visually smooth across clients.

The player controller, connection flow, and spawning logic are already prepared so the tutorial can focus on networked physics interaction.

Video Timeline

Time	Section
00:00	Introduction
00:35	Initial project setup
01:10	What is Forecast Physics?
02:44	Enabling Forecast Physics
03:06	Setting up physics balls
04:27	Adding ball push behavior
06:15	Creating the player pusher
11:33	Adding bouncy physics materials
12:40	Requesting authority at runtime
16:15	Testing the final result

What Is Forecast Physics?

Forecast Physics is a Fusion feature for smoother networked Rigidbody simulation.

A networked physics object normally receives authoritative state over the network. Proxy clients can then display that state, but the received transform represents remote time rather than the client’s current local time.

Forecast Physics extrapolates the object forward.

Instead of only displaying the last received position, Fusion estimates where the object should be now based on its current physical state.

When newer network state arrives, Fusion reconciles the locally forecast result.

This makes physics objects such as balls, crates, vehicles, and movable props feel more responsive on clients that do not currently hold State Authority.

Forecasting Compared with Basic Synchronization

Fusion supports different approaches for networked physics objects.

Forecast Physics Enabled

Use Forecast Physics when an object should be:

• smooth on remote clients;
• physically interactive;
• pushed or bumped by players;
• controlled by different clients during a session;
• forecast into local client time.

Examples include:

• balls;
• crates;
• movable obstacles;
• vehicles;
• physics-based tools;
• interactive environment objects.

Forecast Physics Disabled

With Forecast Physics disabled, the object behaves more like a conventionally synchronized network object.

The authoritative client sends state and proxy clients display the received result.

Proxy Rigidbodies are generally treated as kinematic in this mode, making the setup more suitable for objects that remote clients are not expected to interact with physically.

Examples include:

• non-interactive physics decorations;
• authoritative moving props;
• background physics objects;
• objects that only one fixed authority controls.

Choosing the Physics Mode

Requirement	Recommended Mode
Players physically interact with the object	Forecast Physics
Authority can move between players	Forecast Physics
Smooth remote Rigidbody motion is important	Forecast Physics
Object is synchronized but not locally interactive	Forecast disabled
Proxy physics should remain kinematic	Forecast disabled
Object has a fixed authoritative owner	Depends on interaction requirements

Forecast Physics adds value when local simulation and interaction matter. It is not required for every synchronized object.

Required Project Setup

Forecast Physics must be enabled at two levels:

1. globally in the Network Project Config;
2. individually on each applicable NetworkTransform.

The physics object also requires:

• NetworkObject;
• NetworkTransform;
• Unity Rigidbody;
• Forecast Physics enabled on the NetworkTransform.

For smoother Unity rendering, enable Rigidbody interpolation.

Enabling Forecast Physics Globally

Open the Fusion Network Project Config and enable Forecast Physics.

This makes the feature available to the project.

The global setting does not automatically enable forecasting on every object. Each networked physics object must also enable the relevant setting on its own NetworkTransform.

Enabling Forecast Physics Per Object

Select the physics object and open its NetworkTransform.

Enable Forecast Physics for that object.

The final object setup should include:

Component	Purpose
NetworkObject	Gives the object a Fusion network identity.
NetworkTransform	Synchronizes position and rotation.
Rigidbody	Provides Unity physics simulation.
Forecast Physics	Forecasts the object into local client time.

Rigidbody Configuration

Enable interpolation on the Unity Rigidbody:

Interpolate

Rigidbody interpolation smooths visual movement between Unity physics updates.

Forecast Physics and Rigidbody interpolation solve related but different problems:

Feature	Purpose
Forecast Physics	Compensates for remote network time and forecasts physics state.
Rigidbody interpolation	Smooths rendering between local Unity physics updates.

Both contribute to the final visual result.

Physics Timing

Forecast Physics objects should run their physics logic through Unity’s physics timing.

Use:

C#

FixedUpdate()

for Rigidbody forces and related physics operations.

Avoid placing the actual Rigidbody force application in:

C#

FixedUpdateNetwork()

for this setup.

Unity physics runs during the fixed physics step, so authority checks and Rigidbody.AddForce are performed from FixedUpdate.

Sample Objective

The sample contains:

• a first-person player;
• a camera;
• several networked physics balls;
• Shared Mode connection and spawning logic;
• scripts for object detection, authority transfer, and pushing.

When the player presses E:

1. the key press is buffered;
2. the player performs a SphereCast in the camera direction;
3. the SphereCast looks for a pushable ball;
4. the ball checks whether the local client has State Authority;
5. the authoritative client applies an impulse.

Player Setup

The player contains:

Component or Reference	Purpose
PlayerPhysicsPusher	Detects push input and finds the target ball.
PushOrigin	Starting point of the SphereCast.
LookReference	Defines the camera-facing push direction.

PushOrigin can be attached near the player camera or upper body.

LookReference should normally be the first-person camera transform.

Ball Setup

Each ball contains:

Component	Purpose
NetworkObject	Fusion network identity.
NetworkTransform	Networked position and rotation.
Rigidbody	Local physics simulation.
PushablePhysicsObject	Applies the authoritative push impulse.
DistanceBasedAuthority	Requests State Authority for the closest player.

Forecast Physics is enabled on the NetworkTransform.

The NetworkObject also enables:

Allow State Authority Override

This allows another client to request State Authority at runtime.

State Authority

State Authority determines which client can write the object’s authoritative networked state.

For the ball, only the client with State Authority should apply the real Rigidbody force.

Proxy clients can run Forecast Physics for smooth representation, but they must not independently author the authoritative force.

The push script therefore checks:

C#

Object.HasStateAuthority

before applying an impulse.

Why Authority Must Move

In Shared Mode, different players may approach and interact with the same physics object.

A ball permanently owned by one distant client would make interaction awkward for nearby players.

The sample transfers State Authority according to distance:

• the closest player should control the ball;
• another player can request authority when they move closer;
• the new authority can then apply the push.

This approach is simple and works for the tutorial scenario.

Allow State Authority Override

Enable the following setting on the ball’s NetworkObject:

Allow State Authority Override

Without this setting, another client cannot take State Authority by calling:

C#

Object.RequestStateAuthority();

Use authority override only for objects whose ownership is expected to change during gameplay.

DistanceBasedAuthority

DistanceBasedAuthority is attached to the ball.

Its responsibility is only to determine whether the local player should request State Authority.

It does not apply forces.

The logic runs in:

C#

FixedUpdate()

Every client evaluates the distance comparison, including clients that do not currently own the ball.

Authority Request Flow

The authority script follows this sequence:

1. Return if the local client already has State Authority.
2. Wait for a request interval.
3. Find the player who currently has State Authority.
4. Find the local player object.
5. Measure both players’ distances from the ball.
6. Request State Authority if the local player is closer.

Limiting Authority Requests

Do not request authority every physics frame.

Use a short interval between checks to reduce unnecessary authority requests.

Conceptually:

C#

if (Time.time < _nextRequestTime)
{
    return;
}

_nextRequestTime =
    Time.time + RequestInterval;

The request interval should be responsive enough for gameplay without creating excessive request traffic or repeated authority contention.

Comparing Distances

Use squared distance when only comparing which player is closer:

C#

float localDistance =
    (localPlayer.position - transform.position)
    .sqrMagnitude;

float authorityDistance =
    (authorityPlayer.position - transform.position)
    .sqrMagnitude;

Squared distance avoids the square-root operation required by regular magnitude.

Then request authority when the local player is closer:

C#

if (localDistance < authorityDistance)
{
    Object.RequestStateAuthority();
}

Authority Contention

Distance-based ownership can create repeated transfers if two players remain at nearly the same distance.

Production implementations can reduce this with:

• a distance threshold;
• hysteresis;
• a minimum ownership duration;
• interaction locks;
• explicit grab or use states;
• authority request cooldowns;
• a deterministic priority rule.

For the volleyball sample, a simple closest-player comparison is sufficient.

PushablePhysicsObject

PushablePhysicsObject is attached to the ball.

It stores the Rigidbody reference and exposes a method such as:

C#

TryPush()

The method receives:

• push direction;
• forward impulse;
• upward impulse.

Authority Check Before Pushing

The first step in TryPush is checking State Authority:

C#

if (!Object.HasStateAuthority)
{
    return;
}

If the client is only a proxy, it must not apply the authoritative Rigidbody impulse.

This prevents multiple clients from applying conflicting physics changes.

Creating the Push Impulse

The impulse combines the camera direction with an upward lift:

C#

Vector3 impulse =
    direction * forwardImpulse +
    Vector3.up * upwardImpulse;

The forward part moves the ball where the player is looking.

The upward part gives the volleyball-style interaction additional lift.

Applying the Force

Apply the impulse through the Rigidbody:

C#

_rigidbody.AddForce(
    impulse,
    ForceMode.Impulse
);

ForceMode.Impulse applies an immediate change based on mass.

This is appropriate for a short push or hit rather than continuous acceleration.

Example Pushable Object

A simplified implementation can look like:

C#

using Fusion;
using UnityEngine;

public class PushablePhysicsObject :
    NetworkBehaviour
{
    [SerializeField]
    private Rigidbody _rigidbody;

    public void TryPush(
        Vector3 direction,
        float forwardImpulse,
        float upwardImpulse)
    {
        if (!Object.HasStateAuthority)
        {
            return;
        }

        Vector3 impulse =
            direction.normalized * forwardImpulse +
            Vector3.up * upwardImpulse;

        _rigidbody.AddForce(
            impulse,
            ForceMode.Impulse
        );
    }
}

Normalize the direction before applying configurable impulse strength.

PlayerPhysicsPusher

PlayerPhysicsPusher is attached to the player.

It handles:

• reading the push key;
• buffering the request;
• performing the SphereCast;
• finding PushablePhysicsObject;
• calling TryPush.

Buffering the Key Press

Input.GetKeyDown is true for only one rendered Unity frame.

Because the Rigidbody logic runs in FixedUpdate, the fixed physics step may not occur during that same rendered frame.

Store the request in Update:

C#

private void Update()
{
    if (Input.GetKeyDown(KeyCode.E))
    {
        _pushRequested = true;
    }
}

Consume and clear it in FixedUpdate:

C#

private void FixedUpdate()
{
    if (!_pushRequested)
    {
        return;
    }

    _pushRequested = false;

    TryPush();
}

This prevents the input from being missed between Unity frame timing and physics timing.

Push Direction

Use the camera or look reference:

C#

Vector3 direction =
    LookReference.forward;

The player pushes toward the point they are looking at.

This is more intuitive for a first-person interaction than using the player body’s forward direction if the camera can rotate independently.

SphereCast Detection

The sample uses:

C#

Runner.GetPhysicsScene().SphereCast(...)

A SphereCast is similar to a Raycast but uses a radius.

This makes target detection more forgiving because the player does not need to aim precisely at the center of the ball.

Fusion Physics Scene

Use the physics scene associated with the active Fusion runner:

C#

Runner.GetPhysicsScene()

This ensures the query is executed in the correct Unity physics scene, including projects that use Fusion scene handling or separate physics scenes.

SphereCast Parameters

Important parameters include:

Parameter	Purpose
Origin	Starting point of the cast.
Radius	Thickness of the cast.
Direction	Camera-facing cast direction.
Distance	Maximum interaction distance.
Layer mask	Optional filtering for pushable objects.

The sample exposes:

• PushRadius;
• PushDistance.

Push Radius

PushRadius controls how forgiving the detection is.

A larger radius:

• makes balls easier to target;
• can detect nearby unintended objects;
• may feel less precise.

A smaller radius:

• requires more accurate aiming;
• reduces accidental detection;
• can make the interaction harder to use.

Push Distance

PushDistance defines how far the player can reach.

Keep the distance aligned with the intended gameplay range.

A short distance works for physical contact or close volleyball interaction.

A longer distance behaves more like a remote force or interaction ray.

Processing the SphereCast Result

After a successful hit, search for the pushable component:

C#

if (hit.collider.TryGetComponent(
        out PushablePhysicsObject pushable))
{
    pushable.TryPush(
        direction,
        ForwardImpulse,
        UpwardImpulse
    );
}

Depending on the object hierarchy, the component may be located on a parent object. In that case, use a parent lookup.

Example Player Pusher

A simplified version can look like:

C#

using Fusion;
using UnityEngine;

public class PlayerPhysicsPusher :
    NetworkBehaviour
{
    public Transform PushOrigin;
    public Transform LookReference;

    public float PushRadius = 0.5f;
    public float PushDistance = 2.5f;
    public float ForwardImpulse = 8f;
    public float UpwardImpulse = 3f;

    private bool _pushRequested;

    private void Update()
    {
        if (Input.GetKeyDown(KeyCode.E))
        {
            _pushRequested = true;
        }
    }

    private void FixedUpdate()
    {
        if (!_pushRequested)
        {
            return;
        }

        _pushRequested = false;

        Vector3 direction =
            LookReference.forward;

        if (Runner.GetPhysicsScene().SphereCast(
                PushOrigin.position,
                PushRadius,
                direction,
                out RaycastHit hit,
                PushDistance))
        {
            if (hit.collider.TryGetComponent(
                    out PushablePhysicsObject pushable))
            {
                pushable.TryPush(
                    direction,
                    ForwardImpulse,
                    UpwardImpulse
                );
            }
        }
    }
}

Add a layer mask in production projects so the cast only checks relevant objects.

Visualizing the SphereCast

Use Gizmos to visualize:

• cast origin;
• cast radius;
• cast distance;
• look direction.

This helps tune detection without repeatedly guessing values.

For example:

C#

private void OnDrawGizmosSelected()
{
    if (PushOrigin == null ||
        LookReference == null)
    {
        return;
    }

    Vector3 end =
        PushOrigin.position +
        LookReference.forward * PushDistance;

    Gizmos.DrawWireSphere(
        PushOrigin.position,
        PushRadius
    );

    Gizmos.DrawWireSphere(
        end,
        PushRadius
    );

    Gizmos.DrawLine(
        PushOrigin.position,
        end
    );
}

Gizmos are editor-only and do not affect the network simulation.

Physics Materials

Unity physics materials can be used to adjust how the ball interacts with the floor, net, and other objects.

For a volleyball-like result, configure properties such as:

• bounciness;
• dynamic friction;
• static friction;
• bounce combine;
• friction combine.

Assign the material to the ball collider or relevant level colliders.

Bounciness

Increasing bounciness makes the ball retain more energy after collision.

A high-bounce material can make the sample feel more like a volleyball, but excessive values can make the ball unstable or difficult to control.

Test the result with:

• different masses;
• different impulse values;
• the level collider materials;
• multiple clients.

Authority Transfer at Runtime

When a second player moves closer to the ball, DistanceBasedAuthority requests control.

The transfer flow is:

1. Player 1 initially has State Authority.
2. Player 2 moves closer.
3. Player 2 calls RequestStateAuthority.
4. Fusion transfers authority according to Shared Mode rules.
5. Player 2 can now apply the Rigidbody push.

The authority change is not the same as queuing an interaction.

Pushes Are Not Queued

If the player presses E before receiving State Authority, TryPush returns and the force is not applied.

The push is not automatically replayed after authority arrives.

This is expected behavior in the sample.

The intended interaction flow is:

1. proximity causes authority transfer;
2. the player receives authority;
3. a later push input applies the force.

A production interaction system can provide explicit feedback when authority is not yet available.

Optional Queued Interaction

A more advanced implementation could temporarily remember the interaction request while authority is being transferred.

That design needs to define:

• how long the request remains valid;
• whether the target is still in range;
• whether the player still wants to push;
• whether another player gained authority first;
• whether replaying the input later is acceptable.

For immediate physical actions, dropping the request is often simpler and more predictable.

Testing the Sample

Test with at least two clients.

Suggested workflow:

1. Start the first client as the Shared Mode Master Client.
2. Start the second client.
3. Move Player 1 close to the ball.
4. Confirm that Player 1 has State Authority.
5. Press E and verify that Player 1 can push the ball.
6. Move Player 2 closer than Player 1.
7. Confirm that authority transfers.
8. Press E from Player 2.
9. Verify that Player 2 can now push the ball.
10. Observe the ball from both clients.

The ball should remain smooth while authority changes and physics impulses are applied.

Testing Forecast Physics

Compare the object with Forecast Physics enabled and disabled.

Check:

• proxy smoothness;
• visible network delay;
• response to collisions;
• authority-transfer behavior;
• correction behavior;
• high-latency conditions.

Use Fusion’s network simulation tools where appropriate to test realistic latency and packet conditions.

Different Ball Masses

The sample can include multiple balls with different Rigidbody masses.

Because ForceMode.Impulse is mass-dependent, heavier balls respond less to the same impulse.

This demonstrates that local physics settings still influence the forecasted result.

When testing different objects, compare:

• mass;
• drag;
• angular drag;
• interpolation;
• collision detection mode;
• physics material.

Forecast Physics and State Authority

Forecast Physics does not remove the need for authority.

These systems solve different problems:

System	Responsibility
Forecast Physics	Smoothly extrapolates physics state into local client time.
State Authority	Determines which client writes authoritative state.
Rigidbody	Calculates local Unity physics.
NetworkTransform	Synchronizes the object transform.
Authority-transfer logic	Decides which client should control the object.

All parts are required for the full interaction.

Recommended Setup Workflow

1. Enable Forecast Physics in the Network Project Config.
2. Add a NetworkObject to the physics object.
3. Add a NetworkTransform.
4. Enable Forecast Physics on the NetworkTransform.
5. Add and configure the Rigidbody.
6. Enable Rigidbody interpolation.
7. Enable State Authority override where ownership can change.
8. Add authority-transfer logic.
9. Apply forces only from the State Authority client.
10. Use Unity FixedUpdate for Rigidbody interactions.
11. Buffer rendered-frame input before consuming it in FixedUpdate.
12. Test with multiple clients and simulated latency.

Key Concepts

Concept	Description
Forecast Physics	Extrapolates networked physics objects into local client time.
Forecast disabled	Uses more conventional authoritative state synchronization for proxies.
State Authority	Client allowed to author the object’s networked state.
Allow State Authority Override	Allows other Shared Mode clients to request State Authority.
RequestStateAuthority	Requests control of a network object.
HasStateAuthority	Checks whether the local client can write authoritative state.
NetworkTransform	Synchronizes the object transform.
Rigidbody interpolation	Smooths rendering between Unity physics updates.
FixedUpdate	Unity callback used for Rigidbody physics timing.
SphereCast	Radius-based physics cast used for forgiving object detection.
Runner.GetPhysicsScene()	Retrieves the Unity physics scene used by the Fusion runner.
ForceMode.Impulse	Applies an immediate mass-dependent Rigidbody impulse.

Best Practices

Use this checklist when implementing Forecast Physics:

• Enable Forecast Physics globally and per object.
• Use Forecast Physics only for objects that benefit from local interaction.
• Add NetworkObject, NetworkTransform, and Rigidbody.
• Enable Rigidbody interpolation.
• Run Rigidbody logic in FixedUpdate.
• Apply physics forces only from the client with State Authority.
• Enable authority override only when runtime transfer is required.
• Limit how frequently clients request authority.
• Use hysteresis or cooldowns if authority changes too frequently.
• Buffer one-frame input before processing it in FixedUpdate.
• Use Runner.GetPhysicsScene() for physics queries.
• Add a layer mask to interaction casts.
• Normalize push direction before applying force.
• Use Gizmos to tune interaction range.
• Test with multiple clients and simulated network conditions.
• Validate that authority transfers before applying the interaction.

Common Pitfalls

Pitfall	Why It Is a Problem
Enabling Forecast Physics only in the project config	Each applicable NetworkTransform must also enable it.
Enabling it only on the object	The global project setting must also be active.
Applying Rigidbody force from proxy clients	Multiple clients can produce conflicting local physics results.
Forgetting Allow State Authority Override	Other clients cannot request State Authority.
Applying force in rendered-frame Update	Rigidbody interactions should use fixed physics timing.
Reading GetKeyDown only in FixedUpdate	The one-frame input can be missed.
Requesting authority every physics frame	Produces unnecessary request traffic and possible contention.
Assuming a push is queued during authority transfer	The sample discards pushes when authority is not yet available.
Using the default Unity physics scene blindly	Fusion may use a runner-specific physics scene.
Using a Raycast with very precise aiming requirements	Interaction may feel unnecessarily difficult compared with a SphereCast.
Setting the SphereCast radius too high	Unintended nearby objects may be detected.
Treating Forecast Physics as authority	Forecasting smooths state but does not determine who controls it.

Summary

Forecast Physics makes networked Rigidbody objects feel smoother and more responsive by extrapolating their physics state into each client’s local time.

The feature must be enabled globally in the Network Project Config and individually on the object’s NetworkTransform.

In the volleyball sample, the closest player requests State Authority over the ball. PlayerPhysicsPusher detects the ball with a camera-directed SphereCast, and PushablePhysicsObject applies an impulse only when the local client holds State Authority.

Forecast Physics controls smooth local representation, while State Authority controls who can author the real physics result. Together, they support responsive physics interaction across multiple Shared Mode clients.

Last updated on 16/09/2026

Back to top