I’m developing a Voxel Engine to make a cube world. I’m trying to accomplish this using the procedural mesh componenet.
So far I’ve only set up some code to build cubes (actually untextured and without any physics). You can such code here: http://pastebin.com/8jqThv8e (Psyrain is the name of the project, Voxine is the Voxel Engine)
By changing the values x,y and z have to reach in the loops I can change the number of blocks I generate. Unfortunately trying, for an exemple, 16x16x256 it gets terribly slow.
What’s the problem? Is the procedural mesh not ideal for what I want to make? And what should I use instead?
Is my code just bad written?
Is my computer a potato?
Don’t create a separate section for each cube, you can just build the geometry (vertices and triangles) for all the blocks and send it all in one CreateSection call. CreateSection is expensive
You’re making 36 vertices for each cube. You only need 8 to draw a standalone cube. If you’re drawing lots of cubes in a matrix you need even less because you can share the vertices between the cubes.
At first I actually wanted to build them using just 8 vertices for each, but I don’t know what functions of the procedural mesh component could help me achieve this. I mean, is there a function which takes 8 vertices and returns a cube?
Or should so I take a few steps back and try to setup everything with, for an exemple, OpenGL?
EDIT: just realized I can effectively build such a function by calculating the 8 vertices and then build triangles from such vertices lol (if there’s still a better way, tell me please )
Yep The triangles array you fill with the Vertex array index, 3 entries for each triangle. So for a simple quad, 4 vertices, 2 triangles = six entries in triangles array.
Thanks for your suggestions, it has really improved, though with the values i’ve set to x,y,z (16x16x256, which I think should be the typical dimension of a chunk) it still is pretty slooow.
Am I still doing some expensive coding or whatelse?
You only need one UV/VertexColor/Tangent/Normal per vertex btw…
You’re creating 8 vertices for each cube. 16x16x256x8 = over half a million vertices, 750k+ triangles worth of data you’re shunting on the GPU, it’s going to take a while.
You can start by culling the faces you don’t need to draw…i.e. below ground or with adjacent cubes. Then look at breaking up the world into chunks. I haven’t built a voxel world through so I’m not sure what the best approach is. It’s quite possible that you’re better off creating instanced cubes (InstancedStaticMesh/HierarchicalInstancedStaticMesh).
FWIW I have build a heightmap based terrain generator and it’s tough to maintain a good framerate just updating 32x32 patches. IME updating a proc mesh component in realtime for a 3d world is going to require a fair bit of smart optimising how to chunk up the world.
You are generating all sides, wether they are hidden by other cubes or not. Before you generate each side check if the block thats on that side is transparent or not.
It depends on what game you’re looking at, Minecraft is indeed 16x16x256 IIRC. I personally use 32x32x32 or 16x16x16 depending on what I’m trying to do with it. I will say as far as I’ve tested the PMC (ProceduralMeshComponent) is usually superior to the ISMC/HISMC way of doing it, but the current PMC has a couple performance issues. I will add that the best thing to do is probably 1 PMC per chunk as unfortunately updating any section in the PMC with collision will force a complete rebuild of collision for all sections which is extremely slow due to PhysX cooking. You will for sure want to remove faces that are hidden by adjacent blocks, that alone will drastically reduce your poly count.
)
The triangles array you fill with the Vertex array index, 3 entries for each triangle. So for a simple quad, 4 vertices, 2 triangles = six entries in triangles array.