From ProceduralMesh to DynamicMesh

I have a ProceduralMeshComponent which receives a simple array of vertices, indices, normals, uvs, etc. I need to update the vertex colors dynamically and my understanding is that a DynamicMesh is preffered (more efficient). So I’m converting to creating a FDynamicMesh3 instead to insert into a DynamicMeshComponent.

Instead of a single call with arrays of all the data, the only way to construct such a FDynamicMesh3 seems to be to add the vertices one by one, and then set the triangles one by one. That seems a lot less efficient with many unnecessary function calls. There also doesn’t seem to be a way to reserve memory if you know the amount of vertices and triangles up front…

Anyway, I noticed the triangles can have a group id with an undocumented AllocateTriangleGroup which simply increases an internal GroupIDCounter. What are triangle groups and when would I want to use them? Or is that similar to the ProceduralMesh having different sections where each can have a different material?


I have the basic conversion done, but the UVs don’t seem to work… I simply provide the UV per vertex in AppendVertex with a range of 0.0-1.0, but they don’t seem to be working? I tried scaling them with a factor 10, 100 and 1000, but that didn’t seem to do anything.

Basically I do the following in BeginPlay:

FDynamicMesh3 mesh(true, true, true, false);
Multiple calls of AppendVertex and AppendTriangle to provide all the info.
UDynamicMeshComponent->SetMaterial(0, Material);

I do see the shape, and in the debugger the mesh.VertexUVs is filled correctly.

Not sure what’s going on, any help is appreciated.

After filling the FDynamicMesh3, calling

UE::Geometry::CopyVertexUVsToOverlay(mesh, *mesh.Attributes()->PrimaryUV());

UE::Geometry::CopyVertexNormalsToOverlay(mesh, *mesh.Attributes()->PrimaryNormals());

Seems to fix it. Not sure why this is needed.

Oh, and a copy of the VertexColors to the VertexColor overlay is also required.


I am facing the same problem. Calling AppendVertex over and over seems wrong. We really should be able to reserve the number of vertices ahead of time.