Photon Fusion Inspector Tutorial

This page accompanies the Photon Fusion Inspector Tutorial – Visual Debugging & Optimization video and explains how to inspect networked scene objects, prefabs, and NetworkBehaviour components across a Photon Fusion project.

Use this page when auditing network configuration, investigating frequently changing state, comparing networked prefab sizes, checking authority at runtime, or understanding how Fusion features are distributed throughout a project.

For more information visit our documentation about the Fusion Inspector right here.

Overview

Fusion Inspector is an add-on for visualizing and analyzing Fusion projects inside the Unity Editor.

It provides project-wide information about:

• networked scene objects;
• registered network prefabs;
• scripts derived from NetworkBehaviour;
• Networked state size;
• State Authority;
• state-change frequency;
• overridden Fusion callbacks;
• implemented Fusion interfaces;
• declared RPCs;
• script execution order.

The tool works in both Edit Mode and Play Mode.

Edit Mode is useful for auditing configuration before objects spawn. Play Mode adds runtime information such as authority, distance, and state-change statistics.

This video uses the Fusion Asteroids sample to demonstrate:

• installing the latest Fusion Inspector package;
• navigating its three primary sections;
• inspecting networked scene objects;
• comparing network prefab configuration;
• auditing NetworkBehaviour scripts;
• filtering and sorting results;
• selecting multiple objects for detailed analysis;
• finding objects with frequent state changes;
• enabling docked Inspector windows;
• understanding the tool’s Editor performance cost.

Video Timeline

Time	Section
00:00	Introduction
00:20	Downloading and importing Fusion Asteroids
01:14	Downloading and importing Fusion Inspector
01:24	Fusion Inspector walkthrough
08:12	Bonus Fusion Inspector tip

What Is Fusion Inspector?

Fusion Inspector is an Editor add-on that presents a consolidated view of Fusion objects, prefabs, and components.

Instead of manually opening individual prefabs or searching scripts one at a time, the Inspector can answer questions such as:

• Which scene objects currently have State Authority?
• Which prefabs have the largest expected Networked state?
• Which objects are changing their Networked properties most often?
• Which scripts override FixedUpdateNetwork()?
• Which components declare RPCs?
• Which objects are near the player or camera?
• Which NetworkBehaviour types are used most frequently?
• Which components implement a specific Fusion interface?

It is primarily a development, debugging, and optimization tool.

Installing the Sample Project

The video uses the Fusion Asteroids sample as a project with existing networked objects and gameplay systems.

A typical setup process is:

1. Download the Fusion Asteroids sample.
2. Open the project in a supported Unity version.
3. Allow Unity to upgrade the project if required.
4. Verify that Fusion is installed and configured.
5. Open the sample scene.
6. Test that the game runs before adding the latest Inspector package.

Using an existing sample provides enough scene objects, prefabs, Networked state, and runtime activity to demonstrate the Inspector effectively.

Installing Fusion Inspector

Some samples may already contain an older version of Fusion Inspector.

To use the current version:

1. Locate the existing Fusion Inspector folder.
2. Remove the outdated add-on if necessary.
3. Download the current package.
4. Import it into the Unity project.
5. Allow scripts to compile.
6. Open Fusion Inspector from its Editor menu or toolbar overlay.

Avoid keeping multiple versions of the add-on in the same project because duplicate scripts or assemblies can cause compilation conflicts.

Main Sections

Fusion Inspector contains three primary sections:

Section	Purpose
Scene Objects	Displays networked objects in the currently loaded scene.
Prefabs	Displays registered networked prefabs and their expected configuration.
Components	Displays scripts derived from NetworkBehaviour.

Each section answers a different category of debugging question.

Edit Mode and Play Mode

Fusion Inspector works in both Unity Edit Mode and Play Mode.

Edit Mode

Edit Mode is useful for:

• checking static configuration;
• auditing scene objects;
• reviewing network prefab setup;
• comparing expected Networked state size;
• finding component usage;
• inspecting callback and interface implementation.

Play Mode

Play Mode adds runtime information such as:

• current State Authority;
• object distance;
• total state changes;
• average state changes;
• active scene-object statistics;
• detailed changes by component.

Use Play Mode when investigating actual runtime behavior rather than only expected configuration.

Toolbar Overlay

Fusion Inspector includes a toolbar overlay for quick access.

The overlay reduces the need to navigate through Unity menus repeatedly.

