Prediction Culling: Optimizing Predict/Rollback Performance

This page accompanies the Photon Quantum Prediction Culling Explained: Optimize Predict/Rollback Performance video and explains how to reduce the cost of predicted simulation by skipping entities that are not currently relevant to the local player.

Use this page when a project contains many entities, expensive physics, navigation, AI, or gameplay systems that do not need to be predicted while they are outside the player’s visible or relevant area.

Overview

Quantum is a deterministic predict/rollback engine.

To keep local gameplay responsive, Quantum predicts the simulation ahead of the latest verified frame. When verified input arrives, the simulation rolls back to the verified state and re-simulates forward.

Prediction Culling reduces the amount of work performed during these predicted frames.

Entities outside the configured prediction area can be skipped during prediction and simulated only when verified frames are processed.

This can reduce CPU cost when:

• the world contains many entities;
• large parts of the map are outside the player’s view;
• distant entities use expensive gameplay logic;
• physics or navigation workload is spatially distributed;
• only nearby interactions need immediate prediction.

Prediction Culling does not guarantee a performance improvement for every project. Its effectiveness depends on entity count, simulation complexity, prediction distance, player visibility, and how much work can actually be skipped.

This video covers:

• how Quantum prediction and rollback work;
• why predicted simulation can become expensive;
• when Prediction Culling is useful;
• how to configure a local prediction area;
• how built-in Quantum systems use culling;
• how custom filter systems participate automatically;
• how Prediction Culling interacts with deterministic RNG;
• which iteration APIs do not use culling automatically;
• how to implement custom culling logic.

Video Timeline

Time	Section
00:00	Introduction
00:45	Prediction in action
01:18	Prediction Culling in Stumble Guys
02:36	Prediction Culling golden rule
03:06	CullingSystem3D
03:33	Creating the prediction culling sphere
05:07	Prediction Culling in action
06:28	RNG prediction issues
07:08	Advanced culling tips

Predict/Rollback Simulation

Quantum predicts gameplay ahead of the latest verified frame.

This allows local input to affect gameplay immediately instead of waiting for a network round trip.

A simplified flow is:

1. The local client collects input.
2. Quantum predicts future frames.
3. Verified input arrives from the network.
4. Quantum rolls back to the latest verified frame.
5. The simulation re-runs from that frame to the current predicted state.

Quantum performs this rollback and re-simulation as part of its normal prediction model.

This provides consistent simulation behavior and makes performance easier to profile than a system where rollback occurs only after detected input differences.

Why Prediction Can Be Expensive

A simulation frame may run more than once.

For example, a frame can be:

• simulated during prediction;
• discarded during rollback;
• simulated again using verified input.

If a project contains many expensive entities, the cost of repeatedly simulating all of them can become significant.

Potentially expensive workloads include:

• dynamic physics bodies;
• navigation agents;
• AI decision-making;
• environmental systems;
• obstacle logic;
• projectile simulation;
• large crowds;
• complex entity queries.

The cost becomes especially noticeable in large maps where the local player can only see or interact with a small section of the world.

Example: Large Obstacle-Course Game

Consider a large multiplayer obstacle-course game containing:

• dozens of players;
• spinning platforms;
• swinging hammers;
• falling tiles;
• hundreds of physics objects;
• multiple areas of the map.

The local player only sees a limited part of the course.

Predicting interactions on the opposite side of the level may provide no visible benefit to that player, while still consuming CPU time.

Prediction Culling allows Quantum to focus predicted simulation on nearby or otherwise relevant entities.

How Prediction Culling Works

Prediction Culling separates simulation behavior by frame type.

Frame Type	Entity Simulation
Predicted frame	Cullable entities outside the active prediction area can be skipped.
Verified frame	All required entities are simulated to maintain the correct authoritative state.

A culled entity is not removed from the game.

Its predicted logic is temporarily skipped until:

• a verified frame is simulated;
• it enters the prediction area;
• custom culling logic marks it as relevant.

Default Radius-Based Culling

Quantum includes radius-based prediction culling.

The game provides:

• a prediction-area center;
• a prediction radius.

During predicted frames, entities inside that area remain active for prediction.

