GS_PhantomCam

Rather than moving a single camera directly, GS_PhantomCam lets you place lightweight virtual cameras — “phantoms” — throughout the scene. Each phantom holds a complete camera state and a priority value. The Cam Core component drives the real camera to match whichever phantom currently has the highest effective priority. Transitions are animated by Blend Profiles that specify duration, easing, blend shape, and optional state inheritance. Influence Fields modify camera selection spatially or globally without changing base priorities.

Each phantom is not a fixed-behavior camera. It hosts a composable Body → Aim → Reposition additives → Noise additives stage pipeline — so the same component drives follow cams, orbital cams, tracking dollies, third-person shoulder cams, and cinematic stingers depending on which stages are slotted. The framework also runs a channel system that scales from arcade single-cam through 4-player split-screen co-op with no changes to the per-cam authoring surface.

For usage guides and setup examples, see The Basics: GS_PhantomCam.

 

Contents

• Architecture
• Cam Manager
• Cam Core
• Phantom Cameras
• Stage Pipeline
• Channels & Instancing
• Blend Profiles
• Camera Influence Fields
• Group Targets
• Tug Fields
• Noise & Impulse
• Orbit Profiles
• State Inheritance
• Camera Input Reader
• Cross-Gem Contracts
• Installation
• See Also

---

Architecture

Breakdown

Each phantom camera publishes a pose every tick by running its stage pipeline. The Cam Manager arbitrates priority across all registered phantoms inside a channel and notifies the channel’s Cam Core when the winner changes. The Cam Core then blends from the outgoing pose to the new one, optionally inheriting pose state across the transition and applying mid-blend interrupt correction when a new winner appears before the current blend completes.

Step	What it means
1 — Per-tick pipeline	Each phantom threads a CameraState through Body → Aim → Reposition additives → Noise additives → Finalize. The committed transform is published to the entity.
2 — Priority arbitration	The Cam Manager re-evaluates base + sum(influences) per channel. Channel 0 covers all legacy / single-player flows.
3 — Dominance change	When a channel’s winner changes, the Cam Manager fires SettingNewCam (or SettingNewCamOnChannel when channel instancing is on).
4 — Profile query	Cam Core calls GetBestBlend(fromCam, toCam) on the assigned Blend Profile. The matched entry returns blend time, easing curve, blend shape (Linear / Spherical / Cylindrical), an inherit-state flag, and a pivot source selector.
5 — State inheritance	If inherit-state is set, the outgoing cam publishes a CamPoseSnapshot; the incoming cam’s Body adopts it through its own kinematic interpretation (orbit yaw/pitch, track param, lead-follow seed).
6 — Interpolation	Cam Core blends position, rotation, and FOV over the entry’s blend time using the configured easing + shape. If a new blend interrupts this one, a correction window pulls the new start curve back from the rendered TM.

E Indicates extensible classes and methods.

Patterns - Complete list of system patterns used in GS_Play.

---

Cam Manager

The Cam Manager is the singleton controller for the entire camera system. It extends GS_ManagerComponent and now owns six responsibilities:

• Registration — Every phantom camera and Cam Core self-registers on activate; the Cam Manager holds authoritative per-channel tables.
• Priority evaluation — When any camera’s priority changes, EvaluatePriority re-sorts each channel and determines its dominant camera. A dominance change fires SettingNewCam (instancing off) or SettingNewCamOnChannel (instancing on).
• Influence routing — Priority influences from Influence Fields or gameplay code are routed to the channel of the affected target via AddCameraInfluence(sourceEntity, targetEntity, camName, influence). Influences whose target isn’t bound to any channel are silently dropped.
• Target system — Per-channel target bindings via SetChannelTarget(channelId, target). Legacy single-arg SetTarget forwards to channel 0.
• Group target registry — Named Group Targets self-register on activate so stages can resolve them by name.
• Dispatch overrides & active main-view — Cross-channel cinematic dispatch (DispatchCamToCamCore) and engine main-view selection (SetActiveChannel / SetActiveCamCore) wrap O3DE’s MakeActiveView for orchestrated multi-view flows.

Component	Purpose
GS_CamManagerComponent	Singleton manager. Channel registries, priority arbitration, influence routing, group-target registry, dispatch, active-view selection, rig spawning.

Cam Manager API

---

Cam Core

The Cam Core is the per-frame driver that makes the real O3DE camera match the dominant phantom for its channel. It lives on the main camera entity, which must be a child entity of the Cam Manager entity (or of a rig-prefab root in Tier 3) so it spawns and despawns with the camera system.

Every frame, when locked to a phantom, the Cam Core parents the main camera to that phantom entity and reads its position, rotation, and FOV directly. During a blend transition:

1. The Cam Core receives SettingNewCam (or SettingNewCamOnChannel) from the Cam Manager.
2. It queries the assigned Blend Profile for the best matching entry between the outgoing and incoming cameras.
3. The matched entry returns duration, easing, blend shape, an inherit-state flag, and a pivot source. If no profile entry matches, the Cam Core falls back to its own default blend time, easing, and shape.
4. If inherit-state is set, the outgoing cam’s Body publishes a CamPoseSnapshot and the incoming cam’s Body adopts it before the blend executes.
5. Over the blend duration, position, rotation, and FOV are interpolated using the configured easing curve and shape (Linear / Spherical-around-pivot / Cylindrical-around-pivot).
6. If a new blend starts mid-flight, a mid-blend correction window pulls the new start curve back from the rendered TM so the camera does not snap.
7. On completion, the Cam Core parents the main camera to the new dominant phantom, locking them together until the next transition.

Component	Purpose
GS_CamCoreComponent	Core camera driver. Blend execution (including interrupt correction), inheritance handoff site, drives the engine view, channel-aware via CamCoreRequestBus.

Cam Core API

---

Phantom Cameras

A Phantom Camera is a single entity component — GS_PhantomCameraComponent — that holds priority, lens, snap/focus state, target routing, and one stage pipeline slot authored by the user. It does not render anything. It registers with the Cam Manager on activation (auto-routing to the correct channel via its ChannelStampComponent ancestor) and publishes a per-tick pose from its Body + Aim + Additive stages.

Where previous versions of GS_PhantomCam shipped separate components per behavior (clamped-look, static-orbit, track, etc.), all of those behaviors are now stage variants layered on top of the single base component. Authors pick a Body stage, an Aim stage, and zero-or-more Additive stages from the editor’s type-picker.

Component	Purpose
GS_PhantomCameraComponent	Base virtual camera. Carries the stage pipeline slot, priority, target routing, lens, snap/focus/blendingOut state.
AlwaysFaceCameraComponent	Billboard utility — keeps an entity facing the active camera. Not a camera type itself.

Phantom Cameras API

Retired components. StaticOrbit_PhantomCamComponent, ClampedLook_PhantomCamComponent, and Track_PhantomCamComponent no longer exist as separate components. Their behavior is now provided by Body / Aim stage variants. Legacy URLs redirect to the matching stage docs.

---

Stage Pipeline

Every phantom camera runs the same fixed pipeline per tick:

Body → Aim → Reposition additives → Noise additives → Finalize

• Body writes state.position. Examples: DefaultFollowBody, OrbitBody, DynamicOrbitBody, LeadingFollowBody, TrackBody.
• Aim writes state.rotation. Examples: DefaultAim, ClampedLookAim. (Other gems — notably gs_performer — register additional aim variants.)
• Reposition additives correct the smoothed pose. Run BEFORE noise so noise can’t be undone. Examples: collision pushback, occlusion, tug listeners.
• Noise additives perturb the final pose. Examples: PerlinNoise (continuous handheld shake), ImpulseNoise (event-triggered ADSR burst).
• Finalize publishes the committed transform and lens.

Each stage owns its own damping. Stages are reflected polymorphic types — derived from IBodyStage / IAimStage / IAdditiveStage, not AZ::Component. The editor’s type-picker enumerates all registered derivations from the SerializeContext class hierarchy, so other gems can extend the catalog cleanly.

Stage Pipeline API

---

Channels & Instancing

A channel is one player viewpoint slot. Each channel owns its own rig (spawned from a prefab), its own Cam Core, its own target binding, its own priority table, and its own active influence set. Channel 0 is the implicit default for all single-player flows.

The system progressively discloses across three authoring tiers:

Tier	Setup	Behavior
Tier 1 — Arcade	Drop CamCore + PhantomCams in the level. Call SetTarget(player).	Legacy fallback. Cam Manager synthesizes channel 0 around level-placed cams.
Tier 2 — Standard single-player	Set m_primaryRigPrefab on the Cam Manager. Call SetTarget(player).	Cam Manager spawns the rig at startup; the prefab’s CamCore + cams self-register to channel 0.
Tier 3 — Co-op / split-screen / cinematic	Toggle m_enableInstancedChannels = true. Fill m_channelConfigs.	Per-channel arbitration, channel-aware influence routing, cross-channel dispatch, active-main toggling.

Concept	Purpose
Channel system	Scope enum (Local / AllChannels / TrueUnique), ChannelStampComponent runtime plumbing, spawn lifecycle, cross-channel dispatch, active-view selection.

Channels & Instancing API

Pending — multi-view rendering. Multi-view rendering ships with the AttImage render-target binding work. Until then, the engine renders one channel at a time even when multiple are arbitrating internally.

---

Blend Profiles

Blend Profiles are data assets (.camblendprofile) that define how the Cam Core transitions between phantom cameras. Each profile contains a list of blend entries. Each entry specifies a From camera, a To camera, a blend duration, an easing curve, a blend shape, an inherit-state flag, and a pivot source. This allows every camera-to-camera transition in your project to have unique timing, feel, and geometry.

Entry Resolution Order

1. Exact match — From name and To name both match.
2. Any-to-specific — From is blank/“any”, To matches the incoming camera.
3. Specific-to-any — From matches the outgoing camera, To is blank/“any”.
4. Default fallback — The Cam Core’s own default blend settings.

Blend Entry Fields

Field	Description
FromCamera	Outgoing phantom camera entity name. Blank/“any” matches all.
ToCamera	Incoming phantom camera entity name. Blank/“any” matches all.
BlendTime	Transition duration in seconds.
EasingType	Interpolation curve applied during the blend. See Curves Utility.
BlendShape	Linear, Spherical-around-pivot, or Cylindrical-around-pivot. Spherical sweeps the camera through a great-circle arc around a pivot; cylindrical does the same but only on the yaw axis.
InheritState	When set, the outgoing cam publishes a CamPoseSnapshot and the incoming cam’s Body adopts it before the blend executes. See State Inheritance.
PivotSource	Which point the shape uses as its pivot — target world position, body anchor, or look-at point.

Camera names correspond to entity names of the phantom camera entities in the scene.

Asset	Purpose
GS_PhantomCamBlendProfile	Blend settings asset. Per-pair transition duration, easing, shape, inherit-state, pivot source.

Blend Profiles API

---

Camera Influence Fields

Influence components modify the effective priority of phantom cameras without touching their base priority values. They work by calling AddCameraInfluence(sourceEntity, targetEntity, camName, influence) on the Cam Manager bus, identified by camera name. Multiple influences on the same camera stack additively.

The signature carries two entity arguments: the source (the field emitting the influence — used as the per-channel storage key so overlapping fields don’t collide) and the target (the entity that triggered the influence — used as the routing key to look up which channel the influence applies to). Influences whose target isn’t bound to any channel are silently dropped, which gives clean isolation between players in co-op.

GlobalCameraInfluenceComponent

Applies a constant priority modifier for its entire active lifetime. Useful for gameplay states that should always favor a particular camera — boosting a cutscene camera’s priority during a scripted sequence, for example.

Placement: Place GlobalCameraInfluenceComponent on the StageData entity. It activates and deactivates automatically with the stage, keeping camera influence scoped to the level that defines it.

CameraInfluenceFieldComponent

Applies a priority modifier only when the camera subject enters a defined spatial volume. Requires a PhysX Collider (set as trigger) on the same entity to define the volume. On entry, the influence is added; on exit, it is removed. See Physics Trigger Volume Utility for setup details.

Useful for level design — switching to an overhead camera when the player enters a room, or boosting a scenic camera in a vista area.

Component	Purpose
GlobalCameraInfluenceComponent	Global, constant priority modifier for a named camera. Place on the StageData entity.
CameraInfluenceFieldComponent	Spatial priority modifier. Activates when the camera subject enters the trigger volume. Requires a PhysX trigger collider.

Camera Influence Fields API

---

Group Targets

A Group Target is a target entity whose world transform is the weighted centroid of a subject set. Phantom Cameras point at it like any other target. The Cam Manager hosts a named registry so stages can resolve a group entity by string name.

