Mesh Types

A URealtimeMeshComponent renders whatever URealtimeMesh object you attach to it. RMC ships several concrete leaf classes, each tuned for a different way of authoring geometry. You pick one, initialize it on the component, then drive it with that class’s API.

You attach a mesh with the templated InitializeRealtimeMesh on the component:

// Owner is a URealtimeMeshComponent
URealtimeMeshSimple* Mesh = Component->InitializeRealtimeMesh<URealtimeMeshSimple>();

The class you name here is the whole choice — everything downstream (how you supply vertices, how you update, whether there’s CPU-side storage) follows from it. This page helps you pick; each type then has its own page with the full API.

---

The family at a glance

Type	Class	Module	Author geometry with	Use when
Simple	URealtimeMeshSimple	RealtimeMeshComponent	A StreamSet you fill with the builder	You want full control and the best update paths. The primary, recommended type.
Procedural	URealtimeMeshProcedural	RealtimeMeshComponent	Parallel TArrays (CreateMeshSection)	You are migrating from UProceduralMeshComponent and want a near find-and-replace port.
Dynamic	URealtimeMeshDynamic	RealtimeMeshExt	A UDynamicMesh / FDynamicMesh3	You already work in Geometry Scripting / the GeometryProcessing library.
Constructed	URealtimeMeshConstructed	RealtimeMeshExt	A generator resolved from a config struct	Geometry is produced on demand from parameters, with no CPU-side mesh kept.

Simple and Procedural live in the core RealtimeMeshComponent module (always available). Dynamic and Constructed live in RealtimeMeshExt and need that module added to your .Build.cs — see their pages.

---

Choosing a type

Start with Simple. URealtimeMeshSimple is the reference type and what the rest of these docs assume by default. You build a StreamSet with the mesh builder, hand it to CreateBufferSet, and later update it with UpdateBufferSet or the in-place fast paths. It exposes everything RMC can do — polymorphic stream layouts, polygroup auto-sectioning, LODs, and minimum-copy per-frame updates. See Simple.

Choose Procedural to migrate existing PMC code. URealtimeMeshProcedural mirrors UProceduralMeshComponent’s Blueprint surface — CreateMeshSection / UpdateMeshSection taking parallel arrays of positions, triangles, normals, UVs, colors, and tangents. It is the fastest way to move a PMC project onto RMC; once you’re running, you can adopt Simple for the sections that need it. See Procedural.

Choose Dynamic if you live in Geometry Scripting. URealtimeMeshDynamic owns a UDynamicMesh (FDynamicMesh3) as its source of truth and makes RMC a largely drop-in replacement for UDynamicMeshComponent. Edit the mesh with the GeometryProcessing API or Geometry Scripting nodes and RMC converts it to render/collision streams for you. See Dynamic.

Choose Constructed for data-driven, storage-free generation. URealtimeMeshConstructed holds a generator plus a per-mesh descriptor and (re)generates its geometry on demand — there is no CPU-side copy of the mesh kept around. This is the path the spatial streaming system builds on. See Constructed.

---

What they share

All four are URealtimeMesh leaves, so the concepts in Key Concepts and the component topics in Component Core apply regardless of which you pick: material slots, section groups and sections, LODs, and collision are configured the same way. The differences are purely in how you feed geometry in and what update paths you get back.