Depending on the package version, it can provide shortcuts for opening the available Inspector views or switching between common analysis modes.

Scene Objects Section

The Scene Objects section displays Fusion network objects in the currently loaded scene.

This can include:

• scene-placed NetworkObject instances;
• spawned runtime objects;
• player objects;
• enemies;
• projectiles;
• shared world objects;
• Master Client-controlled objects.

Scene Object References

Each entry includes a reference to the corresponding Unity object.

Double-click the reference to select the object in the Unity Hierarchy.

This is useful when the Inspector reveals a suspicious object and you need to inspect its:

• NetworkObject;
• attached NetworkBehaviour components;
• prefab relationship;
• authority settings;
• hierarchy;
• scene configuration.

Scene Object Configuration

The Scene Objects section can display configuration from each object’s NetworkObject.

Relevant data can include:

• Shared Mode configuration;
• authority-related settings;
• network flags;
• object identity;
• attached components;
• state size.

This makes it possible to audit many network objects without selecting them individually.

Runtime Information

During an active Fusion session, Scene Objects can expose additional runtime values.

Examples include:

• whether the local peer has State Authority;
• runtime object status;
• total Networked state changes;
• average state changes;
• distance from a selected reference;
• object-level Networked state size.

Runtime data is particularly useful for debugging Shared Mode authority and frequently changing state.

Networked State Size

Networked State Size estimates or reports how much replicated state is associated with an object.

For a complete scene object, this includes the Networked state contributed by its attached NetworkBehaviour components.

Use this value to:

• compare similar objects;
• identify unexpectedly large player prefabs;
• detect components with excessive Networked properties;
• review the cost of highly replicated entities;
• prioritize optimization work.

State size is one part of network cost. Update frequency, interest management, player count, and change frequency also affect actual traffic.

Distance Measurements

Scene Objects can be sorted or filtered by distance from references such as:

• the local player object;
• the main camera;
• the Unity Editor camera.

This supports questions such as:

• Which networked objects are within 50 meters of the player?
• Which enemies are currently near the camera?
• Which distant objects are still changing frequently?
• Which nearby objects should be included in interest management?

Distance information can help correlate network activity with spatial relevance.

Name Filtering

Use the name filter to find objects by naming convention.

Examples:

Enemy

Player

Projectile

Consistent object naming improves the usefulness of this filter.

Component Filtering

Scene Objects can also be filtered by attached component types.

This can be used to find all objects containing a component such as:

• player movement;
• health;
• weapon state;
• enemy AI;
• interest management;
• physics synchronization.

Component filtering is more reliable than name filtering when object names vary.

Auditing Scene Network Objects

The Scene Objects section is useful for auditing objects that are placed directly in the scene rather than spawned from prefabs.

Check for:

• unexpected NetworkObject instances;
• incorrect Shared Mode settings;
• missing or unnecessary Networked components;
• authority override configuration;
• large state sizes;
• scripts changing state too frequently.

Scene-placed network objects can be overlooked because they are not always reviewed alongside the prefab registry.

State Authority Filtering

In Play Mode, filter by the State Authority field.

A useful workflow is:

1. Click the State Authority header.
2. Set the field filter to show only true.
3. Sort by total state changes.
4. Inspect which locally authoritative objects are changing most frequently.

This helps narrow the analysis to objects whose state the local client is currently writing.

Total State Changes

Total State Changes tracks how many changes have been observed during the current inspection period.

A high value can indicate:

• Networked properties changing every tick;
• noisy values;
• rapidly changing object state;
• unnecessary writes;
• active movement or simulation;
• a component updating more often than expected.

This value is a diagnostic signal rather than a direct bandwidth measurement.

A state change may not map one-to-one to a fixed number of transmitted bytes because Fusion uses its own replication, compression, and scheduling behavior.

Average State Changes

Average State Changes helps compare change activity over time.

This is useful when analyzing:

• steady-state network behavior;
• short gameplay events;
• combat sequences;
• movement;
• object spawning;
• temporary abilities.

For example, record the average before and during an attack sequence to identify which objects or components become more active.

Multi-Object Selection

Select multiple Scene Object entries using:

• Ctrl for individual selections;
• Shift for a range.

A detailed view can then show the selected objects and their component-level state-change information.

This helps determine whether an object-level spike comes from:

• movement state;
• health;
• inventory;
• weapons;
• animation;
• a custom Networked component.

Component-Level Change Analysis

