Learn about this Experimental feature, but you cannot publish a project that uses it.
The camera director is responsible for selecting the active camera and blending between cameras when the active camera changes. Every player has a camera_director_component that you can use to control which camera is active for that player.
There are two key things to remember when working with a camera director:
camera_director_componentderives fromcamera_component, which means directors are nestable and have their own modifier stack.An empty camera director is inert. Registering the first camera activates the Scene Graph Camera system for that player, and deregistering the last camera deactivates the system and returns to the default Fortnite camera.
Get the Player's Camera Director
Retrieve the player's camera director with this code:
if (Director := Player.GetComponent[camera_director_component]):
# ...Once you have the director, you can register cameras with it, each with a priority.
Registering Cameras
To register a camera with a a priority on Call AddCamera to register a camera with a priority.
AddCamera(Camera:camera_component, Priority:rational):cancelable
AddCamera is failable, so call it with square brackets.
A few things worth knowing about AddCamera:
It returns a handle: The returned cancelable deregisters the camera when you call
Cancel()on it. Keep it if the camera is ever meant to go away.It runs on the server: Registration is server-side work, and the resulting list of cameras replicates to clients. Do not expect AddCamera to succeed from client-only code.
Registering the same camera twice updates it: If the camera is already registered, its existing entry is reused and moved to the new priority instead of a second entry being created. This is how you change a camera's priority.
Adding a director to itself fails: Any other camera component, including another director, is accepted.
The camera must be attached to an entity: A camera component registered to a director does nothing unless it is attached to an entity in the world, because that entity's transform is where the camera starts from.
using { /Verse.org/SceneGraph }
using { /Verse.org/Simulation }
# Registers this entity's camera for a player, and takes it back out again.
camera_registration_component := class(component):
# The priority this camera competes at.
@editable
Priority : int = 100
Choosing the Active Camera
The director keeps its entries sorted by priority and walks them from the highest priority downward, picking the first camera that is currently in the scene.
Camera selection works as follows:
Highest priority wins: Priorities are rational, so you can insert a camera between two existing ones without renumbering anything.
Cameras that are not in the scene are skipped: A registered camera whose component is not currently in the scene is passed over, and the next highest priority takes the active slot. This means you can leave a camera registered and control whether it is eligible by whether its entity is in the scene.
Ties go to the most recently-registered camera: Registering a camera at a priority that already exists places it above the existing one, so it becomes active.
A change of active camera starts a transition: The director resolves one transition per change, asking the outgoing and incoming cameras which blend to use. To learn more about transition resolution, see Camera Component Transitions.
If camera devices and scene graph cameras are both active for a player, the scene graph camera takes priority.
Removing Cameras
There are two ways a camera stops being registered:
Cancel the handle: Calling
Cancel()on thecancelablethatAddCamerareturned removes that camera's entry. If it was the active camera, the director immediately picks the next eligible one and transitions to it.Let the camera leave the simulation: A camera component tracks the registrations made against it and cancels them all when it ends simulation. Removing a camera's entity from the world therefore deregisters it from every director that was using it, with no bookkeeping on your part.
When the last entry is removed, the director deactivates the Scene Graph camera system for that player and the normal Fortnite camera resumes (a camera device or default Fornite camera).
If the director still has entries but none of them are currently eligible, it does not deactivate. It falls back to an internal camera posed at the director's own entity transform and blends to it through the normal transition path. So, an empty director passes control back to Fortnite while a director with all ineligible cameras keeps the Scene Graph camera system running on a fallback view.
Nesting Directors
Because a director is a camera component, a director can be registered as a camera inside another director:
OuterDirector.AddCamera[InnerDirector, Priority := 500]To the outer director, the inner director counts as a single camera at priority 500. The inner director picks its own active camera independently using its own priorities.
Use nesting to group a set of related cameras under one priority, so the group completes as a unit. Priorities inside the inner director only decide among that group's own cameras. The outer director never sees those numbers — it only sees the group as one camera at the priority you gave it.
How the Director Works
The Scene Graph camera director is a Verse-facing layer over a camera director in the Gameplay Cameras system, and understanding this mapping helps when you are debugging.
Each camera becomes an evaluation context. The active camera's evaluation context is attached as the child context the director drives, and it is released and replaced when the active camera changes.
The per-frame order is select, then transition, then evaluate. The director determines the active camera, overrides the next transition if the camera changed, and then evaluates.
Ticking follows registration. The first entry registers the director's tick and runs the activation callback for the player. Removing the last entry unregisters the tick and destroys both the camera system evaluator and the evaluation context, which is what returns the player to the normal Fortnite camera.
Entries replicate. The list of camera entries replicates with a RepNotify, and each entry is a replicated subobject carrying its camera, priority, and resolved transition. That is how the client knows what to evaluate.
A camera shared between directors is duplicated. If the camera the director wants is already active in another director's context, the director creates a second evaluation context for it rather than fighting over the first.
Outgoing camera rigs are frozen during a blend. This is forced on, so a camera component that is removed from the world partway through a transition cannot break the blend.
Server-side evaluation is off by default. On a dedicated server the director skips camera evaluation unless
Verse.Camera.EnableCameraUpdateOnServeris enabled. Evaluation is client work, which is why cameras stay responsive to input.