Component	Purpose
GroupTargetComponent	Weighted multi-subject focal entity. Centroid modes (weighted mean, bbox center, sphere center). Optional derived rotation. Physics-aware cadence.

Group Targets API

---

Tug Fields

Tug Fields are collider-driven spatial reposition sources. A volume in the world pulls the camera’s body position and/or aim rotation toward a configured destination while a proxy attached to the rig is in contact with the volume. The system is decoupled into three components — CameraTugVolumeComponent (the trigger volume), CameraTugSourceComponent (the falloff geometry and destination), and TugFieldProxyComponent (the cam-side receiver) — and is PhysX-paired through dedicated TugProxy / TugField collision layers so the engine itself filters contacts. No registry, no Cam Manager involvement.

Naming note. Tug-field m_channels are arbitrary string tags (“Cinematic”, “Combat”) that match volumes to listeners. They are not the same as instancing ChannelIds, which are integer per-player slots — see Channels & Instancing.

Components	Purpose
Tug Fields	Volume / source / proxy three-component model, tug listeners (TugAimListener, TugBodyListener), PhysX layer contract.

Tug Fields API

---

Noise & Impulse

Noise stages perturb the final pose in the Noise phase of the pipeline, autonomous from Body / Aim. Two stages ship: PerlinNoise (continuous handheld / idle shake driven by a .camnoiseprofile asset) and ImpulseNoise (event-triggered ADSR burst). Multiple noise stages compose freely on one cam.

Asset	Purpose
CameraNoiseProfile	.camnoiseprofile — layered Perlin noise definitions for the NoiseStage. Six per-axis layer lists (position xyz, rotation xyz).

Noise Profiles API

---

Orbit Profiles

CameraOrbitShape is a .camorbit asset that defines the shape of an orbital sweep — a power-bulge family that smoothly interpolates between a diamond (Roundness 0), a sphere (Roundness 0.5), and a cube (Roundness 1). Arc-length reparameterization keeps spatial speed constant as the camera traces the shape. Consumed by DynamicOrbitBody.

Asset	Purpose
CameraOrbitShape	.camorbit — power-bulge orbit shape with arc-length reparameterization.

Orbit Profiles API

---

State Inheritance

State inheritance lets the incoming cam in a transition start from a kinematic interpretation of the outgoing cam’s pose, rather than its own ideal. The protocol is universal: every Body stage may publish a CamPoseSnapshot (TryGetPoseSnapshot) and may adopt one (TryAdoptPoseSnapshot). Orbit back-derives yaw / pitch from the snapshot. Track projects to its spline. LeadingFollow seeds at the band-natural distance from the source’s facing.

Inheritance is opt-in per blend entry via the InheritState flag on the matched Blend Profile entry. The default is OFF; enable it only when the smoother handoff is worth the kinematic cost.

State Inheritance API

---

Camera Input Reader

The Camera Input Reader provides yaw / pitch input deltas to Body and Aim stages that drive their pose from player input (notably DynamicOrbitBody). It implements the OrbitInputProvider interface and integrates with PlayerControllerInputReader from gs_unit. It distinguishes sensitivity (raw input scale) from halflife (damping rate) and applies ResetPendingInput semantics so a stage that didn’t tick this frame doesn’t accumulate a stale input buffer.

Component	Purpose
GS_CameraInputReaderComponent	Orbit input provider. Sensitivity and halflife controls. Per-cam pending input drain.

Camera Input Reader API

---

Cross-Gem Contracts

The Cam Core exposes the camera as an observable service through the GS_Core Interfaces layer — the observable-service trio: learn a core exists (Emit), query it (Exchange), observe its updates (Emit):

Contract	Kind	Used for
CamCoreEmissionBus	Emit	UpdateCameraPosition (per-frame pose), OnCamCoreRegistered / OnCamCoreUnregistered (rig lifetime). Global broadcast.
CamCoreExchangeBus	Exchange	GetCamCore — resolve the active Cam Core’s entity.

The internal SetPhantomCam command stays an in-gem bus (Cam Manager → Cam Core), not a cross-gem contract. See the Contract Reference for details.

---

Installation

GS_PhantomCam requires only GS_Core.

1. Enable GS_PhantomCam in Project Manager or project.json.
2. Add GS_CamManagerComponent to a dedicated entity and register it in the Game Manager Startup Managers list. Save this entity as a prefab.
3. Author a rig prefab containing GS_CamCoreComponent on a main O3DE camera entity plus the phantom cameras you want to ship with the rig. Assign this prefab to the Cam Manager’s m_primaryRigPrefab for Tier 2 (single-player) or to m_channelConfigs[i].m_rigPrefab for Tier 3 (per-channel). For Tier 1 / legacy, hand-place the CamCore as a child of the Cam Manager entity instead.
4. Assign a Blend Profile asset to the Cam Core’s Blend Profile slot. Configure default blend time, easing, and shape on the component for fallback transitions.
5. Place phantom camera entities (either in the rig prefab or in the level). Author their Body, Aim, and Additive stages from the type-picker.
6. For spatial influence zones, add CameraInfluenceFieldComponent alongside a PhysX Collider (trigger) to define the volume.
7. For global per-stage influence, add GlobalCameraInfluenceComponent to the StageData entity.
8. For multi-player or split-screen, toggle m_enableInstancedChannels = true on the Cam Manager and populate m_channelConfigs. See Channels & Instancing.

For a full guided walkthrough, see the PhantomCam Set Up Guide.

---

See Also

For conceptual overviews and usage guides:

• The Basics: PhantomCam

For related resources:

• GS_Core API
• Orbital Solver Utility — math primitive used by Spherical / Cylindrical blend shapes and LeadingFollowBody.
• Curves Utility
• Physics Trigger Volume Utility
• GS_Cinematics API

---

Get GS_PhantomCam

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

1 - Cam Manager

The Cam Manager is the singleton controller for the GS_PhantomCam camera system. It extends GS_ManagerComponent and owns the full lifecycle of virtual cameras: per-channel registration of phantom cameras and Cam Cores, per-channel priority arbitration, channel-aware target binding, influence routing, the named Group Target registry, cross-channel cinematic dispatch, and engine main-view selection.

When a phantom camera activates, it walks transform ancestors looking for a ChannelStampComponent, identifies its channel, and self-registers with the Cam Manager. When priorities change — through direct calls, enable/disable toggling, or influence fields — the Cam Manager re-evaluates the affected channel(s) and notifies the channel’s Cam Core to begin blending toward the new winner.

For usage guides and setup examples, see The Basics: GS_PhantomCam.

Contents

• How It Works
• Authoring Tiers
• Channels
• Group Target Registry
• Dispatch Overrides
• Active Main View
• Spawn Lifecycle
• Setup
• API Reference
• Extending the Cam Manager
• See Also

How It Works

Camera Registration

Every Phantom Camera registers with the Cam Manager on activation and unregisters on deactivation. The registration path depends on the cam’s CamChannelScope and whether it lives under a ChannelStampComponent ancestor — see Channels. For legacy / single-player flows (no stamp ancestor), the cam routes through channel 0 via the legacy RegisterPhantomCam method.

Priority Evaluation

When any camera’s priority changes, the Cam Manager calls EvaluatePriority(), which iterates every active channel. Each channel computes effective = base + sum(influences) per cam and picks the highest. A change in a channel’s winner triggers SettingNewCamOnChannel(channelId, targetCam) (when channel instancing is enabled) or the legacy SettingNewCam(targetCam) (when it is not). The channel’s Cam Core listens for this to begin its blend transition.

Camera Influences

Camera influences are named priority modifiers that shift a camera’s effective priority. They are added and removed through AddCameraInfluence(sourceEntity, targetEntity, camName, influence) and RemoveCameraInfluence(sourceEntity, targetEntity). The sourceEntity is the storage key (so multiple overlapping fields don’t collide); the targetEntity is the routing key — the Cam Manager looks up the channel via GetChannelForTarget(targetEntity). Influences whose target isn’t bound to any channel are silently dropped. See Camera Influence Fields.

Target Assignment

Each channel holds its own target binding. SetChannelTarget(channelId, target) sets the target for one channel; the legacy SetTarget(target) forwards to channel 0. Setting a valid target on a channel propagates it to every cam in the channel via SetCameraTarget and pushes a synchronous SnapCameraNow so the cam’s evaluated pose lands before downstream consumers query its transform. Clearing the target (invalid EntityId) does not push snap — this preserves the depossess-guard pose-hold behavior.

Authoring Tiers

The Cam Manager exposes a tiered author surface via progressive disclosure. Three top-level inspector fields control which tier is active:

CameraChannelConfig per-row fields:

Channels

A channel is one player viewpoint slot. Each channel owns its own rig, target binding, priority table, active influence set, and Cam Core. Channel 0 (DefaultChannelId) is the implicit default for legacy / single-player flows.

Channel addressing covers most of the Cam Manager’s runtime surface. The bus exposes paired methods — a legacy single-arg form that forwards to channel 0, and a channel-aware multi-arg form for Tier 3:

Direct registration variants (RegisterPhantomCamDirect, RegisterPhantomCamShared) cover author-explicit CamChannelScope::TrueUnique cams that bypass the stamp-walk path. See Channels & Instancing for the full scope enum and stamp-walk semantics.

Group Target Registry

The Cam Manager is the single global authority for named Group Targets. A GroupTargetComponent self-registers on activate; stages with CamTargetMode::GroupTarget resolve the group’s entity by name.

Dispatch Overrides

For cinematic / cross-channel scenarios — e.g. player 3’s wide cam should temporarily render on player 1’s Cam Core — the Cam Manager exposes a dispatch override. Channel arbitration still runs internally during dispatch (SettingNewCamOnChannel still fires with the arbitrated winner); only the physical Cam Core route is overridden.

Active Main View

Wraps O3DE’s AzFramework::Camera::CameraRequests::MakeActiveView so the channel system can orchestrate which Cam Core is the engine’s main view. Orthogonal to dispatch (what cam) and render-target binding (where pixels go).

Listeners receive OnActiveCameraChanged(channelId, camCoreEntity). External MakeActiveView calls made outside this API are not observed — subscribe to AzFramework::Camera::CameraNotificationBus directly if you need to detect engine-level changes.

Spawn Lifecycle

The Cam Manager’s OnStartupComplete hook (driven by the Game Manager) spawns all configured rigs before broadcasting HandleStartup so spawned cams settle into the same startup wave. Stage transitions (BeginLoadStage / LoadStageComplete) despawn and respawn rigs cleanly.

OnStartupComplete:
  if m_enableInstancedChannels == false:
    Tier 1: if m_primaryRigPrefab valid → spawn one rig for channel 0
    Tier 2: no spawn (assumes level-placed CamCore)
  else:
    Tier 3: iterate m_channelConfigs[0 .. min(size, m_activeChannelCount)]
      for each PerChannelInstance config with valid prefab and m_enabledByDefault:
        SpawnChannelRig(channelId, GetEffectiveRigPrefab(channelId))

SpawnChannelRig uses an EntitySpawnTicket with two callbacks:

1. Pre-insertion — Cam Manager attaches a ChannelStampComponent to the spawn root and calls StampChannel(channelId). This bumps the channel’s stamp token and fires OnStamped to any subscribers.
2. Completion — Entities activate. Cam Cores and PhantomCams walk ancestors, find the stamp, and self-register to the channel via token-aware methods. Cam Manager then walks activated entities into channel.m_rigSpawnedEntities, marks the channel active, folds shared TrueUnique cams into the channel’s priority table, validates a Cam Core registered, broadcasts ChannelSpawned(channelId, camCoreEntity), and re-runs EvaluatePriority so the arbitration result reaches the Cam Core.

Mid-session EnableChannel / DisableChannel reuse the same spawn / despawn paths and fire the same notifications.

Setup

1. Add GS_CamManagerComponent to a dedicated entity (commonly inside a Cam Manager prefab).
2. Register the manager prefab in the Game Manager Startup Managers list.
3. Choose your tier:
   • Tier 1 — Assign a rig prefab (containing a Cam Core entity and your phantom cameras) to m_primaryRigPrefab. Leave m_enableInstancedChannels off.
   • Tier 2 — Place the Cam Core entity as a child of the Cam Manager entity directly. Leave m_primaryRigPrefab empty and m_enableInstancedChannels off.
   • Tier 3 — Toggle m_enableInstancedChannels on and populate m_channelConfigs with one row per supported player slot. Use m_primaryRigPrefab as the universal default and per-row Rig Override Prefab for asymmetric setups.
4. Place or author phantom cameras with priorities, target modes, and stage compositions.

For a full walkthrough, see the PhantomCam Set Up Guide.

API Reference

Request Bus: CamManagerRequestBus

Commands sent to the Cam Manager. Global bus — single address, single handler. Extends GS_Core::ManagerBaseRequests.