Entities outside the area can be skipped if they are compatible with culling.

Other spatial approaches, such as camera-frustum-based logic, can be implemented when a sphere does not match the project’s requirements.

The Golden Rule

Players should not normally see culled entities.

Because culled entities do not run their regular logic during predicted frames, their visible movement or behavior may update only when verified frames are processed.

This can cause:

• visible jitter;
• delayed movement;
• snapping;
• animation discontinuity;
• corrections when the entity becomes predicted again.

Set the prediction area large enough to cover:

• the complete visible camera area;
• entities about to enter the screen;
• nearby interactions;
• fast-moving objects;
• gameplay systems that can affect the player soon.

A practical prediction radius should usually extend beyond the current viewport.

Prediction Radius Trade-Off

The prediction radius affects both visual quality and performance.

Radius	Effect
Too small	More entities are skipped, but visible jitter or late prediction can occur.
Too large	Fewer entities are skipped, reducing the performance benefit.
Appropriate	Off-screen work is reduced while visible gameplay remains fully predicted.

Tune the radius using:

• profiler measurements;
• maximum camera distance;
• object speed;
• interaction range;
• level layout;
• target hardware.

Built-In Culling Systems

Quantum’s Prediction Culling systems are commonly available in the project’s Systems Config.

To inspect them:

1. Search for SystemsConfig in the Unity Project window.
2. Open the Systems Config used by the simulation.
3. Locate the culling systems.

Built-in systems such as physics and navigation can participate in Prediction Culling.

The exact configuration depends on whether the project uses:

• 3D simulation;
• 2D simulation;
• custom culling behavior.

Custom Gameplay Systems

Custom filter systems can participate in Prediction Culling automatically.

A filter that includes a spatial transform component can be culled according to the active prediction area.

Supported spatial components include:

• Transform3D;
• Transform2D.

During verified frames, all matching entities continue to be processed.

During predicted frames, the filter can return only relevant entities inside the prediction area.

Creating the Prediction Area Updater

Quantum needs to know where the local player’s relevant prediction area is located.

This information commonly comes from the local player entity or camera.

Create an Entity View Component:

Create > Quantum > Entity View Component

Name it:

LocalPredictionAreaUpdater

Example:

c#

using Photon.Deterministic;
using Quantum;
using UnityEngine;

public class LocalPredictionAreaUpdater :
    QuantumEntityViewComponent
{
    [Header("Culling Settings")]
    [Tooltip("The radius around this entity to predict.")]
    public FP Radius = 20;

    public override void OnActivate(Frame frame)
    {
        var playerLink =
            frame.Get<PlayerLink>(EntityRef);

        if (!Game.PlayerIsLocal(playerLink.Ref))
        {
            Destroy(this);
        }
    }

    public override void OnUpdateView()
    {
        FPVector3 center =
            PredictedFrame
                .Get<Transform3D>(EntityRef)
                .Position;

        Game.SetPredictionArea(center, Radius);
    }
}

The exact PlayerLink field name may differ depending on the project’s component definition.

Prediction Radius Type

The radius uses Quantum’s deterministic fixed-point type:

c#

public FP Radius = 20;

Although this component runs in Unity view code, Game.SetPredictionArea expects Quantum-compatible deterministic values.

Using FP avoids repeated conversion and makes the intended API type explicit.

Local Player Check

The prediction area should follow the local player.

Inside OnActivate, retrieve the entity’s PlayerLink and check whether that player is local:

c#

if (!Game.PlayerIsLocal(playerLink.Ref))
{
    Destroy(this);
}

This prevents remote player views from creating additional local prediction areas.

Only the locally controlled entity should update the local client’s prediction area.

Updating the Prediction Area

Inside OnUpdateView, retrieve the local entity’s deterministic position from the predicted frame:

c#

FPVector3 center =
    PredictedFrame
        .Get<Transform3D>(EntityRef)
        .Position;

Then update the prediction area:

c#

Game.SetPredictionArea(center, Radius);

This informs Quantum which region should remain active during predicted frames.

Why Use the Predicted Frame Position?

The prediction area follows the predicted position of the local player.

This keeps the culling area aligned with the player’s immediately responsive local state rather than a delayed verified position.

