A modifier is a runtime-added override that targets a specific camera node class and changes selected node parameters. Modifiers let gameplay states change how a non-transient camera behaves without creating a new camera type or editing the active type asset.

Examples:

• Raise FieldOfViewNode while sprinting.
• Reduce LookAtNode weight while stunned.
• Disable or retune CollisionPushNode for a scripted room.
• Swap a ControlRotateNode response curve during aim.

Modifiers do not add or remove nodes. They only affect nodes that already exist on the active camera.

Not Unreal's UCameraModifier¶

Unreal's built-in UCameraModifier post-processes the final Player Camera Manager view. ComposableCameraSystem modifiers sit below that final output: they target individual nodes before the camera finishes evaluating, so downstream nodes see the changed parameter values.

Authoring Model¶

Create a Node Modifier Data Asset in the Content Browser. The asset is the unit you add and remove at runtime.

Each asset contains one or more fixed wrapper entries in its Modifiers array. A wrapper has two authoring modes:

The Node Type mode is the normal path for most gameplay camera tuning. It copies only the checked properties from a template node. Runtime wires, exposed parameters, and default pin values still exist, but checked modifier properties win while the modifier owns that field.

Use Custom Modifier Class when the override needs procedural logic or compatibility with an older Blueprint modifier asset.

Apply Modes¶

The data asset's ApplyMode controls what happens after the modifier manager decides the asset is effective for the current camera.

ReactivateCamera is the default. Adding or removing the modifier reconstructs the current type-asset camera as a fresh instance and blends from the old camera pose to the new camera pose. Node Type overrides are applied before node initialization, so the node starts its activation with the modified values. Custom Blueprint modifier callbacks keep the legacy post-initialize timing.

ModifyExistingInstance keeps the same camera actor and node instances alive. The runtime state takes ownership of the checked node fields, writes target values into the live node, and optionally blends supported property types over time. This is useful for gameplay tuning such as FOV, offsets, speeds, weights, and response curves where rebuilding the whole camera would be unnecessary.

Continuous value transitions are handled by UComposableCameraModifierTransitionBase. Discrete fields switch at the transition's DiscreteSwitchWeight. If no value transition is set, the value changes immediately.

Camera Tag Queries¶

Camera types and spawned cameras carry CameraTags, an FGameplayTagContainer. A modifier asset carries CameraTagQuery, a full gameplay tag query.

• Empty CameraTagQuery matches every camera.
• ANY, ALL, and NONE query expressions are supported through Unreal's native tag query editor.
• Legacy single CameraTag values migrate into CameraTags.
• Legacy modifier CameraTags lists migrate into an ANY query.

Gameplay still controls when the modifier asset is active. The tag query controls which running cameras it can affect.

Priority¶

When two active modifier assets both target the same camera and the same node class, Node Type entries resolve independently for each checked property. The higher-priority asset wins only for overlapping properties.

Priority is evaluated per (camera, exact node class, property). One asset can win FieldOfViewNode.FieldOfView while another simultaneously wins FieldOfViewNode.FieldOfViewOffsetCurve, as long as their checked properties do not overlap. Equal priority preserves later-registration-wins behavior.

Custom Modifier Class entries remain whole-node winners because arbitrary Blueprint side effects cannot declare which properties they own.

Transitions¶

ReactivateCamera assets use camera-pose transitions when an add/remove changes the effective modifier set:

1. OverrideEnterTransition on the incoming modifier asset, when adding.
2. OverrideExitTransition on the outgoing modifier asset, when removing.
3. The normal transition resolution chain for the camera type.
4. A hard cut.

ModifyExistingInstance assets use value transitions instead:

1. OverrideEnterValueTransition on the incoming modifier asset, when adding.
2. OverrideReplaceValueTransition on the incoming modifier asset, when it replaces another asset for the same checked property.
3. OverrideExitValueTransition on the outgoing modifier asset, when removing.
4. Immediate value application when the selected transition is unset or has zero duration.

If Replace is unset, the runtime keeps the legacy priority handoff rule: incoming Enter is used when the incoming priority is at least the outgoing priority; otherwise outgoing Exit is used.

This keeps modifier application deterministic while letting simple property tuning avoid full camera reactivation.

Adding and Removing at Runtime¶

From Blueprint, use the Add Modifier and Remove Modifier functions in UComposableCameraBlueprintLibrary. Both take a resolved AComposableCameraPlayerCameraManager and a UComposableCameraNodeModifierDataAsset.

From C++, prefer the same library when you need world/player resolution. If you already own a PCM reference, AddModifier and RemoveModifier are available directly on the PCM.

Mesh Camera Layers use the same system internally: a mesh profile supplies modifier assets, the world subsystem duplicates those assets per player camera manager, and the PCM replaces the old set with one camera refresh.

In Summary¶

• Modifier assets are the runtime unit; individual wrapper entries are not registered directly.
• Node Type mode lets designers override checked node properties without authoring a Blueprint modifier class.
• Custom Modifier Class mode keeps the older Blueprint/C++ extension path.
• CameraTagQuery scopes modifier assets to camera tag containers.
• Highest priority wins per checked property; disjoint Node Type properties on the same node class can compose.
• ReactivateCamera rebuilds and pose-blends the current camera.
• ModifyExistingInstance keeps the live camera and value-blends supported properties.

Next: lightweight, self-expiring per-frame behaviors via Actions.