An object can contain multiple NetworkBehaviour components.

Object-level state changes show that the object is active, but component-level inspection helps identify the source.

For example:

Component	Possible State Activity
Player movement	Position, rotation, velocity, movement state
Weapon handler	Ammo, cooldown, fire events
Health	Damage and healing
Animator state	Movement and action parameters
Inventory	Item changes

Use multi-selection and detailed views to narrow optimization work to the responsible component.

Scene Objects Value Context Menu

Values in the Scene Objects table can expose context-menu actions.

Depending on the selected field and Inspector version, these actions can help:

• copy a value;
• select the referenced object;
• apply a related filter;
• navigate to associated data;
• inspect details.

Right-click values and headers when exploring the tool because many controls expose additional functionality through context menus.

Prefabs Section

The Prefabs section displays networked prefab assets registered for Fusion.

This is useful before the prefabs have spawned.

It allows developers to audit their expected network footprint during project setup rather than waiting for runtime instances.

Prefab References

Each entry links to the corresponding Unity prefab.

Double-click the reference to open or select the prefab asset.

From there, inspect:

• NetworkObject;
• attached NetworkBehaviour components;
• Networked properties;
• synchronization components;
• authority settings;
• nested network objects.

Prefab Configuration

The Prefabs section can show relevant configuration associated with each network prefab.

This enables project-wide checks for:

• inconsistent authority settings;
• unnecessary network components;
• incorrect spawn configuration;
• oversized replicated state;
• prefabs that do not follow project conventions.

Expected State Size at Spawn

The prefab’s Networked State Size represents its expected replicated state when instantiated.

This is useful for estimating the relative cost of object categories before runtime.

For example:

1. Filter prefab names by Enemy.
2. Sort by Networked State Size.
3. Review the largest enemy prefabs.
4. Inspect whether every Networked property is necessary.
5. Compare boss and standard enemy configurations.

Prefab Optimization

Large state size is not automatically incorrect.

A large prefab may legitimately require more replicated data.

The value should trigger investigation when:

• similar objects differ significantly;
• a simple object has unexpectedly high state size;
• a frequently spawned object contains many Networked fields;
• data could be derived locally rather than synchronized;
• temporary state remains permanently Networked.

Filtering Prefabs

The Prefabs section supports filters such as:

• object name;
• attached components;
• field-specific values.

Examples:

• find all enemy prefabs;
• find all prefabs using a movement component;
• find all objects containing RPC handlers;
• compare all projectile prefabs;
• identify prefabs with a specific synchronization component.

Prefabs Value Context Menu

Prefab values can also expose context-menu operations.

Use these controls to navigate quickly from a table entry to the prefab asset or related configuration.

Components Section

The Components section displays scripts derived from:

C#

NetworkBehaviour

This provides a code-oriented view of the project’s Fusion architecture.

Instead of showing runtime object instances, it shows the reusable component types that define network behavior.

Component Type References

Each entry includes the component type name.

Double-click the type to locate or select the corresponding MonoScript asset.

This creates a direct path from inspection data to source code.

Fusion Callback Overrides

The Components section can indicate whether a script overrides Fusion callbacks such as:

• Spawned();
• Despawned();
• FixedUpdateNetwork();
• Render().

This answers questions such as:

• Which components run tick-based logic?
• Which scripts contain render-side presentation logic?
• Which components perform initialization during spawning?
• Which components handle cleanup during despawning?

Fusion Interface Implementations

The Inspector can also show implemented Fusion interfaces.

Examples can include:

• ISimulationEnter;
• ISimulationExit;
• IAfterHostMigration;
• IInterestEnter;
• other Fusion-specific interfaces.

This helps locate systems associated with:

• simulation lifecycle;
• host migration;
• interest management;
• specialized Fusion callbacks.

Scene Object Usage Count

The Components section can display how many current scene objects use each component.

Sort by this value to determine:

• which components are most widespread;
• which scripts affect the largest number of runtime objects;
• which components should receive priority during optimization;
• whether a supposedly specialized component is attached broadly.

A small inefficiency in a component used by thousands of objects can matter more than a larger inefficiency used once.

Prefab Usage Count

The prefab count shows how many network prefabs include a component.

This helps identify:

• shared foundational components;
• legacy scripts still present in prefabs;
• components used by many entity types;
• potential refactoring targets.

RPC Count

The Components section can report how many RPCs a script declares.

Use this to:

• locate RPC-heavy components;
• audit communication patterns;
• find scripts that mix many responsibilities;
• review whether events should use RPCs or Networked properties;
• inspect potential sources of frequent message traffic.

A high RPC count is not automatically a problem, but it may indicate a component that deserves closer review.

Component Networked State Size

The Networked State Size for a component shows its contribution to object state.

This helps identify which script is responsible for a large object footprint.

For example, a player object may be large because of:

• inventory data;
• animation state;
• weapon state;
• movement history;
• replicated configuration.

Component-level state size provides a more actionable result than object-level size alone.

Script Execution Order

The Components section can display Script Execution Order.

Use this when diagnosing:

• Unity callback ordering;
• dependencies between MonoBehaviours;
• initialization timing;
• presentation scripts running before required data exists.

Fusion simulation ordering and Unity Script Execution Order are separate concepts, but both can affect how project code behaves.

Component Type Filtering

Filter components by type name.

Examples:

Player

Weapon

Interest

Network

Use consistent class naming to make project-wide inspection easier.

Components Without FixedUpdateNetwork

To find components that do not override FixedUpdateNetwork():

1. Locate the corresponding callback column.
2. Click the field header until the red filter state is active.
3. Review the resulting component list.

This can help distinguish:

• presentation-only components;
• RPC-only components;
• state containers;
• scripts using other lifecycle callbacks.

Not overriding FixedUpdateNetwork() is not inherently a problem. The filter is useful for architecture review.

Components Implementing IInterestEnter

To find components implementing IInterestEnter:

1. Locate the relevant interface indicator.
2. Toggle the green filter state.
3. Inspect the matching component types.

This quickly locates code associated with interest-management entry behavior.

Total and Average Changes by Component

In runtime analysis, components can be sorted by total or average state changes.

This helps identify Networked scripts whose state changes frequently across all instances.

Useful questions include:

• Is a value being written every tick even when unchanged?
• Is a Networked float too noisy?
• Is a component active on more objects than expected?
• Does a temporary gameplay event generate excessive state changes?
• Can some state be derived locally?

State Changes and Network Traffic

Frequent Networked state changes often correlate with more replication work.

However, the Inspector’s change counters should be treated as an optimization lead, not an exact bandwidth profiler.

Actual traffic depends on factors such as:

• serialization size;
• change masks;
• delta compression;
• tick rate;
• interest management;
• number of receiving peers;
• object visibility;
• transport overhead.

Use state-change metrics to identify candidates, then confirm results with Fusion’s runtime statistics or other network profiling tools.

Interactive Field Filtering

Many Inspector columns use a three-state field-header filter.

The states are commonly represented as:

State	Result
Default	Show all entries.
Green	Show entries where the feature or condition is present.
Red	Show entries where the feature or condition is absent.

This makes it possible to combine questions such as:

• show objects with State Authority;
• hide components that override Render();
• show scripts that implement an interest interface;
• find components without RPCs.

Sorting

Click a field header to sort by its values.

Repeated clicks can switch between:

• ascending;
• descending;
• default order.

Sorting is especially useful for numerical fields such as:

• state size;
• total changes;
• average changes;
• object count;
• prefab count;
• RPC count;
• distance.

Combining Filters and Sorting

Filters narrow the set of entries.

Sorting ranks the remaining entries.

Example workflow:

1. Filter Scene Objects to HasStateAuthority = true.
2. Filter by a gameplay component.
3. Sort by total state changes.
4. Select the highest entries.
5. Open the detailed component view.
6. Inspect the responsible Networked properties.

This produces a more focused investigation than sorting the complete project.

Practical Example: Authoritative Objects with Frequent Changes

To identify locally authoritative objects generating frequent state updates:

1. Enter Play Mode.
2. Open Scene Objects.
3. Filter HasStateAuthority to green.
4. Sort Total State Changes in descending order.
5. Select the highest objects.
6. Inspect their component-level changes.
7. Open the relevant scripts.

Possible findings include:

• movement state changing every tick;
• an unnecessary Networked timer;
• values being assigned even when unchanged;
• state that could be derived locally.

Practical Example: Enemy Prefab State Size

To compare enemy prefabs:

1. Open Prefabs.
2. Filter by Enemy.
3. Sort Networked State Size from highest to lowest.
4. Open the largest entries.
5. Compare attached NetworkBehaviour components.
6. Check whether large Networked collections or fields are necessary.

This helps optimize network footprint before enemies spawn.

