So I’ve going through the process of creating a game similar to that of Minecraft. I’ve gotten the terrain generation sorted but am running into the problem of lag. I wonder if there is a way to ‘merge’ other actors’ meshes if they are close to each other as having multiple actors with a separate mesh causes an insane amount of lag.
1 Like
If you’re going to make a minecraft-look-a-like, you will have not to spawn blocks individually. In Minecraft’s code, there is one instance of each type of block abstractly spawned (not physically, I mean). On the other hand, there is a grid structure made of chunks containing short and simple data about blocks supposed to be in each place. Then, on each frame, the game is computing which faces it has to render, based on face culling (to make it simple: every face facing another full block shouldn’t be rendered).
In UE4, for the same purpose exercise, I made a Chunk actor which contains an array of Block structure. For now, the structure is only containing an ID or a class reference to the block it’s supposed to represent. Then, when chunk is loaded or blocks are individually updated, I compute again the faces that should be shown and I spawn staticMeshComponent inside my Chunk actor at the correct location with corresponding texture.
This way, I go from 1616256 = 65 536 actors per chunk, each generating faces, to 1 actor and on average 1000 simple static meshes. For the sake of collision engine, the benefits are even greater.
Here is a representing picture:
https://puu.sh/Bqq0h/8461ad2fe8.jpg
Hi Tomlabete, that sounds like a good method. When you say that you compute the visible faces and spawn staticMeshComponents, do you mean you spawn a staticMeshComponent for each visible face of the block (eg. 1 static mesh for the top face, 1 for the left face, etc)? Thanks
Yes I do, that’s it!
I spawn planes for each individual face. But later on that same project (after answering you) I had an issue. I was trying to spawn many chunks (~200, which isn’t much compared to Minecraft far render distance) and lag problem came back.
Actually, I managed to solve that problem by reconsidering from the ground how I was doing it. I downloaded the RuntimeMeshComponent plugin (which is an extension of the native ProceduralMeshComponent) and now I define a 3D-array of vertices and UV-vertices, and I draw faces by updating the faces array (where you give 3 vertice’s IDs to get one triangle, so you need to give 6 vertice’s IDs to make one square face) of that mesh component’s sections.
This was becoming quite complicated actually and this is about where I stopped this project as it was only for the sake of the exercise. I made a prototype in which you can have as many full-cubes as you want, and place them in various orientations, but then I understood that I would need a complete architecture redefinition to make all the half-cubes, stairs, 3D models of Minecraft compatible with my system.
This could definitely be done though, and I really want to work on that again later 
Hence my encouragments for you!
Thanks for the info! I’m not currently working on a minecraft-like system, more so just researching how to do procedural terrains in general. ProceduralMeshComponent seems like a good way to go, I’ll check it out.