Asset-Generated Components: How Meshes, Sounds and Particles Become Components
In the main lesson you wrote a component yourself. But hold on — you never wrote mesh_component, so where did it come from? UEFN wrote it for you: the meshes, sounds and particle assets already in your project automatically generate matching component classes. These are called asset-generated components, and they are by far the most numerous kind of component in Scene Graph.
1. Where They Come From: Assets Grow Their Own Component Classes
Epic's definition is short: an asset-generated component is a component class created automatically from preexisting content in your project, such as a mesh, sound, or particle system asset. Those assets may also expose properties you can then modify on the generated component.
The step that catches people: after importing or creating an asset, you have to compile your project's Verse code before the component class is generated. Freshly imported an .fbx and can't find it in the Add Component list? Nine times out of ten you simply haven't compiled yet.
This mechanism answers a common beginner question: "how many kinds of component does Scene Graph actually have?" The few dozen built-ins (transform, light, collision, camera, interactable…) are just the skeleton. What really fills out a project is the large batch generated from your own assets. The list is as long as your usable asset library.
It also completes a sentence from the last lesson. An entity is a container, a component is an ability — and in this design, "what it looks like" is an ability too. Visual form is not an intrinsic property of an entity; it is carried in by a component generated from an asset. An entity with no mesh_component is completely invisible: it still exists, it can still hold logic, it just has no body.
2. mesh_component: The Archetype
The mesh component's Verse class name is literally mesh_component. It gives an entity a visible form and is the most-attached component there is, no contest. The options Epic documents:
| Option | Values | Effect |
|---|---|---|
| Enable | True / False | Activates or deactivates the component |
| Collidable | True / False | Whether it participates in physics collision |
| Queryable | True / False | Whether Verse code can reference it |
| Visible | True / False | Whether it displays in the scene |
Material slots live here too: they can be selected and overridden through the mesh dropdown menu. One phrasing in the docs is worth noting — asset-generated components are always overridden from the component dropdown menu. That is, you are not editing the asset itself; you are giving it an override on this entity. Same idea as changing a Static Mesh Component's Material Override without touching the parent material.
How do you use it in code? Lesson 27's comparison table already showed it: Entity.GetComponent[mesh_component] fetches it, and Enable() / Disable() toggle its display. Epic's own "platform that disappears on a loop" tutorial does exactly this:
blink_component<public> := class<final_super>(component):
@editable
Duration<public>:float = 2.0
# Hide: switch off the mesh component on this entity
Hide():void =
if (Mesh := Entity.GetComponent[mesh_component]):
Mesh.Disable()
# Show: switch it back on
Show():void =
if (Mesh := Entity.GetComponent[mesh_component]):
Mesh.Enable()
OnSimulate<override>()<suspends>:void =
loop:
Sleep(Duration)
Hide()
Sleep(Duration)
Show()
Read it back: this component has no idea what it is attached to. It just asks "do you have a mesh?" and toggles it if the answer is yes. The same blink_component works on a cube, on a staircase, on a tree — because it depends on an ability, not a type. That sentence could serve as the slogan for all of Scene Graph.
Note the if wrapped around GetComponent: the lookup is an operation that can fail, so it must sit in a failure context. That's Verse's long-standing way of killing Accessed None at the syntax level (Lessons 12 and 18), and it holds for component lookup too.
3. Three Limits to Know Up Front
- ▢ One component of a kind per entity. Epic's wording: you can only add one of a given component class or subclass. So you cannot hang two meshes off one entity. Building an object out of three meshes? Create three child entities and give each one a mesh. This is the biggest structural break from Blueprint, where five Static Mesh Components on one Actor is routine.
- ▢ Compile after importing before the component class exists. See section 1. If a new asset doesn't show up, compile first.
- ▢ Not every asset qualifies. Epic states plainly that Fortnite's own Static Meshes and FAB assets are currently not compatible with Scene Graph in UEFN; the static meshes usable as mesh_component are the basic shapes. For custom meshes you need to import a 3D mesh file such as an .fbx, or build one with UEFN's modeling tools.
The third one genuinely affects your start-up pace: if your existing workflow is "pull an asset from FAB, drag it into the level", moving to Scene Graph means solving the asset-sourcing question first. It's also a reminder that Scene Graph is still being built out inside UEFN — the capability boundary moves release by release, so check the official notes of the day before you plan around it.
4. Compared to Dragging In a Static Mesh Component
A Blueprint author can walk this flow blindfolded: open the Actor Blueprint → Components panel +Add → Static Mesh Component → pick the asset in the Static Mesh field in Details → adjust the material, tick collision. Scene Graph's version maps across almost cell for cell:
| What you do in Blueprint | What you do in Scene Graph | Difference |
|---|---|---|
| Add a Static Mesh Component in the Components panel | Add Component in the Details panel, pick the mesh component | Same action; Scene Graph allows only one per entity |
| Pick the asset in the Static Mesh field in Details | Pick the mesh from the component dropdown (asset-generated components are overridden here) | The asset must be imported and the Verse code compiled before it appears in the list |
| Material Override | Material slots selected and overridden from the mesh dropdown | Same semantics: you edit this instance, not the source asset |
| Collision Presets | The Collidable toggle | Scene Graph's granularity is currently coarser; check the official docs |
| Set Visibility node | Mesh.Enable() / Mesh.Disable() |
You first need GetComponent[mesh_component], which is a failable expression |
| Five Static Mesh Components on one Actor | Five child entities, one mesh component each | The biggest difference: hierarchy moves from "a component list" to "an entity tree" |
That last row deserves an extra paragraph. In Blueprint, "one Actor plus a list of components" is flat, and hierarchy between components comes from Attach Parent. In Scene Graph, hierarchy is carried by entities natively, and components shrink into a thin list of abilities on each entity. The result: your scene structure ends up thinner and deeper than in Blueprint — more entities, fewer components on each. Building your first complex object feels verbose; once it clicks, you notice every layer has a much cleaner job.
You're building a car: one body mesh plus four wheel meshes. How do you structure it in Scene Graph?
Sources
Compiled from Epic's official documentation:
- Mesh Component in Unreal Editor for Fortnite (official docs) ↗
- Getting Started in Scene Graph in Fortnite (official docs) ↗
- Verse API: the /Verse.org/SceneGraph module (official API reference) ↗
Scene Graph is still evolving inside UEFN; the range of usable assets and the properties on each component change release by release, so treat the official docs of the day as authoritative.