Registration

Priority and influence

Targets

Runtime channel management

Dispatch and active view

Group target registry

Notification Bus: CamManagerNotificationBus

Events broadcast by the Cam Manager. Multiple handler bus — any number of components can subscribe. Extends GS_Core::ManagerBaseNotifications.

Legacy (instancing OFF)

Channel-aware (instancing ON)

Virtual Methods

Override these when extending the Cam Manager. Always call the base implementation.

Extending the Cam Manager

Extend the Cam Manager to add custom priority logic, additional registration behavior, or project-specific camera selection rules. Extension is done in C++.

Header (.h)

#pragma once
#include <GS_PhantomCam/GS_CamManagerBus.h>
#include <Source/GS_CamManagerComponent.h>

namespace MyProject
{
    class MyCamManager : public GS_PhantomCam::GS_CamManagerComponent
    {
    public:
        AZ_COMPONENT_DECL(MyCamManager);

        static void Reflect(AZ::ReflectContext* context);

    protected:
        void EvaluatePriority() override;
        AZ::EntityId EvaluatePriorityForChannel(GS_PhantomCam::ChannelId channelId) override;
    };
}

Implementation (.cpp)

#include "MyCamManager.h"
#include <AzCore/Serialization/SerializeContext.h>

namespace MyProject
{
    AZ_COMPONENT_IMPL(MyCamManager, "MyCamManager", "{YOUR-UUID-HERE}");

    void MyCamManager::Reflect(AZ::ReflectContext* context)
    {
        if (auto serializeContext = azrtti_cast<AZ::SerializeContext*>(context))
        {
            serializeContext->Class<MyCamManager, GS_PhantomCam::GS_CamManagerComponent>()
                ->Version(0);

            if (AZ::EditContext* editContext = serializeContext->GetEditContext())
            {
                editContext->Class<MyCamManager>("My Cam Manager", "Custom camera manager")
                    ->ClassElement(AZ::Edit::ClassElements::EditorData, "")
                        ->Attribute(AZ::Edit::Attributes::Category, "MyProject")
                        ->Attribute(AZ::Edit::Attributes::AppearsInAddComponentMenu, AZ_CRC_CE("Game"));
            }
        }
    }

    void MyCamManager::EvaluatePriority()
    {
        // Call base to run standard per-channel arbitration.
        GS_CamManagerComponent::EvaluatePriority();

        // Custom system-wide logic here.
    }

    AZ::EntityId MyCamManager::EvaluatePriorityForChannel(GS_PhantomCam::ChannelId channelId)
    {
        // Apply per-channel rules before falling back to base arbitration.
        // Example: lock to a specific cam during a scripted sequence.
        // if (m_lockedCam.IsValid()) return m_lockedCam;
        return GS_CamManagerComponent::EvaluatePriorityForChannel(channelId);
    }
}

Script Canvas Examples

Enabling and disabling the camera system:

Setting the global camera target:

Reacting to a new dominant camera:

See Also

For related PhantomCam components:

• Cam Core
• Phantom Cameras
• Channels & Instancing
• Blend Profiles
• Camera Influence Fields
• Group Targets

For foundational systems:

• Manager Base Class
• Game Manager

For conceptual overviews and usage guides:

• GS_PhantomCam Overview
• The Basics: Cam Manager

Get GS_PhantomCam

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

1.1 - Channels & Instancing

A channel is one player viewpoint slot. Each channel owns its own rig (spawned from a prefab), its own Cam Core, zero or more Phantom Cameras registered to it, a bound target, and its own priority table. Channel 0 (DefaultChannelId) is the implicit default for all legacy / single-player flows.

The channel system progressively discloses across three authoring tiers — Tier 1 single-cam, Tier 2 single-player rig, Tier 3 multi-channel. The per-cam authoring surface is identical across tiers; only the Cam Manager configuration changes.

Pending — multi-view rendering (I.9b). The channel system architecturally supports per-channel render targets via AttachmentImage assets, but the Atom RPI binding has not landed yet. Until it does, the engine renders one channel at a time even when multiple are arbitrating internally. The active main-view selector decides which channel reaches the engine framebuffer; see Active Main View.

Contents

• Three Authoring Tiers
• ChannelId
• Cam Channel Scope
• ChannelStampComponent
• Rig Prefab Resolution
• Spawn Pipeline
• Stamp-Walk Registration
• Shared Cams and Collapse Detection
• Cross-Channel Dispatch
• Active Main View
• Runtime Channel API
• Notifications
• Tier 3 Author Workflow
• Naming Collision Callout
• See Also

Three Authoring Tiers

The Cam Manager exposes three top-level inspector fields that control the system tier. See Cam Manager — Authoring Tiers for the full author surface.

The Master Gate is m_enableInstancedChannels. When OFF, channel-aware fields are hidden in the inspector and only the legacy bus signatures (SetTarget, SettingNewCam) route through. When ON, the full channel surface is live and channel-aware notifications (SettingNewCamOnChannel) replace the legacy ones.

ChannelId

using ChannelId = AZ::u32;
static constexpr ChannelId InvalidChannelId = static_cast<ChannelId>(-1);
static constexpr ChannelId DefaultChannelId = 0;

Channel ids are integers (0 … max − 1). The default channel id is 0. Legacy single-arg bus calls (SetTarget(target), RegisterPhantomCam(cam)) forward to channel 0.

Logical cam names — the entity names of phantom cameras inside a rig prefab — are scoped within their channel. The same name can appear in all four channels’ rigs without collision. Authors never type _i1 / _i2 suffixes.

Cam Channel Scope

Each Phantom Camera authors a CamChannelScope that decides how it participates in the channel system:

enum class CamChannelScope : AZ::u8 {
    Local       = 0,  // Default. Lives in its owning channel's scope.
    AllChannels = 1,  // In-rig natural duplicate — every rig instance carries one.
    TrueUnique  = 2,  // Exactly one instance total; bound or shared.
};

TrueUnique sub-fields (visible only when scope is TrueUnique):

Author recipes:

• Cam inside a rig prefab — leave as Local.
• Per-player tailored broadcast cam in the level — AllChannels (in-rig); deferred for out-of-rig.
• Hero-perspective cam for a specific player — TrueUnique + m_boundChannelId = N.
• Shared cinematic collapse cam — TrueUnique + advanced + m_allChannelsShare = true. Pair with a Group Target to trigger OnAllChannelsActivatedSharedCam.

ChannelStampComponent

Pure runtime plumbing. Marks an entity (typically a rig root) with a (ChannelId, stampToken) pair. Phantom Camera and Cam Core components walk transform ancestors looking for this stamp at activate time to determine which channel they belong to.

Authored visibility: none. The stamp is reflected for serialization only — no EditContext block. The author never sees or sets it; the Cam Manager auto-attaches one during the spawn pre-insertion callback and calls StampChannel(channelId) to bump the token.

Why the token

m_stampToken bumps on every StampChannel(id) call (including idempotent re-stamps). The Cam Manager validates the supplied (channelId, token) against the live stamp on every registration call — mismatched tokens are rejected with a warning. This prevents stale messages from a previous stamp generation overwriting fresh bindings.

Buses

Static helper

static AZ::EntityId ChannelStampComponent::FindStampAncestor(AZ::EntityId start);

Walks transform ancestors via the request bus and returns the closest stamped entity (or invalid id if no stamp ancestor).

Rig Prefab Resolution

Three inspector fields on the Cam Manager control where each channel’s rig comes from:

The Cam Manager’s GetEffectiveRigPrefab(channelId) returns:

1. m_channelConfigs[channelId].m_rigPrefab if set.
2. Else m_primaryRigPrefab.
3. Else invalid (the channel emits a warning at spawn time and stays inert).

Symmetric multi-channel co-op (all players use the same rig) sets the primary once; every channel inherits. Asymmetric setups (e.g. P1 third-person, P2 top-down) set per-channel overrides.

Spawn Pipeline

The Cam Manager spawns configured rigs on startup (driven by OnStartupComplete) and re-spawns them on stage transitions.

OnStartupComplete:
  if m_enableInstancedChannels == false:
    Tier 1: m_primaryRigPrefab valid → SpawnChannelRig(DefaultChannelId, m_primaryRigPrefab)
    Tier 2: no spawn (assumes level-placed CamCore)
  else:
    Tier 3: iterate m_channelConfigs[0 .. min(size, m_activeChannelCount)]
      for each PerChannelInstance config with m_enabledByDefault and valid prefab:
        SpawnChannelRig(channelId, GetEffectiveRigPrefab(channelId))

SpawnChannelRig uses an EntitySpawnTicket with two callbacks:

1. Pre-insertion callback (entities created, not yet activated):
   • Cam Manager identifies the spawn root (first entity in the spawn container).
   • Attaches a ChannelStampComponent to it.
   • Calls StampChannel(channelId) — bumps the token, fires OnStamped to any subscribers.
2. Completion callback (entities activated):
   • Cam Manager walks activated entities into channel.m_rigSpawnedEntities.
   • Marks the channel m_active = true.
   • Folds any TrueUnique-shared cams into the new channel’s priority table.
   • Validates that a Cam Core registered (warns if not).
   • Broadcasts ChannelSpawned(channelId, camCoreEntity).
   • Re-runs EvaluatePriority(channelId) so the channel’s arbitration result reaches its Cam Core.

Stage transitions

BeginLoadStage    → DespawnAllChannelRigs (lock arbitration first)
LoadStageComplete → SpawnAllConfiguredRigs BEFORE broadcasting HandleStartup
                    so fresh-stage cams come up in the startup wave.

Stamp-Walk Registration

When a Phantom Camera (or Cam Core) activates, it walks ancestors for a ChannelStampComponent and branches:

RegisterWithCamManager:
   branch on m_channelScope (PhantomCam only — CamCore is always Local-equivalent):

   ┌── Local:
   │      stamp = FindStampAncestor(myEntity)
   │      if stamp valid:
   │         RegisterPhantomCamForChannel(myEntity, stamp, channelId, token)
   │         registrationMode = StampAware
   │      else:
   │         RegisterPhantomCam(myEntity)             // legacy channel 0
   │         registrationMode = LegacyChan0
   │
   ├── AllChannels:
   │      stamp = FindStampAncestor(myEntity)
   │      if stamp valid:
   │         RegisterPhantomCamForChannel(myEntity, stamp, channelId, token)
   │         registrationMode = StampAware
   │      else:
   │         warn (out-of-rig cloning deferred)
   │         fall back to legacy channel 0
   │         registrationMode = LegacyChan0
   │
   └── TrueUnique:
          if m_boundChannelId valid AND !m_allChannelsShare:
             RegisterPhantomCamDirect(myEntity, m_boundChannelId)
             registrationMode = Direct
          elif !m_boundChannelId AND m_allChannelsShare:
             RegisterPhantomCamShared(myEntity)
             registrationMode = (Shared, stored as Direct for unregister routing)
          else:
             warn (fragile manual-control mode)
             stay unregistered
             registrationMode = None

registrationMode is cached on the component so UnregisterFromCamManager can route symmetrically.

OnStamped — mid-session re-stamp handling

If a rig is re-stamped mid-session (rare; typically only during stage transitions or hot-reload), the cam handles it:

OnStamped(newChannelId, newToken):
   Only acts in StampAware or None modes.
   In Direct or LegacyChan0 modes, the signal is ignored — author intent
   takes precedence over stamps.

   UnregisterFromCamManager (old binding)
   m_resolvedChannelId  = newChannelId
   m_resolvedStampToken = newToken
   RegisterWithCamManager (new binding)

The Cam Core mirrors the same pattern.

Shared Cams and Collapse Detection

RegisterPhantomCamShared(cam) adds the cam to every active channel’s priority table. The Cam Manager tracks the list in m_sharedCams. A shared cam:

• Wins arbitration in every channel where it has the highest priority.
• Gains focus from any channel selecting it.
• Never DROPS focus via channel notifications — a shared cam losing in channel N doesn’t preclude winning in channel M.

Collapse detection

EvaluatePriority collects per-channel winners. If every active channel picked the same cam AND that cam is in m_sharedCams, the Cam Manager edge-triggers OnAllChannelsActivatedSharedCam(sharedCam) via m_lastSharedCollapsedCam — fires once on entry into the condition, and once on cam-A → cam-B shared-cam transitions.

Typical use case: a shared cinematic cam paired with a Group Target tracking all players. When players converge such that the shared cam wins in every channel, UI receives the collapse signal and can switch from split-screen layout to single-view layout.

No counterpart “uncollapsed” event exists — listeners dedupe locally if they care about exit.

Cross-Channel Dispatch

For cinematic / cross-channel scenarios — e.g. player 3’s wide cam should temporarily render on player 1’s Cam Core — the Cam Manager exposes a dispatch override.