Using the verified position could make the prediction area lag behind a fast-moving local entity.

Attaching the Updater

Attach LocalPredictionAreaUpdater to the player’s Entity View prefab.

The component is created on every player view, but removes itself from non-local players during activation.

Every Unity view update, the local instance updates the prediction area.

Camera-Centered Prediction Areas

The prediction area does not have to be centered on the player.

Some games may achieve better results by centering it on:

• the camera;
• a point ahead of the player;
• the center of the visible gameplay area;
• a strategic focus point;
• a spectator target.

For example, a fast-moving game can offset the center in the movement direction so that upcoming entities enter prediction earlier.

The center still needs to be converted into deterministic Quantum coordinates before being passed to the simulation.

Spinning Obstacle Component

To demonstrate culling in a custom system, define a component:

c#

component SpinningObstacle
{
}

The component identifies entities that should rotate continuously.

Creating a Cullable Custom System

Create a filter system:

c#

namespace Quantum
{
    public unsafe class ObstacleRotationSystem :
        SystemMainThreadFilter<
            ObstacleRotationSystem.Filter>
    {
        public struct Filter
        {
            public EntityRef Entity;
            public Transform3D* Transform;
            public SpinningObstacle*
                ObstacleComponent;
        }

        public override void Update(
            Frame frame,
            ref Filter filter)
        {
            filter.Transform->Rotation *=
                FPQuaternion.Euler(
                    0,
                    frame.DeltaTime * 50,
                    0
                );
        }
    }
}

The system rotates every matching obstacle during normal processing.

Automatic Culling Through Filters

The filter includes:

c#

public Transform3D* Transform;

This allows Quantum to apply spatial Prediction Culling to the system automatically.

During a predicted frame:

• obstacles inside the prediction area are returned by the filter;
• cullable obstacles outside the area can be skipped.

During a verified frame:

• all required obstacles are processed;
• the complete deterministic state remains correct.

No manual distance check is required inside the system.

Avoid Manual Distance Checks When Possible

Without built-in culling, a system might manually compare every entity position with the local player.

That approach still requires iterating through all entities before rejecting distant ones.

Prediction-aware filters can avoid processing culled entities entirely during predicted frames.

This can reduce:

• component access;
• system update calls;
• gameplay calculations;
• physics or navigation workload;
• repeated distance calculations.

Systems Without Transform Components

A filter must include an appropriate transform component for automatic spatial culling.

A system that only filters:

• inventory data;
• global state;
• timers;
• non-spatial singleton components;

does not automatically become spatially cullable.

If a system controls a spatial entity, include the relevant transform in the filter when appropriate.

Do not add transforms only to force culling if skipping the system would make its state incorrect.

Verified-Frame Behavior

Culling affects predicted execution, not the final verified simulation result.

On verified frames, culled entities are processed so their authoritative state remains correct.

This is why Prediction Culling can improve prediction performance without permanently pausing distant gameplay.

However, systems should still be designed so that skipping predicted updates does not cause unacceptable visual artifacts.

Prediction Culling and Physics

Quantum’s built-in physics integration can benefit from Prediction Culling.

Distant cullable physics entities may avoid predicted processing while remaining correctly simulated on verified frames.

The performance benefit depends on:

• number of bodies;
• collision density;
• sleeping behavior;
• culling radius;
• dynamic interactions;
• target platform.

Physics Sleeping and Prediction Culling address different cases.

Optimization	Purpose
Physics Sleeping	Stops inactive physics bodies from being processed unnecessarily.
Prediction Culling	Skips distant cullable entities during predicted frames.

They can be used together.

Prediction Culling and Navigation

Navigation systems can also benefit from culling when agents outside the prediction area do not require predicted updates.

This can reduce the predicted cost of:

• path following;
• avoidance;
• steering;
• local navigation logic.

Verified frames continue to maintain the correct world state.

Prediction Culling and RNG

Prediction Culling can affect the order in which a shared RNG stream is advanced during predicted frames.

Consider an entity that normally calls:

c#

frame.RNG->Next(...)

If the entity is culled during prediction, that call does not occur.