Practical Example: Components by State Changes

To identify active component types:

1. Open Components in Play Mode.
2. Sort by Total State Changes.
3. Inspect the highest entries.
4. Compare state size and instance count.
5. Determine whether high change count is expected.

A movement component on many active players may legitimately rank highly. A static metadata component should not.

Practical Example: Components by Scene Usage

Sort components by scene-object count.

This reveals the most widely used network scripts.

These scripts deserve particular attention because:

• bugs affect many objects;
• small state sizes accumulate;
• frequent writes multiply across instances;
• execution cost scales with usage.

Practical Example: Missing FixedUpdateNetwork

Use the red FixedUpdateNetwork indicator to find components that do not override the method.

This can help during architectural review when looking for:

• scripts expected to run simulation logic but do not;
• presentation-only components;
• components relying on RPCs or Networked callbacks instead.

Do not assume the absence of FixedUpdateNetwork() is an error without reviewing the component’s intended role.

Practical Example: Interest Interfaces

Use the interface filters to locate components associated with interest management.

For example, filter for IInterestEnter to review:

• visibility-entry effects;
• local initialization when an object becomes relevant;
• interest-based presentation;
• state handling when objects enter a player’s interest set.

Docking Fusion Inspector

By default, Fusion Inspector can open as a utility window.

A utility window:

• remains above normal Unity windows;
• may be convenient for temporary inspection;
• cannot be docked in the standard Editor layout.

To enable docking, add the following scripting define symbol:

FUSION_INSPECTOR_DOCKED

Add it through Unity Player Settings for the relevant build target.

After recompilation, the Inspector can open as a dockable Editor window.

Adding the Define Symbol

A typical workflow is:

1. Open Project Settings.
2. Select Player.
3. Open the relevant platform settings.
4. Find Scripting Define Symbols.
5. Add:
   FUSION_INSPECTOR_DOCKED
6. Apply the change.
7. Wait for scripts to recompile.
8. Reopen Fusion Inspector.

Preserve the existing symbols and separate entries correctly according to the Unity version.

Multiple Inspector Windows

With docked mode enabled, multiple Fusion Inspector windows can be opened simultaneously.

This supports side-by-side comparison.

Examples include:

• Scene Objects beside Components;
• authoritative objects beside all objects;
• enemy prefabs beside player prefabs;
• state size beside state changes;
• two different filtered component views.

Each window can maintain a distinct filter and sort configuration.

Side-by-Side Analysis

A useful layout can include:

Window	Configuration
Left	Scene Objects filtered to local State Authority
Right	Components sorted by total state changes

Another layout could use:

Window	Configuration
Left	Enemy prefabs sorted by state size
Right	Components filtered by enemy-related type names

This reduces repeated filter changes while investigating related data.

Editor Performance Cost

Fusion Inspector iterates over project or scene information to keep its views updated.

In Play Mode, runtime views may inspect objects every Unity frame.

With thousands of objects, this can add Editor CPU overhead.

This does not necessarily indicate that the build itself has the same cost. The overhead comes from the debugging tool running inside the Editor.

Reducing Inspector Overhead

When analyzing large projects:

• open only the windows currently needed;
• close Inspector views when measuring baseline Editor performance;
• avoid keeping several runtime windows open unnecessarily;
• use filters to reduce visual complexity;
• profile standalone builds separately;
• do not treat Editor frame rate with the Inspector open as final game performance.

The tool is intended to reveal issues, but it can affect the environment being measured.

Optimization Workflow

Use Fusion Inspector as part of a structured optimization process:

1. Establish a representative gameplay scenario.
2. Open the relevant Inspector section.
3. Filter to the object category being investigated.
4. Sort by state size or state-change activity.
5. Select suspicious entries.
6. Inspect component-level data.
7. Open the corresponding prefab or script.
8. Make one focused optimization.
9. Repeat the same test.
10. Confirm the result with runtime network statistics.

Interpreting Large State Size

When a component has large Networked state, investigate:

• arrays or collections;
• large network strings;
• redundant booleans;
• duplicated state;
• high-precision values;
• state that can be derived;
• data needed only by State Authority;
• values that could be stored in non-Networked configuration.

Do not remove required state solely to reduce the reported size.

Interpreting Frequent State Changes

When a component changes frequently, investigate whether:

• values are assigned every tick without checking;
• noisy floats can be quantized;
• a value can be computed locally;
• a property needs to be Networked;
• the update rate can be reduced;
• interest management can limit recipients;
• an event would be better represented by an RPC;
• an RPC would be better represented by state.

The correct solution depends on whether the data represents persistent state or a one-time event.

Inspector Data and Bandwidth

Fusion Inspector helps identify potential network cost, but it does not replace complete traffic analysis.

Networked State Size indicates data footprint.

State changes indicate activity.

Actual network bandwidth also depends on:

• how many clients receive the object;
• snapshot frequency;
• replication rules;
• compression;
• interest management;
• transport behavior.

Use the Inspector to locate candidates, then verify with actual runtime statistics.

Key Concepts

Concept	Description
Fusion Inspector	Unity Editor add-on for inspecting Fusion objects, prefabs, and components.
Scene Objects	View of networked objects in the loaded scene or active session.
Prefabs	View of registered network prefab assets and expected state configuration.
Components	View of project scripts derived from NetworkBehaviour.
Networked State Size	Size contributed by replicated Networked state.
Total State Changes	Number of observed state changes during the inspection period.
Average State Changes	Average change activity measured over time.
State Authority	Peer currently allowed to write an object’s Networked state.
Field selector	Column control used to filter entries by a feature or condition.
Multi-selection	Selection of several objects for combined detailed analysis.
Toolbar overlay	Quick-access Unity toolbar control for Fusion Inspector.
FUSION_INSPECTOR_DOCKED	Define symbol that enables dockable Inspector windows.
NetworkBehaviour	Fusion base class for networked component scripts.
Execution Order	Unity ordering configuration associated with scripts.

Best Practices

Use this checklist when working with Fusion Inspector:

• Use Edit Mode for configuration audits.
• Use Play Mode for authority and state-change analysis.
• Filter by object category before comparing values.
• Sort by Networked State Size to find large state footprints.
• Sort by total or average changes to find active objects.
• Inspect component-level changes before modifying code.
• Use State Authority filters in Shared Mode debugging.
• Audit scene objects as well as prefabs.
• Review frequently used components because costs scale by instance count.
• Treat state changes as an optimization lead, not exact bandwidth.
• Confirm changes with runtime network statistics.
• Use clear object and component naming conventions.
• Enable docking for persistent side-by-side analysis.
• Close Inspector windows when measuring baseline Editor performance.
• Profile standalone builds independently of Editor tooling.

Common Pitfalls

Pitfall	Why It Is a Problem
Treating Networked State Size as actual bandwidth	Traffic also depends on changes, recipients, compression, and tick rate.
Treating every frequent state change as a bug	Movement and other active systems may legitimately change every tick.
Optimizing only the largest object	A small component used by thousands of objects may cost more overall.
Ignoring scene-placed network objects	They may contain incorrect or expensive configuration outside the prefab workflow.
Looking only at total changes	Component-level detail is needed to find the actual source.
Assuming missing FixedUpdateNetwork() is an error	Some components are intentionally presentation-only or event-driven.
Leaving multiple Inspector windows open during performance tests	The tool itself adds Editor CPU overhead.
Measuring only in the Unity Editor	Editor and Inspector overhead do not represent a production build.
Removing state based only on size	The state may be required for gameplay correctness or late joining.
Editing an old embedded add-on without updating it	The sample may contain an outdated Inspector version.
Importing a new version without removing conflicts	Duplicate add-on scripts can cause compilation errors.
Assuming State Authority alone explains all network activity	Interest, object count, changes, and recipients also matter.

Related Links

• Photon
• Photon Fusion
• Fusion Inspector
• Fusion Asteroids
• Photon Dashboard
• Fusion Shared Mode Basics
• Photon Samples
• Fusion Starter

Summary

Fusion Inspector provides a project-wide view of networked scene objects, prefab assets, and NetworkBehaviour scripts.

The Scene Objects section is useful for inspecting runtime authority, object distance, Networked state size, and state-change activity.

The Prefabs section helps audit expected state size and configuration before objects spawn.

The Components section reveals callback overrides, implemented interfaces, RPC counts, execution order, usage counts, and component-level state size.

Filtering, sorting, multi-object selection, and side-by-side docked windows make it possible to move from a broad project overview to a specific object or script.

Fusion Inspector should be used as a diagnostic tool rather than a complete bandwidth profiler. Its state-size and state-change data identify optimization candidates, which should then be verified under representative runtime conditions.

Last updated on 16/09/2026

Back to top