Channel arbitration still runs internally during dispatch. SettingNewCamOnChannel continues to fire with the arbitrated winner — only the physical Cam Core route is overridden. This means downstream listeners still see what “would have” arbitrated, useful for HUD or AI behavior that shouldn’t follow the cinematic override.

Active Main View

Wraps O3DE’s AzFramework::Camera::CameraRequests::MakeActiveView so the channel system can orchestrate “this player’s view is on main right now” without callers reaching into camera bus plumbing. Orthogonal to dispatch (what cam) and render-target binding (where pixels go).

Listeners receive OnActiveCameraChanged(channelId, camCoreEntity). channelId == InvalidChannelId when the active cam isn’t channel-bound (e.g. a direct SetActiveCamCore to an external entity). External MakeActiveView calls made outside this API are not observed — subscribe to AzFramework::Camera::CameraNotificationBus directly if you need to detect engine-level changes.

Runtime Channel API

Intended lobby flow: author sets m_channelConfigs to N (primed max), pre-startup the lobby calls SetActiveChannelCount(actualPlayerCount), then OnStartupComplete spawns just actualPlayerCount rigs. Mid-session join / drop uses EnableChannel / DisableChannel.

Notifications

Channel-related events on CamManagerNotificationBus. See Cam Manager — Notifications for the full notification surface.

Tier 3 Author Workflow

1. On the Cam Manager: toggle m_enableInstancedChannels = true.
2. Set m_primaryRigPrefab to the project’s default rig (used as universal fallback).
3. Populate m_channelConfigs with one entry per supported player slot:
   • Set m_channelName for inspector readability (“P1”, “P2”, …).
   • Optionally set m_rigPrefab (the “Rig Override Prefab”) — leave empty to inherit the primary.
   • Set m_enabledByDefault = true for slots that should spawn on startup.
4. Optionally set m_activeChannelCount for the lobby cap, or call SetActiveChannelCount at runtime before startup.
5. Per-player cams placed inside the rig prefab will auto-stamp on spawn — no per-cam authoring required for normal Local-scope cams.
6. For shared cinematic cams (one cam to rule them all), set the cam’s m_channelScope = TrueUnique + m_showAdvanced = true + m_allChannelsShare = true.
7. For author-explicit per-channel cams (rare), use m_channelScope = TrueUnique + m_boundChannelId = N + m_allChannelsShare = false.

For the basics-side walkthrough with screenshots and step-by-step recipes, see The Basics: Channels & Instancing.

Naming Collision Callout

Tug-field m_channels ≠ instancing ChannelId. Tug-field channels are arbitrary string tags (“Cinematic”, “Combat”) that match tug volumes to listeners — see Tug Fields. Instancing channels documented on this page are integer ChannelIds for per-player viewpoint routing. The two systems are unrelated despite the shared word. The system uses the same identifier name in the codebase for both; the docs make the distinction prominent here and in the tug-fields page.

See Also

For related PhantomCam pages:

• Cam Manager — the owning component.
• Phantom Cameras — CamChannelScope is authored on each cam.
• Cam Core — one Cam Core per channel.
• Group Targets — pair with shared TrueUnique cams for collapse-to-single-view scenarios.
• Tug Fields — note the channel naming disambiguation above.

For the basics-side walkthrough:

• The Basics: Channels & Instancing

Get GS_PhantomCam

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

2 - Cam Core

The Cam Core is the runtime driver of the GS_PhantomCam system. It lives on a camera entity (the main O3DE camera entity for single-player, or a per-channel Cam Core entity for multi-channel projects) and is responsible for one job: making the engine’s camera match the dominant Phantom Camera for its channel. Every frame, the Cam Core reads the target phantom camera’s position, rotation, and field of view, then applies those values to the actual camera entity — either instantly (when locked) or through a timed blend transition.

When the Cam Manager determines a new dominant phantom camera for the Cam Core’s channel, it fires a per-channel notification and routes the new cam to the Cam Core via SetPhantomCam. The Cam Core then looks up the best matching blend in the active Blend Profile, optionally inherits state from the outgoing cam, and begins interpolating toward the new phantom camera over the specified duration, easing curve, and blend shape. If a new transition starts before the current blend completes, a small correction window pulls the new blend back from the rendered TM so the cam does not snap. Once a blend completes, the main camera locks to the phantom camera as a child entity, matching its transforms exactly until the next transition.

For usage guides and setup examples, see The Basics: GS_PhantomCam.

Contents

• How It Works
• Blend Shape and Pivot
• State Inheritance Handoff
• Interrupt Correction
• Channel Addressing
• Setup
• API Reference
• Usage Examples
• Extending the Cam Core
• See Also

How It Works

Blend Transitions

When a camera transition is triggered:

1. The Cam Core receives SetPhantomCam(targetCam) from the Cam Manager, routed to its own entity address.
2. It queries the assigned Blend Profile for the best matching blend entry between the outgoing and incoming cameras (by entity name).
3. The matched entry returns duration, easing curve, blend shape (Linear / Spherical / Cylindrical), an inherit-state flag, and a pivot source. If no entry matches, the Cam Core falls back to its own defaults.
4. If the entry’s inherit-state is set, the state inheritance handoff runs before the blend starts so the destination cam’s body adopts a kinematic interpretation of the outgoing cam’s pose.
5. The outgoing cam’s m_blendingOut flag is set so it continues ticking through the transition (keeps the source pose live if the target is moving).
6. Over the blend duration, the Cam Core interpolates position (using the chosen shape), rotation (slerp), and lens (FOV / near / far) from the outgoing state to the incoming state.
7. If a new blend interrupts this one, the interrupt correction window pulls the new start curve back so the cam doesn’t snap.
8. On completion, the Cam Core parents the main camera to the new dominant phantom, locking them together until the next transition.

Blend Profile Resolution

The Cam Core holds a reference to a GS_PhantomCamBlendProfile asset. When a transition occurs, it calls GetBestBlend(fromCam, toCam) on the profile to find the most specific matching entry. Resolution order:

1. Exact match — From camera name to To camera name.
2. Any-to-specific — “Any” to the To camera name.
3. Specific-to-any — From camera name to “Any”.
4. Default fallback — The Cam Core’s own default blend time, easing, and shape.

See Blend Profiles for full details.

Camera Locking

Once a blend completes, the main camera becomes a child of the dominant phantom camera entity. All position, rotation, and property updates from the phantom camera are reflected immediately on the real camera. This lock persists until the next transition begins.

Blend Shape and Pivot

Each blend entry specifies a shape that controls how position interpolates:

The pivot point is resolved by the entry’s pivot source:

Cams publish their pivot as the pivotPos field on CamPoseSnapshot (see State Inheritance). Stages that don’t publish a pivot disqualify themselves from being the pivot source.

The math is implemented by the Orbital Solver Utility in GS_Core — BlendPositionAroundPivot(from, to, pivot, alpha, shape, axis).

State Inheritance Handoff

When a blend entry has m_inheritState = true, the Cam Core runs a handoff between the outgoing and incoming cams before starting the blend:

1. Pull a CamPoseSnapshot from the outgoing cam via PhantomCameraRequests::TryGetPoseSnapshot.
2. If the snapshot is valid, push it to the incoming cam via PhantomCameraRequests::TryAdoptPoseSnapshot.

The Get / Adopt calls forward to the cam’s Body stage. Bodies that don’t implement the protocol return false; the handoff is a silent no-op and the blend proceeds normally.

The handoff runs before StartBlend, so by the time the blend captures source and destination poses, the destination cam’s body has already adopted the seed pose. This makes inherited blends feel like a continuation of the outgoing cam’s motion rather than a clean start.

See State Inheritance for the full protocol and per-stage adoption semantics.

Interrupt Correction

When a blend A → B is in flight and a new blend A’ → C kicks off, snapping the cam’s source TM produces a perceptible velocity jolt — the cam visibly changes direction at the interrupt moment. The Cam Core’s mid-blend correction window prevents this.

Mechanism

1. Capture the cam’s currently-rendered TM at the interrupt moment → m_interruptSnapshotTM.
2. Compute T_natural = 1 - oldBlendFactor — the curve point on the new blend at which the cam’s velocity matches its current motion.
3. Compute T_start = max(0, T_natural − m_interruptCorrection) — pull the new blend back by the correction window.
4. Seed the new blend at curve point T_start.
5. Over the window [T_start, T_natural], the rendered pose is a Y-blend between the snapshot and the new blend’s natural pose, with the Y factor sweeping 0 → 1.
6. After T_natural, the Y-blend yields fully to the new blend; pure new-blend interpolation continues with live source / destination TMs.

The cam starts in the snapshot pose at the interrupt, ramps gracefully into the new trajectory across the correction window, and proceeds normally.

Window width

m_interruptCorrection is authored on the Cam Core, default 0.03 (3% of the new blend’s curve). Larger windows feel smoother but produce more visible lag in the handoff territory; smaller windows feel snappier but reintroduce the velocity jolt. Setting it to 0 degenerates to legacy hard-anchor behavior.

Channel Addressing

The Cam Core self-registers with the Cam Manager on activate. It walks transform ancestors looking for a ChannelStampComponent to determine its channel:

• Stamp found — Registers via RegisterCamCoreToChannel(camCore, stampEntity, channelId, token). Listens at its own entity address on CamCoreRequestBus so the Cam Manager can route per-channel SetPhantomCam calls.
• No stamp — Registers via the legacy RegisterCamCore. Routes through channel 0 in single-player projects.

If the Cam Core’s parent rig is re-stamped (rare; typically during stage transitions or hot-reload), the ChannelStampNotificationBus::OnStamped handler un-registers from the old channel and re-registers to the new one. The Cam Manager’s token validation rejects mismatched stamp tokens to prevent stale messages from overwriting fresh bindings.

One Cam Core per channel. Multi-channel projects (Tier 3) spawn one per active channel; single-player projects use a single Cam Core at channel 0.

Setup

1. Add GS_CamCoreComponent to a camera entity. For Tier 1 / Tier 2 (single-player), this is the main O3DE camera entity, parented under the Cam Manager entity. For Tier 3 (multi-channel), include one Cam Core per rig inside the rig prefab.
2. Create a Blend Profile data asset in the Asset Editor and assign it to the Cam Core’s Blend Profile slot.
3. Configure default blend time, easing, and blend shape on the Cam Core for cases where no profile entry matches. See Curves Utility for available easing types.
4. Optionally adjust Interrupt Correction (default 0.03) if your project has unusually short or long blends.

API Reference

Request Bus: CamCoreRequestBus

Internal command bus, Cam Manager → Cam Core. Per-entity — each Cam Core listens at its own entity id so the Cam Manager can route per-channel events; Broadcast hits every connected Cam Core (stage-transition global clear). This is not a cross-gem contract and is not script-reflected — external systems observe the camera through the two GS_Core contracts below.

Cross-Gem Contract: CamCoreExchangeBus

The query half of the camera’s observable-service trio, housed in GS_Core. Addressed by the Cam Core’s EntityId; single provider.

Cross-Gem Contract: CamCoreEmissionBus

The emit half of the trio, housed in GS_Core. Global broadcast, multiple handlers — any number of components can subscribe without depending on GS_PhantomCam. Was CamCoreNotificationBus before the interfaces migration; the ScriptCanvas-facing name is preserved by GS_PhantomCam’s binder, so existing graphs keep resolving.

Inspector Fields

Usage Examples

C++ — Querying the Main Camera Entity

#include <GS_Core/Interfaces/Camera/CamCoreExchangeBus.h>

AZ::EntityId mainCameraId;
GS_Core::CamCoreExchangeBus::BroadcastResult(
    mainCameraId,
    &GS_Core::CamCoreExchange::GetCamCore);

For a multi-channel project, query the Cam Manager for a specific channel’s Cam Core instead:

#include <GS_PhantomCam/GS_CamManagerBus.h>

AZ::EntityId p1CamCore;
GS_PhantomCam::CamManagerRequestBus::BroadcastResult(
    p1CamCore,
    &GS_PhantomCam::CamManagerRequests::GetChannelCamCore,
    GS_PhantomCam::ChannelId(0));

C++ — Listening for Camera Updates

#include <GS_Core/Interfaces/Camera/CamCoreEmissionBus.h>

class MyCameraListener
    : public AZ::Component
    , protected GS_Core::CamCoreEmissionBus::Handler
{
protected:
    void Activate() override
    {
        GS_Core::CamCoreEmissionBus::Handler::BusConnect();
    }

    void Deactivate() override
    {
        GS_Core::CamCoreEmissionBus::Handler::BusDisconnect();
    }

    void UpdateCameraPosition(
        const AZ::Vector3& camPos,
        const AZ::Vector3& camFacing,
        float deltaTime) override
    {
        // React to per-tick camera position / facing changes.
    }
};