Another entity using the same global RNG can then receive a different value during the predicted frame.

When the verified frame runs all entities, the global sequence is advanced differently and the prediction is corrected.

This can cause visible behavior changes after rollback.

Examples include:

• selecting a different attack;
• changing movement direction;
• choosing another target;
• producing a different procedural action.

Component-Based RNG for Cullable Entities

Give independent entities their own component-based RNGSession when their random behavior can be skipped by Prediction Culling.

Example:

c#

component EntityRandom
{
    RNGSession RNG;
}

Each entity advances its own random stream.

When that entity is culled:

• its local RNG is not advanced;
• unrelated entities are not affected;
• its RNG state rolls back with the component;
• the global RNG sequence is not shifted by its skipped call.

Use the global RNG to initialize local seeds, then use the local sessions for ongoing entity-specific behavior.

RNG Isolation Benefits

Component-based RNG reduces coupling between:

• different AI agents;
• cullable entities;
• procedural obstacles;
• environmental objects;
• independently scheduled systems.

It does not eliminate the need for deterministic call order inside each entity’s own logic.

Iterators and Prediction Culling

Filter systems can participate in Prediction Culling automatically.

Generic component iteration does not necessarily receive the same automatic behavior.

For example:

c#

frame.GetComponentIterator<T>()

does not automatically apply prediction-area filtering.

A system using this iterator may continue processing every matching component, including distant entities.

For cullable spatial logic, prefer a filter that includes:

• Transform3D; or
• Transform2D.

Choosing an Iteration API

Iteration Method	Automatic Spatial Prediction Culling
Filter with Transform3D	Yes, when configured for culling.
Filter with Transform2D	Yes, when configured for culling.
Generic component iterator	No automatic spatial culling.
Singleton access	Not spatially culled.
Manual entity lookup	Depends on custom logic.

Use the API that matches the system’s correctness and performance requirements.

Custom Prediction Logic

A spherical prediction area may not fit every game.

Alternative logic can include:

• camera-frustum culling;
• room-based culling;
• grid-cell relevance;
• floor or zone relevance;
• team-based relevance;
• portal visibility;
• explicit gameplay priority.

Quantum exposes manual culling controls for advanced scenarios.

Relevant APIs can include:

c#

frame.SetCullable(...)

and:

c#

frame.Cull(...)

The exact signatures and intended execution context depend on the Quantum version.

Use the current Quantum documentation when implementing manual culling.

Camera-Frustum Culling

A camera-frustum approach predicts entities that are:

• visible;
• close to becoming visible;
• inside an expanded camera volume.

This can be more selective than a sphere in:

• top-down games;
• corridor-based games;
• strategy games;
• games with long narrow camera views.

Include a safety margin around the camera frustum so fast-moving entities become predicted before entering the visible area.

Gameplay Relevance Beyond Visibility

Visibility is not the only reason an entity may need prediction.

An off-screen entity may still affect the local player through:

• projectiles;
• explosions;
• long-range attacks;
• shared physics constraints;
• global triggers;
• networked abilities;
• chained gameplay logic.

The prediction area must account for interaction range, not just camera visibility.

Measuring the Performance Benefit

Prediction Culling should be evaluated with profiling data.

Compare:

• simulation time with culling disabled;
• simulation time with culling enabled;
• number of entities inside the prediction area;
• predicted-frame workload;
• verified-frame workload;
• visible correction artifacts;
• target-platform frame time.

Use a Quantum Release build and representative gameplay conditions.

Prediction Culling is useful only if the skipped work outweighs its management cost and does not degrade the player experience.

When Prediction Culling Helps

Prediction Culling is more likely to help when:

• many entities are outside the local player’s area;
• distant entities contain expensive systems;
• the map is large;
• players are distributed across separate areas;
• physics or navigation workloads are heavy;
• the camera shows only a limited part of the simulation;
• target hardware has a constrained CPU budget.

When Prediction Culling May Not Help

The benefit can be limited when:

• almost all entities remain inside the prediction area;
• the game has only a small number of entities;
• most simulation cost comes from global systems;
• entity logic is inexpensive;
• the map is compact;
• players interact across the whole world;
• the required radius is almost as large as the level;
• verified-frame cost is already the primary bottleneck.

