Actor, Scene, and Primitive Components¶
Actors are containers. Components are the parts that give an actor a location, a shape, collision, audio, camera, movement, or reusable behavior.
The one-minute version¶
- An
Actoris the thing that can be placed or spawned in a level. Most of what the player sees or collides with is done by that actor's components. UActorComponentis the base component type. It belongs to an actor but has no world transform by itself.USceneComponentadds a transform and attachment support. It can sit in a parent/child hierarchy, but it does not automatically render or collide.UPrimitiveComponentadds renderable/collidable geometry. Static meshes, skeletal meshes, capsules, boxes, spheres, and many visual components are primitive components.- An actor's visible world location usually comes from its RootComponent. Moving the actor means moving that root component.
- Meshes, collision, audio, cameras, spring arms, and health logic live as components because they are parts of an actor, not separate world identities by default.
The component tree¶
Open a Blueprint's Components window and you are looking at the actor's parts:
BP_PlayerCharacter (Actor)
└─ CapsuleComponent (PrimitiveComponent, RootComponent)
├─ Mesh (SkeletalMeshComponent, PrimitiveComponent)
├─ SpringArm (SceneComponent)
│ └─ FollowCamera (CameraComponent, SceneComponent)
└─ HealthComponent (ActorComponent)
The tree matters because transform changes flow through it. Move the capsule, and the mesh, spring arm, camera, and other attached scene components follow. Move the mesh relative to the capsule, and only the mesh's offset changes.
That is why actor-level transform nodes are not abstract magic. They usually operate through the actor's root scene component. If there is no useful root, or if the root is the wrong component, movement, collision, and attachment behavior will feel wrong.
The three component families¶
flowchart TD
Actor[AActor<br/>placeable/spawnable world object] --> C[UActorComponent<br/>owned part, no transform]
C --> S[USceneComponent<br/>has transform and attachment]
S --> P[UPrimitiveComponent<br/>has geometry/render/collision]
Actor Component¶
An Actor Component is a behavior/data part with no independent position.
Use it for:
- health, inventory, stamina, team, interaction, ability, or sensor logic;
- state that should be reused across many actor classes;
- code that should belong to the owning actor but not to any mesh/socket.
An Actor Component can tick if ticking is enabled. It can bind events, call functions on its owner, own variables, and broadcast dispatchers. It cannot be placed at a hand socket or used as a collision shape because it has no transform.
Scene Component¶
A Scene Component has a transform: location, rotation, and scale. It can attach to another scene component and act as a parent for other components.
Use it for:
- empty pivot points;
- sockets/offset anchors;
- spring arms, cameras, audio components, arrow components;
- organizing a hierarchy where child components should follow a parent.
A Scene Component is useful even when it is invisible. For example, a Muzzle
scene component on a weapon gives you a stable transform for spawning a
projectile.
Primitive Component¶
A Primitive Component is a scene component with geometry. It can render, collide, overlap, block traces, or simulate physics depending on its subclass and settings.
Use it for:
- Static Mesh and Skeletal Mesh components;
- Capsule, Box, Sphere, and other collision components;
- renderable effects and components with bounds;
- physics bodies and hit/overlap events.
Most collision pages on this site talk about primitive components because overlaps and hits are component-pair events, not vague actor events.
The root component is the actor's transform body¶
An actor's transform is effectively the transform of its root scene component. Child components store their transforms relative to their parent unless they are using absolute transform flags.
Set Actor Location
-> moves the actor's RootComponent in world space
-> child scene/primitive components keep their relative offsets
This explains common beginner surprises:
- The mesh moves but collision stays behind. You moved a child mesh relative to the capsule instead of moving the actor/root.
- The actor moves but the visible mesh appears offset. The mesh has a relative offset under the root.
- A trace hits the capsule, not the art. Collision is on the root capsule or another primitive component, not automatically on every visible part.
- A socket follows animation. The socket belongs to a skeletal mesh component, so anything attached there follows that component's evaluated pose.
For characters, the root is normally the capsule, while the skeletal mesh is offset below it. That is intentional: Character Movement moves the capsule through the world, and the mesh follows.
Why not make everything an Actor?¶
Use an Actor when the thing needs its own world identity:
- it can be placed separately in a level;
- it can be spawned/destroyed as a gameplay object;
- it needs its own transform and lifetime;
- it should replicate, be possessed, take damage, or be found as an actor.
Use a Component when the thing is part of an actor:
- a mesh or collision shape on a door;
- a camera on a player;
- a reusable health behavior on enemies and props;
- a muzzle point, audio source, spring arm, inventory component, or interaction component.
The quick path is making every visible part a separate actor. The concrete cost is reference/lifetime confusion: you now have to coordinate transforms, ownership, destruction, networking, and communication between things that could have been one actor with clear parts.
Component registration and runtime behavior¶
Components must be registered with the world before they can tick, render, collide, or otherwise participate in the scene. Designed components in the Components window are registered as part of normal actor creation. Runtime components created with Add Component by Class go through a registration/finish step as part of the node's implementation.
If a component appears to do nothing, check:
- does the actor exist in the play world?
- is the component registered?
- is it active/ticking if it needs tick?
- is it attached where you think it is?
- for primitive components, are collision/render/physics settings enabled?
- are you editing the class default or the live instance?
Failure usually looks like silence: no collision event, no visible mesh, no camera view, no tick. The engine does not infer the missing setup from the component name.
The pattern everyone actually uses¶
For a first character:
BP_PlayerCharacter
-> CapsuleComponent root
-> CharacterMovementComponent
-> Skeletal Mesh under capsule
-> SpringArm under capsule or mesh
-> Camera under spring arm
-> HealthComponent as plain ActorComponent
For a pickup:
BP_Pickup
-> Scene root or mesh root
-> StaticMeshComponent for art
-> SphereComponent for interaction overlap
-> optional AudioComponent for idle hum
For an interactable door:
BP_Door
-> Scene root
-> DoorFrame mesh
-> DoorPanel mesh
-> BoxComponent trigger
-> Timeline moves DoorPanel relative rotation
Lookalikes - which one do I want?¶
| Thing | Has transform? | Renders/collides? | Use when |
|---|---|---|---|
| Actor | Through root component | Through components | It is a placed/spawned world object with its own lifetime. |
| Actor Component | No | No by default | Reusable behavior/data attached to an actor. |
| Scene Component | Yes | No by default | Pivot, socket anchor, camera, spring arm, audio, hierarchy parent. |
| Primitive Component | Yes | Yes, depending subclass/settings | Mesh, collision shape, physics body, overlap/hit source. |
| Child Actor Component | Yes, as a component that owns a child actor | The child actor has its own components | A designed sub-actor should live as part of another actor. |
| Spawn Actor from Class | Creates separate actor | Actor's components decide | Runtime thing needs its own world lifetime. |
Rule of thumb: actor = whole object; component = part of an object; root component = the part the actor's transform rides on.
Going deeper¶
- World vs relative transforms - parent and child transform spaces.
- Attach Actor To Component
- actor attachment still attaches root components to scene components.
- Collision presets, channels, and responses
- collision lives on primitive components.
- Character Movement Component - why characters move through a movement component and root capsule.
- Spring Arm + Camera - a common scene-component hierarchy.
- Official docs: Components, Components Window, Actors, UActorComponent, USceneComponent, and UPrimitiveComponent.
- Engine source (requires engine access - we do not reproduce it here):
component base behavior in
Engine/Source/Runtime/Engine/Private/Components/ActorComponent.cpp; scene transforms and attachment inEngine/Source/Runtime/Engine/Private/Components/SceneComponent.cpp; primitive render/collision behavior inEngine/Source/Runtime/Engine/Private/Components/PrimitiveComponent.cpp; actor component ownership and root-component helpers inEngine/Source/Runtime/Engine/Private/Actor.cpp.