Script Canvas

Reacting to camera position updates:

Extending the Cam Core

The Cam Core can be extended in C++ to customize blend behavior, add post-processing logic, or integrate with external camera systems.

Header (.h)

#pragma once
#include <GS_PhantomCam/Core/GS_CamCoreBus.h>
#include <Source/Core/GS_CamCoreComponent.h>

namespace MyProject
{
    class MyCamCore : public GS_PhantomCam::GS_CamCoreComponent
    {
    public:
        AZ_COMPONENT_DECL(MyCamCore);

        static void Reflect(AZ::ReflectContext* context);
    };
}

Implementation (.cpp)

#include "MyCamCore.h"
#include <AzCore/Serialization/SerializeContext.h>

namespace MyProject
{
    AZ_COMPONENT_IMPL(MyCamCore, "MyCamCore", "{YOUR-UUID-HERE}");

    void MyCamCore::Reflect(AZ::ReflectContext* context)
    {
        if (auto serializeContext = azrtti_cast<AZ::SerializeContext*>(context))
        {
            serializeContext->Class<MyCamCore, GS_PhantomCam::GS_CamCoreComponent>()
                ->Version(0);

            if (AZ::EditContext* editContext = serializeContext->GetEditContext())
            {
                editContext->Class<MyCamCore>("My Cam Core", "Custom camera core driver")
                    ->ClassElement(AZ::Edit::ClassElements::EditorData, "")
                        ->Attribute(AZ::Edit::Attributes::Category, "MyProject")
                        ->Attribute(AZ::Edit::Attributes::AppearsInAddComponentMenu, AZ_CRC_CE("Game"));
            }
        }
    }
}

See Also

For related PhantomCam components:

• Cam Manager
• Phantom Cameras
• Blend Profiles
• State Inheritance
• Channels & Instancing

For utilities used by the blend math:

• Orbital Solver Utility
• Curves Utility

For conceptual overviews and usage guides:

• GS_PhantomCam Overview
• The Basics: Cam Core

Get GS_PhantomCam

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

2.1 - Blend Profiles

Blend Profiles are data assets that control how the Cam Core transitions between Phantom Cameras. Each profile contains a list of blend entries. Each entry defines a From camera, a To camera, a blend duration, an easing curve, a blend shape, a pivot source, and an inherit-state flag. This allows every camera-to-camera transition in your project to have unique timing, feel, and geometry.

The GS_PhantomCamBlendProfile asset is authored in the Asset Editor as a .camblendprofile file. It is registered at startup by PhantomCamDataAssetsSystemComponent and assigned to the Cam Core component. When a camera transition occurs, the Cam Core queries the profile for the best matching blend entry.

For usage guides and setup examples, see The Basics: GS_PhantomCam.

Contents

• How It Works
• Blend Shape
• Pivot Source
• Inherit State
• Data Model
• API Reference
• Creating a Blend Profile
• See Also

How It Works

Blend Entries

Each entry in a Blend Profile defines a single transition rule:

• From Camera — The name of the outgoing camera (the entity name of the phantom camera being left).
• To Camera — The name of the incoming camera (the entity name of the phantom camera being transitioned to).
• Blend Time — The duration of the transition in seconds.
• Blend Type — The interpolation curve applied during the blend. See Curves Utility for the full list.
• Blend Shape — Linear, Cylindrical, or Spherical. See Blend Shape.
• Pivot Source — Source, Destination, or Shared. See Pivot Source. Only consulted when blend shape is not Linear.
• Inherit State — Opt-in cam-to-cam pose handoff. See Inherit State.

Camera names correspond to the entity names of your phantom camera entities in the scene.

Best Target Blend

When the Cam Core needs to transition, it calls GetBestBlend(fromCam, toCam) on the assigned Blend Profile. The system evaluates blend entries in order of specificity:

1. Exact match — An entry with both the From and To camera names matching exactly.
2. Any-to-specific — An entry with From set to blank or “any” and To matching the incoming camera name.
3. Specific-to-any — An entry with From matching the outgoing camera name and To set to blank or “any”.
4. Default fallback — If no entry matches, the Cam Core uses its own default blend time, easing, and shape configured on the component.

This layered resolution allows you to define broad defaults (“any” to “any” at 1.0 seconds) while overriding specific transitions (“MenuCam” to “GameplayCam” at 2.5 seconds with ease-in-out and a spherical sweep).

The first match within a specificity tier wins (no further tie-breaking).

Blend Shape

The blend shape controls how the camera’s position interpolates between source and destination. Defaults to Linear so unconfigured / pre-v3 assets retain straight-lerp behavior.

When the shape is not Linear, the Cam Core calls the Orbital Solver Utility — BlendPositionAroundPivot(from, to, pivot, alpha, shape, axis) — to compute each tick’s position.

Auto-fallback to Linear. When neither cam reports a pivot (e.g. environmental cams without follow / lookAt targets), the orbital solver isn’t called and the blend lerps straight regardless of the authored shape.

Rotation always slerps; the shape only affects position.

Pivot Source

The pivot is the world-space point that Cylindrical / Spherical shapes arc around. It is resolved at blend start from the cams’ pivots. The pivot source selects which cam’s pivot to use:

Pivots come from the cams’ bodies via GetCameraPivot. A cam that doesn’t publish a pivot disqualifies itself from being the pivot source; Cam Core falls back to whichever cam does publish one, or to Linear if neither does.

This field is ignored when Blend Shape is Linear.

Inherit State

Setting Inherit State opts the matched pair into the state inheritance protocol. When the Cam Core is about to start this blend, it:

1. Calls TryGetPoseSnapshot on the outgoing cam — the body publishes a CamPoseSnapshot.
2. Calls TryAdoptPoseSnapshot on the incoming cam — the body consumes the snapshot, re-deriving its internal kinematic state to start from a continuation of the outgoing pose.
3. Bodies that don’t speak the protocol silently no-op and the blend proceeds without inheritance.

The blend then runs from the source cam’s pose to the destination cam’s already-inherited pose — reads as a small smooth drift rather than a swing.

Default is false so cinematic shots authored at specific poses land at those poses unless the author opts in.

Authoring gotcha. If the inherit flag is unchecked on a matched pair, the destination cam falls through to its snap-on-activation seed. For a LeadingFollowBody this looks like “cam orients behind player’s travel direction regardless of source facing.” For DynamicOrbitBody or OrbitBody the cam swings to authored yaw / pitch and blends from there. Both symptoms point at the same root cause — verify the flag in the asset.

Data Model

GS_PhantomCamBlendProfile

The top-level asset class. Extends AZ::Data::AssetData. Registered through PhantomCamDataAssetsSystemComponent. Authored as .camblendprofile.

PhantomBlend

A single blend entry within the profile. Reflected at Version 4 with a version converter that defaults Blend Shape / Pivot Source to Linear / Shared (pre-v3 assets) and Inherit State to false (pre-v4 assets).

API Reference

GS_PhantomCamBlendProfile Methods

Creating a Blend Profile

1. Open the Asset Editor in O3DE.
2. Select New and choose GS_PhantomCamBlendProfile from the asset type list.
3. Add blend entries using the + button on the Blend List array.
4. For each entry:
   • Set the From Camera name (or leave blank for “any”).
   • Set the To Camera name (or leave blank for “any”).
   • Set the Blend Time in seconds.
   • Choose a Blend Type (easing curve) from the dropdown.
   • Choose a Blend Shape (Linear / Cylindrical / Spherical).
   • Choose a Pivot Source (Source / Destination / Shared) — ignored when Blend Shape is Linear.
   • Tick Inherit State if you want the incoming cam’s body to seed from the outgoing cam’s pose.
5. Save the asset.
6. Assign the asset to the Cam Core component’s Blend Profile inspector slot.

For a full walkthrough, see the PhantomCam Set Up Guide.

See Also

For related PhantomCam components:

• Cam Core
• Cam Manager
• Phantom Cameras
• State Inheritance

For related utilities:

• Orbital Solver Utility — the math primitive used by Cylindrical / Spherical shapes.
• Curves Utility

For conceptual overviews and usage guides:

• GS_PhantomCam Overview
• The Basics: Blend Profiles

Get GS_PhantomCam

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

2.2 - State Inheritance

State inheritance is a universal pose-handoff protocol: when the Cam Core transitions cam A → cam B, the matched Blend Profile entry may opt into inheritance via the InheritState flag. The outgoing cam publishes a CamPoseSnapshot; the incoming cam consumes it through its own kinematic model. The blend then reads as a small smooth drift instead of a swing.

Inheritance is body-only by design. Aim and additive stages don’t participate — the destination cam’s aim runs fresh on the inherited body pose.

Contents

• The CamPoseSnapshot Trait
• Opting In — The Blend Profile Toggle
• The IBodyStage Virtuals
• Cam Core Handoff Site
• Per-Variant Implementations
• The consumedAdoption Gate
• Authoring Gotcha — Matched but Not Inheriting
• Adoption Coverage Matrix
• See Also

The CamPoseSnapshot Trait

Universal pose-handoff struct. Runtime only — not serialized.

struct CamPoseSnapshot
{
    // Universal — every cam can produce this from its committed transform.
    AZ::Vector3  worldPos = Vector3::Zero();
    AZ::Vector3  worldFwd = Vector3::AxisY();

    // Source cam's resolved pivot in world space at the time of Get.
    // Orbit-style adopters use this to back-derive angular state in the
    // SOURCE cam's frame — preserves orientation even when the incoming
    // cam resolves a different pivot.
    AZ::Vector3  pivotPos      = Vector3::Zero();
    bool         pivotPosValid = false;

    AZ::EntityId pivotEntity;

    // Orbit-specific authored angular state. Populated by orbit-style Get
    // implementations; consumed by orbit-style Adopters directly, bypassing
    // back-derivation. Preserves A's exact yaw / pitch on B across different
    // orbit shapes — angular continuity wins over spatial back-fit.
    float        yawRad             = 0.0f;
    float        pitchRad           = 0.0f;
    bool         angularStateValid  = false;

    // Producer signal — set by TryGetPoseSnapshot when the snapshot is usable.
    bool         valid = false;

    static void Reflect(AZ::ReflectContext* context);
};

A snapshot may carry partial information. worldPos + worldFwd are always populated when valid is true. pivotPos is populated by bodies that publish a pivot (orbit-style, lead-follow). angularStateValid is set only by orbit-style bodies that publish authored yaw / pitch directly.

Opting In — The Blend Profile Toggle

Authored per-pair on PhantomBlend entries inside a .camblendprofile:

struct PhantomBlend {
    // ... other fields ...
    bool m_inheritState = false;
};

Default false so cinematic shots authored at specific poses land at those poses unless the author opts in. See Blend Profiles — Inherit State for the authoring surface.

The IBodyStage Virtuals

class IBodyStage {
public:
    // ... other interface ...

    // Default returns false — stage doesn't speak the protocol.
    virtual bool TryGetPoseSnapshot(CamPoseSnapshot& out)        const { return false; }
    virtual bool TryAdoptPoseSnapshot(const CamPoseSnapshot& in)       { return false; }
};

A body stage may implement only one side of the protocol. Static-shot bodies (OrbitBody) implement Get but leave Adopt at default false — their authored angles define their identity. Other body stages typically implement both.

Forwarders on the Phantom Camera

The component forwards both calls to the body slot:

bool GS_PhantomCameraComponent::TryGetPoseSnapshot(CamPoseSnapshot& out) const {
    if (IBodyStage* body = GetBody()) {
        return body->TryGetPoseSnapshot(out);
    }
    return false;
}

bool GS_PhantomCameraComponent::TryAdoptPoseSnapshot(const CamPoseSnapshot& in) {
    if (IBodyStage* body = GetBody()) {
        return body->TryAdoptPoseSnapshot(in);
    }
    return false;
}

Exposed on PhantomCameraRequestBus so the Cam Core can address cams uniformly.

Cam Core Handoff Site

Inside SetPhantomCam, after lastCam / currentCam are determined and before StartBlend:

const bool wantInherit = (bestBlend && bestBlend->m_inheritState
                          && lastCam.IsValid() && currentCam.IsValid());

if (wantInherit)
{
    CamPoseSnapshot snap;
    bool gotPose = false;
    PhantomCameraRequestBus::EventResult(gotPose, lastCam,
        &PhantomCameraRequests::TryGetPoseSnapshot, snap);

    if (gotPose && snap.valid)
    {
        bool adopted = false;
        PhantomCameraRequestBus::EventResult(adopted, currentCam,
            &PhantomCameraRequests::TryAdoptPoseSnapshot, snap);
        (void)adopted;
    }
}

