in the last few days I was tinkering with the ProceduralMeshComponent in C++. The idea for the time beeing is to create a Minecraft like world.
So the first thing i tried was to create a simple cube, so i put together 8 vertices and 12 triangles in order to create my cube. Then I tried applying the UVs on these 8 vertices. All went fine for the 4 front faces, uv’s were applyied correctly, but on the top and bottom faces the uv’s were broken.
After some more tinkering I found the KismetProceduralMeshLibrary with some really handy functions, on of those beeing the GenerateCube function.
After applying the function the generated cube was perfect (what a surprise!). So I decided to debug the outcome of the Kismet’s function and found that it actually create 24 vertices for the cube, not only 8. This means that there are 3 duplicated vertices on the same spot.
At this point a few question arises: is this the correct approach (I assume yes, since it is a core function)? But most importantly, once I provide the array with the vertices to the PMC, are these welded, or are there still 24 vertices once rendered? The generates mesh is closed, or all faces are separated and thus on their own “mesh”? Lastly if the vertices are not welded, isn’t this a performance issue? Imagining a world of 100 cubes i would have a total of 2400 vertices instead of 600. I think that something is not adding up here.
I wrote a routine that builds a cube - it finds the common vertices and in the RawMesh it has 8 vertices, 12 triangles but after building it turns to 24 vertices. I’m guess it’s an engine thing.
The amount of difference is so small I don’t think it would ever be noticable - even with 10’s of thousands in the scene.
Regarding the face UV issue - it sounds like you were winding the vertices in the wrong direction, just change them around to fix it.
Thank you for your reply, I think aswell that it could be some rendering thing of the engine that requires a dedicated vertex for every face, maybe due to some weird UV behaviour.
I guess i will take this into account while generating my mesh, and triple all the vertices.
So I did another bit of research. I exported a cube from blender (8 vertices), loaded it as static mesh and throw it into UKismetProceduralMeshLibrary::GetSectionFromStaticMesh(). End result: 24 vertices in engine.
At this point it is clear, as you mentioned, that it is an engine thing. And I believe that my UV issue was due to the lack of vertices (with only 8 vertices I don’t think it had enough information to calculate correctly the uvs).
I don’t know what the engine does underneath in the rendering part, but I assume that the extra vertices are needed in order to map the UVs and are then welded during rendering (at least I hope so).