This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Cam Manager

How to work with the GS_PhantomCam manager — enabling and disabling the camera system, and responding to active camera changes.

The Cam Manager is the camera system’s singleton manager. It integrates with GS_Core’s standard manager lifecycle, handles the camera system’s startup and shutdown through the two-stage initialization sequence, and maintains awareness of which Phantom Camera is currently dominant. Any time the active camera changes, the Cam Manager broadcasts a notification so dependent systems can react without polling.

For architecture details, component properties, and extending the system in C++, see the Framework API reference.

Cam Manager component in the O3DE Inspector

 

Contents

Manager Lifecycle

The Cam Manager is a GS_ManagerComponent and participates in the standard GS_Core startup sequence. It activates alongside all other managers during the two-stage initialization, making it safe to call camera system methods any time after OnStartupComplete.

StageWhat Happens
InitializeCam Manager activates and registers with the camera pipeline.
Startup (OnSetupManagers)Manager is initialized. Safe to query camera state.
Complete (OnStartupComplete)All managers ready. Safe to enable or disable the camera system.

Enabling and Disabling the Camera System

The camera system can be suspended and resumed independently of other gameplay systems. This is used during UI-only states, loading screens, or when a cinematic takes direct control of the camera.

NotificationWhat It Does
EnableCameraSystemActivates the camera system. Phantom Cameras resume competing for priority.
DisableCameraSystemSuspends the camera system. The real camera stops receiving updates from Phantom Cameras.

Both events are on CamManagerNotificationBus. Broadcast them to switch the camera system state from any script or component.

Tracking the Active Camera

The Cam Manager broadcasts SettingNewCam on CamManagerNotificationBus whenever a different Phantom Camera becomes dominant. This fires any time a camera with higher priority activates, a dominant camera deactivates, or a blend resolves to a new target.

Use this event in any system that needs to know which camera is currently active — aiming reticles, world-space UI elements, minimaps, or audio listener positioning.

ScriptCanvas

Suspending the Camera System

ScriptCanvas

Broadcast DisableCameraSystem to suspend camera updates, for example when a cutscene takes direct camera control:

Because DisableCameraSystem and EnableCameraSystem are notifications rather than requests, they are fire-and-forget. Any script can broadcast them.

Changing the Camera Target

ScriptCanvas

The follow target, designated by the CamManager, can be set with Get/Set Target:

Three Authoring Tiers

The Cam Manager exposes three top-level fields that control how the camera system is configured for your project. Most single-player projects use Tier 1; multi-player or split-screen projects use Tier 3.

TierCam Manager configurationWhen to choose it
Tier 1 — Single Camm_primaryRigPrefab set, m_enableInstancedChannels = falseSingle-player projects with a normal camera rig. The default for most games.
Tier 2 — Level-placed CamCoreNo primary rig prefab, m_enableInstancedChannels = falseLegacy single-player flow where the Cam Core is hand-placed in each level.
Tier 3 — Multi-Channelm_enableInstancedChannels = true, m_channelConfigs populatedSplit-screen, local co-op, or cinematic projects that need per-player rigs and arbitration.

For the full step-by-step walkthrough of each tier — including common Tier 3 patterns (shared cinematic cams, hero-perspective cams, cross-channel dispatch) and the lobby flow for variable player counts — see the dedicated Channels page:

Channels & Instancing API

Cam Manager Entity Configuration

Cam Manager entity setup in the O3DE Editor

In Tier 1, assign your rig prefab (containing a Cam Core and any cams that should persist with the manager) to the Cam Manager’s Primary Rig Prefab field. The Cam Manager spawns the rig at startup.

In Tier 2, hand-place the Cam Core entity as a child of the Cam Manager. Any phantom cameras that should persist between stage changes can sit alongside the Cam Core.

In Tier 3, populate m_channelConfigs with one entry per supported player slot — see Channels & Instancing.

Across all tiers, the PossessedUnit event on a player controller is a convenient way to push the camera target the moment the player unit spawns.

Quick Reference

NeedBusMethod / Event
Enable the camera systemCamManagerNotificationBusEnableCameraSystem
Disable the camera systemCamManagerNotificationBusDisableCameraSystem
Set the camera target (single-player)CamManagerRequestBusSetTarget(playerEntityId)
Set a channel’s target (multi-channel)CamManagerRequestBusSetChannelTarget(channelId, entity)
Know when the active camera changes (single-player)CamManagerNotificationBusSettingNewCam(newCamEntityId)
Know when a channel’s active cam changes (multi-channel)CamManagerNotificationBusSettingNewCamOnChannel(channelId, cam)
Spawn / despawn a channel mid-sessionCamManagerRequestBusEnableChannel(id) / DisableChannel(id)
Set the engine’s active main viewCamManagerRequestBusSetActiveChannel(id) or SetActiveCamCore(camCore)