// ... then StartBlend.

The handoff runs before StartBlend, so by the time the blend captures source and destination poses, the destination cam’s body has already adopted the seed pose. The blend then interpolates from the source’s literal position to the destination’s already-inherited pose.

Bodies that don’t speak the protocol (or that reject the inbound pose) return false; the handoff is silent and the blend proceeds normally.

Per-Variant Implementations

DefaultFollowBody

Inheritance into a Default Follow falls through to the Blend Profile’s visual bridge.

OrbitBody (Get-only)

DynamicOrbitBody (full Get + Adopt)

Get:

out.worldPos          = m_idealPosition;
out.worldFwd          = (m_lastResolvedPivot - m_idealPosition).GetNormalizedSafe();
out.pivotPos          = m_lastResolvedPivot;
out.pivotPosValid     = true;
out.pivotEntity       = m_lastResolvedPivotEntity;
out.yawRad            = m_targetYaw;
out.pitchRad          = m_targetPitch;
out.angularStateValid = true;
out.valid             = true;
return true;

Requires a committed pose AND a cached pivot. First-tick adopters that haven’t ticked yet return false.

Adopt stashes the snapshot. The actual derivation happens in the next Evaluate where pivot resolution has run:

if (m_hasPendingAdoption && m_orbitShape.Get())
{
    if (m_pendingAdoption.angularStateValid)
    {
        // ANGULAR mode (preferred). Inherit raw yaw / pitch directly.
        m_targetYaw   = WrapYawToPi(
            ShortestYawTarget(m_targetYaw, m_pendingAdoption.yawRad));
        m_targetPitch = AZ::GetClamp(m_pendingAdoption.pitchRad,
                                     CameraOrbitShape::kPitchAtLow,
                                     CameraOrbitShape::kPitchAtHigh);
    }
    else
    {
        // POSITION mode (fallback). Back-derive yaw from worldPos.
        const AZ::Vector3 referencePivot = m_pendingAdoption.pivotPosValid
            ? m_pendingAdoption.pivotPos
            : pivot;
        const AZ::Vector3 off = m_pendingAdoption.worldPos - referencePivot;

        const float yawObserved    = std::atan2(off.GetY(), off.GetX());
        const float radiusObserved = std::sqrt(off.GetX()*off.GetX() + off.GetY()*off.GetY());
        const float heightObserved = off.GetZ();

        m_targetYaw   = WrapYawToPi(ShortestYawTarget(m_targetYaw, yawObserved));
        m_targetPitch = FindPitchOnShape(*m_orbitShape.Get(), radiusObserved, heightObserved);
    }

    m_idealPosition       = m_pendingAdoption.worldPos;   // seed at adopted pose
    m_hasIdeal            = true;
    consumedAdoption      = true;
    m_hasPendingAdoption  = false;
}

The ANGULAR path is preferred — it preserves authored angular state across different orbit shape assets, which the position back-derivation cannot. The POSITION path is the safety net for source bodies that don’t publish angular state.

LeadingFollowBody (facing-seeded standoff)

Get returns m_idealPosition, world-forward toward cached target, pivotPos = m_lastTargetPoint. No angular state — lead-follow has no degree of freedom other than position-in-band.

Adopt stashes the snapshot. The consume block in Evaluate reads source worldFwd, flattens to the XY plane, and seeds the cam at band-natural standoff distance:

AZ::Vector3 inboundFwd = m_pendingAdoption.worldFwd;
inboundFwd.SetZ(0.0f);
inboundFwd = inboundFwd.GetNormalizedSafe();
if (inboundFwd.GetLengthSq() < epsilon)
    inboundFwd = GetHorizontalForward(stageTargetTM);   // fallback

const float seedDist = AZ::Lerp(m_innerRadius, m_outerRadius, 0.6f);
m_idealPosition = targetPoint - inboundFwd * seedDist;

m_hasIdeal           = true;
m_idleTimer          = 0.0f;
m_hasLastTarget      = true;
consumedAdoption     = true;
m_hasPendingAdoption = false;

Why facing-seeded, not position-seeded? Lead-follow is heading-agnostic. Seeding with the source’s literal worldPos would lock the cam at an off-band angle, defeating the body’s authored intent. The cam inherits the source’s facing at this body’s preferred standoff. Z naturally lands at targetPoint.Z (inboundFwd is XY-flattened) — a from-below source produces a band-natural pose, not stuck-below framing.

TrackBody (path-projection with threshold)

Get returns m_idealPosition plus world-forward toward cached target. No angular state, no pivot — the path is the kinematic reference, not a point.

Adopt stashes. The consume block projects the source’s position onto the spline and rejects when the source sits too far from the path:

EnsureSplineResolved();
if (!m_spline) { m_hasPendingAdoption = false; return; }

AZ::Vector3 nearestWorld;
const float dist = m_spline->FindClosestWorldPoint(
    m_pendingAdoption.worldPos, nearestWorld, /*outT*/);

if (dist > m_adoptionPathThreshold)
{
    // Source sits too far from path — reject, fall back to plain blend.
    m_hasPendingAdoption = false;
    return;
}

m_idealPosition  = m_pendingAdoption.worldPos;
m_springVelocity = AZ::Vector3::CreateZero();
m_hasIdeal       = true;
consumedAdoption = true;
m_hasPendingAdoption = false;

m_adoptionPathThreshold is authored on the TrackBody (default 5.0 m). Prevents teleport-snap when the source cam sits well off the dolly’s path.

The consumedAdoption Gate

Problem: With ctx.snapThisFrame = true on activation, every body’s damping clause snap-clobbers m_idealPosition = desiredPos, discarding the adoption seed. Symptom: cam jerks to its natural ideal then blends from there.

Fix: The snap-on-activation block in every body is gated on !consumedAdoption:

if ((ctx.snapThisFrame || !m_hasIdeal) && !consumedAdoption)
{
    // Snap-seed path. Skipped when adoption already placed m_idealPosition.
}

Adoption-tick uses standard damping from the adopted seed, not snap-seed. When inheritance fires, the seed pose is preserved through the activation tick.

Authoring Gotcha — Matched but Not Inheriting

If m_inheritState is unchecked on a matched blend pair, the destination cam falls through to its snap-on-activation seed instead of consuming the source’s pose. Symptoms vary by body type but all point to the same root cause:

The fix is data-side: check the Inherit State flag on the matched blend entry inside the .camblendprofile asset.

If diagnostic prints are added during debugging, the smoking gun looks like:

Handoff: from=OrbitCam to=LeadCam inherit=0 (matched=1)

matched = 1, inherit = 0 means the blend pair IS in the asset, but m_inheritState is unchecked on it.

Adoption Coverage Matrix

See Also

Related PhantomCam pages:

• Cam Core — runs the handoff during SetPhantomCam.
• Blend Profiles — where m_inheritState lives.
• Interrupt Blending — the correction window runs after the handoff.
• Body Stage Variants — per-variant Get / Adopt detail.
• Phantom Cameras — Execution States — the snap-vs-adoption gating.

Basics-side authoring guide:

• The Basics: State Inheritance

Get GS_PhantomCam

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

2.3 - Interrupt Blending

When a blend A → B is in flight and a new blend A’ → C kicks off, snapping the cam’s source pose produces a perceptible velocity jolt — the cam visibly changes direction at the interrupt moment. The Cam Core’s mid-blend correction window prevents this by seeding the new blend at a velocity-matched curve point and Y-blending between the snapshot pose and the new blend’s natural pose across a small window.

This replaces the legacy BlendFromCore hard-anchor approach, which produced a velocity-zero discontinuity at every interrupt.

Contents

• The Problem
• The Mechanism
• Window Width
• Edge Cases
• Cam Core State
• StartBlend Detection
• OnTick Application
• Inspector Field
• What This Replaces
• See Also

The Problem

Consider a blend A → B running at 50% progress. A new winner C is arbitrated; the system needs a new blend A’ → C. Two naive approaches both fail:

The legacy BlendFromCore flag implemented the second approach. The new correction window replaces it.

The Mechanism

The Cam Core introduces a small correction window at the start of the new blend during which the rendered TM is a Y-blend between the snapshot pose and the new blend’s natural pose. After the window, pure new blend with live source / destination TMs.

Step by step

1. Capture the cam’s currently-rendered TM at the interrupt moment → m_interruptSnapshotTM.
2. Compute oldBlendFactor = oldCurTime / oldTargetTime (how far through the OLD blend we were).
3. Compute T_natural = 1 − oldBlendFactor — the curve point on the new blend at which the cam’s velocity matches its current motion.
4. Compute T_start = max(0, T_natural − m_interruptCorrection) — pull the new blend back by the configurable window width.
5. Seed curBlendTime = T_start * blendTime so the new blend starts at curve-point T_start.
6. Over the window [T_start, T_natural], the rendered pose is a Y-blend between m_interruptSnapshotTM and the new blend’s natural pose at the current curve point. The Y-factor sweeps 0 → 1 across the window.
7. After T_natural, the Y-blend yields fully to the new blend; pure new-blend interpolation continues with live source / destination TMs.

Net effect: the rendered cam starts in the snapshot pose at the interrupt, ramps gracefully into the new blend’s natural trajectory across the correction window, and proceeds normally.

Window Width

m_interruptCorrection is authored on the Cam Core, default 0.03 (3% of the new blend’s curve duration). The tradeoff:

3% is a balance that’s invisibly smooth for typical blend durations (~1s → 30ms correction window).

Edge Cases

Old blend nearly complete

If oldBlendFactor is close to 1 (the old blend was almost done), T_natural ≈ 0 and T_start ≈ −m_interruptCorrection. The window may compress to nothing — T_start clamps at 0:

T_start = max(0.0, T_natural - m_interruptCorrection);

When clamped, the new blend effectively starts from its natural beginning. The cam may still have a small handoff jolt because the correction can’t pull back further.

Old blend just started

If oldBlendFactor is close to 0 (old blend barely started), T_natural ≈ 1 and T_start ≈ 1 − m_interruptCorrection. Most of the new blend happens in pure new mode after a brief correction window. The snapshot influence is short-lived.

Non-blending interrupt (cold start of new blend)

If IsBlending == false when StartBlend is called, no interrupt — set m_inCorrectionWindow = false and run the new blend normally.

Cam Core State

class GS_CamCoreComponent {
    // ...
    float          m_interruptCorrection = 0.03f;     // authored

    bool           m_inCorrectionWindow   = false;
    float          m_correctionStart      = 0.0f;     // blendFactor where window begins
    float          m_correctionEnd        = 0.0f;     // blendFactor where window ends (= T_natural)
    AZ::Transform  m_interruptSnapshotTM  = AZ::Transform::CreateIdentity();
};

StartBlend Detection

void GS_CamCoreComponent::StartBlend(
    float blendTime,
    GS_Core::CurveType blendType,
    GS_Core::Math::BlendShape blendShape,
    GS_Core::Math::PivotSource pivotSource)
{
    if (IsBlending)
    {
        // Mid-blend interrupt.
        const float oldBlendFactor = curBlendTime / targetBlendTime;
        const float T_natural      = 1.0f - oldBlendFactor;
        const float T_start        = AZ::GetMax(0.0f, T_natural - m_interruptCorrection);

        // Snapshot current rendered TM.
        AZ::TransformBus::EventResult(m_interruptSnapshotTM, m_entityId,
            &AZ::TransformInterface::GetWorldTM);

        m_inCorrectionWindow = true;
        m_correctionStart    = T_start;
        m_correctionEnd      = T_natural;

        // Seed new blend's curve position so velocity matches.
        curBlendTime = T_start * blendTime;
    }
    else
    {
        // Cold start.
        m_inCorrectionWindow = false;
        curBlendTime = 0.0f;
    }

    // Capture source / dest poses, blend params.
    prevTransform      = ... ;          // cam's current world TM at this moment
    targetBlendTime    = blendTime;
    currentBlendType   = blendType;
    currentBlendShape  = blendShape;
    currentPivotSource = pivotSource;
    IsBlending         = true;
}

OnTick Application

