Verse Wiki — the Verse handbook for Blueprint authors
Deep Dive · EXTRA

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.verse
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

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:

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.