Do not enable or enlarge the implementation solely because it is available. Measure the result.

Recommended Setup Workflow

1. Confirm that the culling systems are enabled.
2. Identify the locally controlled entity.
3. Create an Entity View Component that updates the prediction area.
4. Use a radius that exceeds the visible gameplay region.
5. Attach the updater to the player view prefab.
6. Verify that only the local player updates the area.
7. Use filters with Transform3D or Transform2D in cullable systems.
8. Inspect custom iterators that may bypass culling.
9. Isolate entity-specific RNG streams.
10. Profile before and after enabling culling.
11. Test rollback and visual corrections under real network conditions.
12. Adjust the radius based on performance and visibility.

Key Concepts

Concept	Description
Predicted frame	Simulation frame calculated ahead of verified network input.
Verified frame	Simulation frame confirmed using authoritative input data.
Rollback	Restoring a verified state before re-simulating forward.
Prediction Culling	Skipping selected distant entities during predicted frames.
Prediction area	Spatial region whose entities remain active during prediction.
Culling radius	Radius of the default spherical prediction area.
Game.SetPredictionArea	Updates the local prediction center and radius.
QuantumEntityViewComponent	Unity-side component used to connect Entity Views with Quantum view logic.
Cullable filter	Filter containing a transform that can use spatial prediction culling.
Component iterator	Generic iteration API that does not automatically apply prediction culling.
Component RNG	Entity-specific random stream stored in rollback-compatible state.
frame.SetCullable	Manual control for whether an entity can be culled.
frame.Cull	Manual culling control for advanced prediction logic.

Best Practices

Use this checklist when implementing Prediction Culling:

• Measure performance before and after enabling culling.
• Use a Quantum Release build for profiling.
• Keep the prediction radius larger than the visible camera area.
• Include fast-moving and soon-to-be-visible entities.
• Update the prediction area from the local player or camera.
• Ensure remote player views do not update the local prediction area.
• Use the predicted local position as the prediction center.
• Use filters containing Transform3D or Transform2D.
• Avoid generic iterators for systems expected to benefit from culling.
• Use component-based RNG for independently cullable entities.
• Keep global systems outside culling when they must always run.
• Account for off-screen interactions and long-range effects.
• Test under latency and rollback conditions.
• Use manual culling APIs only when the default radius is insufficient.
• Profile target hardware rather than relying only on the Unity Editor.

Common Pitfalls

Pitfall	Why It Is a Problem
Assuming culling always improves performance	Small or globally active simulations may see little benefit.
Using a radius smaller than the visible area	Players may see jittering or snapping entities.
Updating the prediction area for every player view	Multiple remote views can overwrite the local prediction area.
Using the verified position for a fast local player	The prediction area may lag behind responsive local movement.
Expecting generic component iterators to be culled	They do not automatically use spatial Prediction Culling.
Omitting the transform from a filter	Quantum cannot apply spatial culling through that filter.
Using the global RNG for cullable entity behavior	Skipped predicted calls can shift the shared RNG sequence.
Culling an entity that affects the local player from off-screen	Important interactions may not be predicted correctly.
Testing only without latency	Rollback-related jitter may not be visible in local testing.
Optimizing verified-frame bottlenecks with Prediction Culling	Culling primarily reduces predicted-frame work.
Using manual culling without preserving correctness	Required entities may be skipped during prediction.

Related Links

• Photon
• Photon Quantum
• Quantum Documentation
• Photon Dashboard
• Photon Samples

Summary

Prediction Culling reduces predicted simulation work by skipping cullable entities outside the local player’s relevant area.

Verified frames continue to process the complete required simulation, while predicted frames focus on nearby or otherwise important entities.

Built-in Quantum systems and custom filter systems containing Transform3D or Transform2D can benefit from culling automatically. Generic component iterators do not receive the same automatic optimization.

The prediction area should remain larger than the visible and interactive region so players do not see entities that are only updating on verified frames.

Prediction Culling is most effective in large, spatially distributed simulations with expensive off-screen entities. Its actual value must be confirmed through profiling under representative gameplay and network conditions.

Back to top