void GS_CamCoreComponent::OnTick(float deltaTime, AZ::ScriptTimePoint)
{
    if (!IsBlending)
    {
        // Locked phase — read currentCam's TM, write it directly.
        return;
    }

    curBlendTime += deltaTime;
    const float blendFactor = AZ::GetMin(1.0f, curBlendTime / targetBlendTime);
    const float easedFactor = ApplyCurve(blendFactor, currentBlendType);

    // Compute the "natural" blended pose for this curve point.
    AZ::Vector3 blendedPos;
    if (currentBlendShape == BlendShape::Linear)
    {
        blendedPos = AZ::Vector3::Lerp(
            prevTransform.GetTranslation(),
            currentTM.GetTranslation(),
            easedFactor);
    }
    else
    {
        AZ::Vector3 pivot = ResolvePivot(currentPivotSource, lastCam, currentCam);
        blendedPos = GS_Core::Math::BlendPositionAroundPivot(
            prevTransform.GetTranslation(),
            currentTM.GetTranslation(),
            pivot, easedFactor, currentBlendShape, AZ::Vector3::CreateAxisZ());
    }
    AZ::Quaternion blendedRot = prevTransform.GetRotation().Slerp(
        currentTM.GetRotation(), easedFactor);

    AZ::Vector3    appliedPos;
    AZ::Quaternion appliedRot;

    if (m_inCorrectionWindow && blendFactor < m_correctionEnd)
    {
        // Y-blend the snapshot with the natural pose.
        float yFactor = (blendFactor - m_correctionStart) / m_interruptCorrection;
        yFactor = AZ::GetClamp(yFactor, 0.0f, 1.0f);

        appliedPos = AZ::Vector3::Lerp(
            m_interruptSnapshotTM.GetTranslation(), blendedPos, yFactor);
        appliedRot = m_interruptSnapshotTM.GetRotation().Slerp(blendedRot, yFactor);
    }
    else
    {
        // Past the correction window — pure new blend.
        appliedPos = blendedPos;
        appliedRot = blendedRot;
    }

    // Write final TM. Apply lens interpolation similarly.
    AZ::TransformBus::Event(m_entityId,
        &AZ::TransformInterface::SetWorldTranslation, appliedPos);
    AZ::TransformBus::Event(m_entityId,
        &AZ::TransformInterface::SetWorldRotationQuaternion, appliedRot);

    if (blendFactor >= 1.0f)
    {
        CompleteBlend();
    }
}

Inspector Field

What This Replaces

Pre-correction, the system used a BlendFromCore flag on the Cam Core. When set, the blend’s source pose was hard-anchored to the cam’s currently-rendered TM at the interrupt moment, for the entire duration of the new blend. The new blend’s velocity at t = 0 was therefore zero — an instant velocity discontinuity at the interrupt point.

The correction-window approach replaces this entirely. BlendFromCore is retained as a field on the Cam Core for back-compat but is not used in the new flow.

See Also

Related PhantomCam pages:

• Cam Core — owns StartBlend and OnTick.
• State Inheritance — runs BEFORE StartBlend; the destination cam’s pose is already inherited when the correction-window snapshot is captured.
• Blend Profiles — author the entries that trigger blends.
• Phantom Cameras — Execution States — m_blendingOut keeps the outgoing cam ticking during the blend so its source pose stays live.

Get GS_PhantomCam

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

3 - Phantom Cameras

A Phantom Camera is a single entity component — GS_PhantomCameraComponent — that publishes a candidate camera pose every tick. It holds priority, target routing, lens, channel scope, and snap / focus / blendingOut state, plus the stage pipeline slot that authors fill in to give the cam its behavior. Phantom cameras do not render anything themselves; they register with the Cam Manager and the Cam Core drives the engine view toward whichever phantom currently wins arbitration.

Where previous versions of GS_PhantomCam shipped separate components for each behavior (clamped-look, static-orbit, spline tracking, etc.), all of those behaviors now live as stage variants on the single base component. An author picks a Body stage, an Aim stage, and zero-or-more Additive stages from the type-picker, and the same GS_PhantomCameraComponent becomes a follow cam, an orbital cam, a tracking dolly, a third-person shoulder cam, or a cinematic stinger depending on which stages are slotted.

For usage guides and setup examples, see The Basics: GS_PhantomCam.

The Phantom Camera component in the Entity Inspector.

Contents

• How It Works
• Stage Pipeline
• Channel Scope
• Execution States
• Staged Poses
• Setup
• PhantomCamData Structure
• API Reference
• Camera Behavior Types
• Usage Examples
• Extending Phantom Cameras
• See Also

How It Works

Priority-Based Selection

Every phantom camera has a base priority. The camera with the highest effective priority (base plus any active influences) wins arbitration within its channel. You can control which camera wins through several strategies:

• Raise priority — Set the desired camera’s priority above all others via SetCameraPriority.
• Disable / Enable — Call DisableCamera to drop the camera’s effective priority, EnableCamera to restore it.
• Change priority directly — Call ChangeCameraPriority on the Cam Manager bus.
• Influence — Add temporary priority modifiers through Influence Fields without touching base priorities.

Follow and Look-At

Follow and look-at behavior is no longer hardcoded on the component; it is provided by the Body and Aim stages slotted on the pipeline. Each tick the cam threads a CameraState accumulator through:

Body → Aim → Reposition additives → Noise additives → Finalize

• The Body stage writes state.position — different variants implement spring-damped follow, orbital sweep, spline traversal, etc.
• The Aim stage writes state.rotation — including angle-clamped look, head-tracking look, etc.
• Additive stages correct or perturb the pose without poisoning Body / Aim ideals.

See Stage Pipeline for the per-tick contract.

Camera Data

Each phantom camera stores its lens and target configuration in a PhantomCamData structure. This data is read by the Cam Core during blending and by stages during evaluation. The stage list lives separately on the component (m_bodySlot, m_aimSlot, m_additives).

Stage Pipeline

Each phantom camera is a container for stages. The component owns three slots:

Stages are reflected polymorphic types — derived from IBodyStage / IAimStage / IAdditiveStage, not AZ::Component. The editor type-picker enumerates all registered derivations from the SerializeContext class hierarchy, so other gems can extend the catalog cleanly.

Per-tick orchestration (run by the component each OnTick):

EvaluateCamTick — eligibility check (see Execution States)
   │ tickActive == true
   ▼
EvaluatePose
   ├─► Build CameraContext (target, deltaTime, lifecycle flags, snapThisFrame)
   ├─► IBodyStage::Evaluate    → writes state.position, state.bodyAnchor
   ├─► IAimStage::Evaluate     → writes state.rotation, state.lookAtPoint
   ├─► snapshot m_desiredPose
   ├─► For each Reposition additive → corrects state
   ├─► snapshot m_stablePose
   ├─► For each Noise additive → perturbs state
   ├─► snapshot m_finalPose
   ├─► Resolve cached pivot (state.lookAtPoint, else target world position)
   └─► Commit m_finalPose to TransformBus + apply lens to engine Camera component

See Stage Pipeline reference for the full per-stage contract, init / asset-fresh-load semantics, and variant catalogs.

Channel Scope

Each phantom camera authors a CamChannelScope that decides how it participates in the channel system:

enum class CamChannelScope : AZ::u8 {
    Local,         // Default. Registers to ancestor stamp's channel, or channel 0 if no stamp.
    AllChannels,   // Stamped: per-rig-instance natural duplicate. Unstamped: warns + falls back.
    TrueUnique,    // Single instance. Either bound to a specific channel or shared across all.
};

Author recipes:

• Cam inside a rig prefab — leave as Local. Each spawned rig instance hosts its own copy via the stamp-walk path.
• Per-player tailored broadcast cam in the level — AllChannels (works naturally for in-rig cams; out-of-rig duplication is deferred).
• Hero-perspective cam for a specific player — TrueUnique + m_boundChannelId = N.
• Shared cinematic collapse cam — TrueUnique + advanced + m_allChannelsShare = true. Paired with a Group Target, this triggers OnAllChannelsActivatedSharedCam when every channel selects the cam.

See Channels & Instancing for the resolution algorithm.

Execution States

A phantom camera carries three boolean states that gate whether it ticks each frame. The tick-eligibility predicate is:

tickActive = m_hasFocus || m_alwaysUpdate || m_blendingOut

When tickActive is false the cam is fully dormant — its stages don’t run, its body doesn’t integrate input, its damping doesn’t advance.

The three flags

snapThisFrame and m_snapNextEval

When a cam should bypass damping for a single tick — to commit its ideal pose directly without spring lag — the component sets m_snapNextEval = true. The next Evaluate consumes the flag, sets ctx.snapThisFrame = true, and resets m_snapNextEval.

m_snapNextEval is set on:

• Focus gain — m_hasFocus flipped from false to true (gated on focus specifically; blend-out wake does NOT trigger snap, which would otherwise yank an outgoing cam back to its initial yaw).
• SetCameraTarget(validEntity) — new follow target.
• SetTargetFocusGroup(validEntity) — new group target.
• QueueSnapCamera() — explicit API call.
• Mid-spawn channel binding — the Cam Manager pushes a synchronous SnapCameraNow when a channel target is already present at registration time. See Cam Manager.

SnapCameraNow vs QueueSnapCamera

Input integration sub-gate

Body stages that drive pose from input (notably DynamicOrbitBody) integrate input on the same predicate, mirrored into CameraContext:

integrateInput = ctx.hasFocus || ctx.alwaysUpdate || ctx.blendingOut

The body still polls the input reader every tick regardless of integrateInput — the poll drains Delta-mode buffers so they don’t accumulate during dormancy. The integration result is discarded when !integrateInput.

Staged Poses

The pipeline produces three pose snapshots per tick:

Three snapshots exist because consumers vary. A Unit that uses camera-forward to drive movement input should query GetStablePose — querying GetFinalPose would let the noise stage drag the character around.

The component also caches a pivot each tick (m_cachedPivot) resolved from the Aim stage’s state.lookAtPoint, falling back to the target’s world position. The Cam Core queries this via GetCameraPivot to drive orbital blend shapes.

Setup

1. Create an entity and add GS_PhantomCameraComponent.
2. Set the Priority value. Higher values take precedence within the channel.
3. Configure FOV, near clip, and far clip on the lens fields.
4. Assign a Cam Target entity (the follow target). Leave empty to inherit the channel target from the Cam Manager.
5. From the Body type-picker, slot a body stage. Configure its target mode, offset, and damping halflife.
6. From the Aim type-picker, slot an aim stage. Configure its target mode, offset, and damping halflife.
7. Optionally add Additive stages — noise, impulse, tug listeners, collision reposition.
8. Set the Channel Scope (Local is the default and almost always correct).
9. Place the entity in your scene or inside a rig prefab. The component registers with the Cam Manager automatically on activation.

For a full walkthrough, see the PhantomCam Set Up Guide.

PhantomCamData Structure

The PhantomCamData structure holds the lens and priority configuration for a phantom camera. Stages are stored separately on the component.

Follow / look-at offsets, damping halflives, and target modes now live on the stages, not on PhantomCamData.

API Reference

Request Bus: PhantomCameraRequestBus

Commands sent to a specific phantom camera. ById bus — addressed by entity ID, single handler per address.

Lifecycle

Priority and target

Snap

Staged pose accessors

Impulse

Inheritance forwarders

Blend-out lifecycle

Camera Behavior Types

Retired components. ClampedLook_PhantomCamComponent, StaticOrbit_PhantomCamComponent, and Track_PhantomCamComponent no longer exist as separate components. Their behavior is now provided by stage variants on the base GS_PhantomCameraComponent. Legacy URLs for these subpages redirect to the matching stage docs.

AlwaysFaceCameraComponent

A billboard helper component. Keeps the attached entity always facing the active camera. This is not a phantom camera type itself but a utility for objects that should always face the viewer (UI elements in world space, sprite-based effects, etc.). Unchanged by the refactor.

Usage Examples

Switching Cameras by Priority

To make a specific phantom camera dominant, raise its priority above all others:

#include <GS_PhantomCam/Cameras/GS_PhantomCameraBus.h>

GS_PhantomCam::PhantomCameraRequestBus::Event(
    myCameraEntityId,
    &GS_PhantomCam::PhantomCameraRequests::SetCameraPriority,
    100);

Disabling the Current Camera

Disable the current dominant camera to let the next-highest priority camera take over:

GS_PhantomCam::PhantomCameraRequestBus::Event(
    currentCameraEntityId,
    &GS_PhantomCam::PhantomCameraRequests::DisableCamera);

Triggering a Camera Impulse

Fire all ImpulseNoise additives on the active cam at a strength scaled by distance:

const float strength = AZ::GetClamp(1.0f - distance / radius, 0.0f, 1.0f);
GS_PhantomCam::PhantomCameraRequestBus::Event(
    activeCameraEntityId,
    &GS_PhantomCam::PhantomCameraRequests::TriggerCameraImpulse,
    strength);

Script Canvas

Enabling and disabling a phantom camera:

Getting a phantom camera’s data:

Extending Phantom Cameras

Most camera customization now happens by authoring a new stage variant rather than subclassing the component. Stages are reflected polymorphic types — derive from IBodyStage, IAimStage, or IAdditiveStage, register with AZ_RTTI + AZ_CLASS_ALLOCATOR, and reflect under the base interface’s class hierarchy. The editor type-picker discovers the new variant automatically.