Glossary

TermMeaning
Cam ManagerThe singleton manager for the PhantomCam system that tracks active cameras and broadcasts changes
Dominant CameraThe Phantom Camera with the highest priority that currently drives the real camera

For full definitions, see the Glossary.

See Also

For the full API, component properties, and C++ extension guide:

For related systems:

Get GS_PhantomCam

GS_PhantomCam — Explore this gem on the product page and add it to your project.

1 - Channels & Instancing

Concept primer for the PhantomCam channel system — what a channel is, which authoring tier to choose, and the pitfalls to know before authoring.

GS_PhantomCam can be configured at three different tiers depending on what your project needs. Most projects use Tier 1 (single-cam) or Tier 2 (single-player rig). Co-op, split-screen, and per-player-cinematic projects use Tier 3 (multi-channel). The per-cam authoring surface is identical across tiers — what changes is the Cam Manager configuration and how many rigs the system spawns.

This page is a concept primer. For step-by-step Tier 1 / Tier 2 / Tier 3 walkthroughs, common Tier 3 patterns, and the lobby-flow recipe for variable player counts, see the recipes collection.

Channel Tier Configurations (Recipes) API

For architecture details and the full bus surface, see the Framework API reference.

 

Contents

What Is a Channel?

A channel is one player viewpoint slot. Each channel owns:

  • An instantiated rig subtree (one Cam Core + zero or more Phantom Cameras).
  • Its own target binding (typically the player unit for that channel).
  • Its own priority table — arbitration is independent per channel.
  • Its own active influence-field records.

Channel 0 is the implicit default for all single-player flows. You only deal with non-zero channels in Tier 3.

Multi-view rendering is pending. Until the AttachmentImage work lands, the engine renders one channel’s view at a time even when multiple channels are arbitrating internally. The Cam Manager’s active main-view API selects which channel reaches the framebuffer. The arbitration / dispatch / target binding all work today — only the simultaneous-rendering piece is gated.

Choosing a Tier

TierCam Manager configurationWhen to choose itRecipe
Tier 1 — Single Camm_primaryRigPrefab set, m_enableInstancedChannels = falseSingle-player projects with a normal camera rig. The default for most games.Tier 1 walkthrough
Tier 2 — Level-placed CamCoreNo primary rig prefab, m_enableInstancedChannels = falseLegacy single-player flow where the Cam Core is hand-placed in each level rather than spawned from a prefab. Supported but not preferred.Tier 2 walkthrough
Tier 3 — Multi-Channelm_enableInstancedChannels = true, m_channelConfigs populatedSplit-screen, local co-op, or cinematic projects that need per-player rigs and arbitration.Tier 3 walkthrough

You can build a project at Tier 1, then add Tier 3 later by toggling the master gate and authoring channel configs — the per-cam configuration and stage compositions you authored at Tier 1 still work.

The Tier 3 walkthrough recipe also covers common Tier 3 patterns (in-rig per-player cams, shared cinematic collapse cams, hero-perspective cams, cross-channel dispatch) and the lobby flow for variable player counts.

Pitfalls

Tug-field channels are not instancing channels

Tug-field m_channels are arbitrary string tags (“Cinematic”, “Combat”) that match tug volumes to listeners. They are unrelated to the integer ChannelIds on this page despite the shared word. See Tug Fields for the unrelated tagging system.

A cam outside any rig prefab in Tier 3

If you place a Local-scope Phantom Camera in the level (not inside a rig prefab) with multi-channel ON, the stamp-walk misses and the cam falls through to legacy channel 0. This may surprise you. To make a level-placed cam channel-aware in Tier 3, set its scope to TrueUnique with explicit binding.

AllChannels outside a rig prefab

AllChannels-scoped cams outside a rig prefab currently warn and fall back to channel 0. The “out-of-rig runtime cloning” path is deferred. For per-player broadcast cams, place the cam inside the rig prefab.

Cam Manager spawns BEFORE HandleStartup

The Cam Manager spawns configured rigs from OnStartupComplete and only then broadcasts HandleStartup. This means cams inside spawned rigs receive the startup wave alongside everything else — your gameplay code can rely on Cam Cores being registered by the time HandleStartup fires. Stage transitions follow the same pattern: respawn before re-broadcasting HandleStartup.

See Also

Recipes:

Framework API:

Related basics pages:

Get GS_PhantomCam

GS_PhantomCam — Explore this gem on the product page and add it to your project.