Use the PhantomCamera ClassWizard template to generate a new camera component when you need component-level customization (rare) — see GS_PhantomCam Templates.

Header (.h)

#pragma once
#include <GS_PhantomCam/Cameras/GS_PhantomCameraBus.h>
#include <Source/Cameras/GS_PhantomCameraComponent.h>

namespace MyProject
{
    class MyCustomCam : public GS_PhantomCam::GS_PhantomCameraComponent
    {
    public:
        AZ_COMPONENT_DECL(MyCustomCam);

        static void Reflect(AZ::ReflectContext* context);
    };
}

Implementation (.cpp)

#include "MyCustomCam.h"
#include <AzCore/Serialization/SerializeContext.h>

namespace MyProject
{
    AZ_COMPONENT_IMPL(MyCustomCam, "MyCustomCam", "{YOUR-UUID-HERE}");

    void MyCustomCam::Reflect(AZ::ReflectContext* context)
    {
        if (auto serializeContext = azrtti_cast<AZ::SerializeContext*>(context))
        {
            serializeContext->Class<MyCustomCam, GS_PhantomCam::GS_PhantomCameraComponent>()
                ->Version(0);

            if (AZ::EditContext* editContext = serializeContext->GetEditContext())
            {
                editContext->Class<MyCustomCam>("My Custom Camera", "Custom phantom camera component")
                    ->ClassElement(AZ::Edit::ClassElements::EditorData, "")
                        ->Attribute(AZ::Edit::Attributes::Category, "MyProject")
                        ->Attribute(AZ::Edit::Attributes::AppearsInAddComponentMenu, AZ_CRC_CE("Game"));
            }
        }
    }
}

For stage-level extension (the more common case), see the Stage Pipeline reference.

See Also

For related PhantomCam components:

• Cam Manager
• Cam Core
• Stage Pipeline
• Channels & Instancing
• Blend Profiles
• Camera Influence Fields
• Group Targets
• State Inheritance

For conceptual overviews and usage guides:

• GS_PhantomCam Overview
• The Basics: Phantom Cameras

Get GS_PhantomCam

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

3.1 - Stage Pipeline

Every Phantom Camera runs the same fixed pipeline per tick:

Body → Aim → Reposition additives → Noise additives → Finalize

The Body and Aim stages produce the cam’s smoothed ideal pose; Reposition additives correct it for collision / tug volumes; Noise additives perturb it for shake and impulse; Finalize commits the result to the entity transform and the engine camera component.

Stages are not AZ::Components. They are reflected polymorphic types — derived from IBodyStage, IAimStage, or IAdditiveStage. The editor’s type-picker enumerates registered derivations from the SerializeContext class hierarchy, so other gems can extend the catalog cleanly without touching the base component.

For per-variant detail, see the catalog pages:

• Body Stage Variants — DefaultFollowBody, OrbitBody, DynamicOrbitBody, LeadingFollowBody, TrackBody.
• Aim Stage Variants — DefaultLookAtAim, ClampedLookAim. Plus extensions from gs_performer.
• Additive Stage Variants — CollisionReposition, OcclusionReposition, TugAimListener, TugBodyListener, PerlinNoise, ImpulseNoise.

Contents

• Per-Tick Model
• Stage Interfaces
• CameraState and CameraContext
• Target Routing
• Decoupled Ideal Pattern
• Damping Convention
• Init Contract
• Polymorphic-Array Convention
• StageHelpers Utility
• Reflection Conventions
• See Also

Per-Tick Model

Each tick, the owning Phantom Camera threads a CameraState accumulator through the pipeline:

GS_PhantomCameraComponent::EvaluatePose
   │
   ├─► Build CameraContext (target, deltaTime, lifecycle flags, snapThisFrame)
   │
   ├─► CameraState state;  // zero-initialized accumulator
   │
   ├─► IBodyStage::Evaluate(state, ctx, dt)
   │       writes state.position, state.bodyAnchor
   │
   ├─► IAimStage::Evaluate(state, ctx, dt)
   │       writes state.rotation, state.lookAtPoint
   │
   ├─► m_desiredPose = (state.position, state.rotation)
   │
   ├─► For each additive in m_repositionStages:
   │       Evaluate(state, ctx, dt) — may correct state.position/rotation
   │
   ├─► m_stablePose = (state.position, state.rotation)
   │
   ├─► For each additive in m_noiseStages:
   │       Evaluate(state, ctx, dt) — perturbs state.position/rotation
   │
   ├─► m_finalPose = (state.position, state.rotation)
   │
   ├─► Resolve cached pivot from state.lookAtPoint (else fallback to target world pos)
   │
   └─► Commit m_finalPose to TransformBus + apply lens to engine Camera component

The component partitions additives into m_repositionStages and m_noiseStages once at slot-assign time (or whenever the additive list changes) based on each additive’s GetStage() result — per-tick code does not re-check the enum each frame.

CamPipelineStage is a fixed ordered enum:

enum class CamPipelineStage {
    Body,
    Aim,
    Reposition,
    Noise,
    Finalize
};

Reposition and Noise are the values an additive may return from GetStage. Body, Aim, and Finalize exist for symmetry but are not author-selectable.

Stage Interfaces

IBodyStage

Single slot per cam. Computes the smoothed follow position.

class IBodyStage {
public:
    AZ_RTTI(IBodyStage, "{6A78E21A-9A5F-4AB5-8F20-08B4D09E5C01}");
    AZ_CLASS_ALLOCATOR(IBodyStage, AZ::SystemAllocator);

    virtual ~IBodyStage() = default;

    virtual void Init() {}

    virtual void Evaluate(CameraState& state, const CameraContext& ctx, float dt) = 0;
    virtual AZ::EntityId ResolveTarget(AZ::EntityId incoming, TargetSignalKind kind) = 0;
    virtual const char* GetDisplayName() const { return "Body Stage"; }

    // State inheritance — default returns false (no protocol).
    virtual bool TryGetPoseSnapshot(CamPoseSnapshot& out) const  { return false; }
    virtual bool TryAdoptPoseSnapshot(const CamPoseSnapshot& in) { return false; }

    static void Reflect(AZ::ReflectContext* context);
};

See Body Stage Variants for the catalog.

IAimStage

Single slot per cam. Computes the smoothed look rotation.

class IAimStage {
public:
    AZ_RTTI(IAimStage, "{9F37E4C6-04AD-4B1F-A9E2-0D3A4B8F1E02}");
    AZ_CLASS_ALLOCATOR(IAimStage, AZ::SystemAllocator);

    virtual ~IAimStage() = default;

    virtual void Init() {}

    virtual void Evaluate(CameraState& state, const CameraContext& ctx, float dt) = 0;
    virtual AZ::EntityId ResolveTarget(AZ::EntityId incoming, TargetSignalKind kind) = 0;
    virtual const char* GetDisplayName() const { return "Aim Stage"; }

    static void Reflect(AZ::ReflectContext* context);
};

Aim does not implement state inheritance — inheritance is body-only by design. See Aim Stage Variants.

IAdditiveStage

Stackable. Self-declares phase via GetStage.

class IAdditiveStage {
public:
    AZ_RTTI(IAdditiveStage, "{B7D2F618-3E44-4A71-9C21-0F3B7C5E0D04}");
    AZ_CLASS_ALLOCATOR(IAdditiveStage, AZ::SystemAllocator);

    virtual ~IAdditiveStage() = default;

    virtual void Init() {}

    virtual CamPipelineStage GetStage() const = 0;  // returns Reposition or Noise
    virtual void Evaluate(CameraState& state, const CameraContext& ctx, float dt) = 0;
    virtual const char* GetDisplayName() const { return "Additive Stage"; }

    static void Reflect(AZ::ReflectContext* context);
};

See Additive Stage Variants.

CameraState and CameraContext

CameraState

The mutable pose accumulator threaded through every stage. Not serialized.

struct CameraState {
    AZ::Vector3    position    = Vector3::Zero();        // accumulator
    AZ::Quaternion rotation    = Quaternion::Identity();

    // Sidecar hints populated by Body/Aim for downstream stages.
    AZ::Vector3    bodyAnchor  = Vector3::Zero();   // post-offset follow anchor
    AZ::Vector3    lookAtPoint = Vector3::Zero();   // world-space focal point
};

The two sidecar fields exist so Reposition additives can read the “natural” pose Body / Aim intended rather than the live state (which may have been displaced by an earlier additive). Tug listeners, for example, blend toward the source point starting from the Body’s bodyAnchor rather than the cam’s possibly-perturbed state.position — prevents compound feedback across ticks.

CameraContext

Read-only per-tick context. Not serialized.

struct CameraContext {
    GS_PhantomCameraComponent* owner;        // for owner helpers (WriteLensFieldOfView, QueueSnapCamera).

    AZ::EntityId               camEntityId;
    AZ::EntityId               targetEntityId;

    AZ::Transform              camInitialTM;     // cam TM read at start of tick
    AZ::Transform              targetTM;         // resolved target world TM
    AZ::Vector3                targetVelocity;

    bool                       targetIsPhysical;
    bool                       hasFocus;
    bool                       alwaysUpdate;
    bool                       blendingOut;
    bool                       snapThisFrame;    // bypass damping this tick

    float                      deltaTime;
};

hasFocus || alwaysUpdate || blendingOut is the input-integration gate — Body stages that drive pose from input (notably DynamicOrbitBody) integrate input only when any of these is true. See Execution States.

snapThisFrame is set on focus gain, target swap, queued snap, and a few other lifecycle events. Stages honor it by bypassing damping for the one tick it is true.

Target Routing

Every Body and Aim variant authors a CamTargetMode enum and (depending on mode) supporting fields. This is the front-end every variant uses to decide which entity it actually follows.

enum class CamTargetMode : AZ::u8 {
    None               = 0,  // no-op for target resolution
    Transform          = 1,  // follow / look at the dispatched CameraTarget
    TargetOffsetEntity = 2,  // reserved — not yet implemented
    // 3 was FocusGroup — removed; use GroupTarget.
    Head               = 4,  // reserved — not yet implemented
    Override           = 5,  // manually-set m_overrideEntity on this stage
    GroupTarget        = 6   // resolve a named GroupTargetComponent via CamManager
};

TargetSignalKind identifies which bus call dispatched the target signal. Lets stages filter by target mode:

enum class TargetSignalKind {
    CameraTarget,  // SetCameraTarget
    FocusGroup     // SetTargetFocusGroup
};

Legacy scenes storing FocusGroup = 3 deserialize as an unknown value; the author re-picks GroupTarget. The newer mode is the canonical way for a stage to track a named group via Group Targets.

Decoupled Ideal Pattern

A subtle but critical convention: each Body / Aim variant maintains an m_idealPosition / m_idealRotation independent of what gets committed to the entity transform.

Why: Reposition additives (collision, occlusion, tug) and Noise additives mutate state.position and state.rotation AFTER Body / Aim runs. If the Body read the committed transform back next tick, the spring would re-try its advance every frame against a collision clamp — producing shudder. By tracking an internal ideal, the Body’s spring runs in clean kinematic space; the committed transform may differ (clamped by collision, shaken by noise) but the Body’s trajectory stays smooth.

The same applies to Aim — m_idealRotation is the slerp’s working value; downstream rotation-modifying additives can freely displace state.rotation without poisoning next tick’s slerp trajectory.

m_idealPosition / m_idealRotation are also what state inheritance reads for TryGetPoseSnapshot and writes for TryAdoptPoseSnapshot — see State Inheritance.

Damping Convention

There is no separate Smoothing stage. Each stage owns its damping internally:

Different halflives capture different physical slownesses and compose naturally. Damping uses the frame-rate-independent HalflifeAlpha(halflife, dt) = 1 - exp2(-dt / halflife) helper.

ctx.deltaTime is clamped at tick entry (maxEvalDeltaTime = 0.05s default) so editor hitches don’t spike damping.

Init Contract

Each stage’s Init() runs once per Activate, after the slot is populated, before any Evaluate. The default is a no-op.

Critical use case — asset-fresh-load. Stages holding asset references (e.g. DynamicOrbitBody.m_orbitShape, PerlinNoise.m_profile) override Init to force a fresh AssetManager load. The deserialized asset reference only carries an AssetId — without an explicit GetAsset call in Init, in-editor edits to the asset don’t propagate to the runtime instance.

Pattern:

void DynamicOrbitBody::Init()
{
    if (m_orbitShape.GetId().IsValid())
    {
        m_orbitShape = AZ::Data::AssetManager::Instance().GetAsset<CameraOrbitShape>(
            m_orbitShape.GetId(),
            AZ::Data::AssetLoadBehavior::PreLoad);
        m_orbitShape.BlockUntilLoadComplete();
    }
}