Ok so I’ve worked with multiple infinite procedural worlds and tried to work out how the generation works and trying to optimize my code to get the most out of my world as possible. Almost every time I’ve had performance issues and problems with keeping a steady framerate due to bad handling of the workload( and maybe some unefficient code ).
Now my question is about how you can implement a chunk-based system which generates the geometry for each chunk of the world over a period of multiple frames, effectively spreading out the heavy load which comes with creating meshes.
AFAIK Unity and threading is a bad combination and thus the only way of spreading out a task over multiple frames is to use Coroutines. These do help alot but I haven’t heard of many using them for this purpose, which makes me wonder if there are more efficient ways of doing it.
Also, looping through all chunks in the world to see if any needs updating is quite inefficient but I cannot come up with a good solution for doing it since making a coroutine check for updates every frame is not the way to go.
I strongly recommend to use threads in this case. However you have to keep in mind what things you can do in a thread and what not. The generation of the vertex and triangle index as well as uv and normal arrays can be done inside a thread. Once the data for a whole chunk is “ready” you will store that data (packaged in a class) inside a synchronised queue. Somewhere in Update or in a coroutine you will poll that queue for new items and simply grab one and create the mesh out of the data.
Keep in mind when you use MeshColliders the generation of those is horrible slow and can’t be sped up. If that’s your bottleneck you either have to use smaller chunks for the collider or use a different system for collisions. For a block-like voxel grid it’s usually better to generate single cube colliders for the visible voxels. If you use an object pool for the colliders the overhead should be minimal and you can spread out the enabling / repositioning in a coroutine.
I’ve even heard of approaches where they only generate colliders where any physics object is near. So chunks far away won’t have any colliders at all.
I’ve posted a simple example of how to implement a threaded job. However that was for a single job. When having tons of those jobs you might want to use a threadpool and a job queue instead. However that queue should be able to reorder it’s items based on priority. If you move fast across your world the priorities of those jobs will change.
Also use object pooling where possible to avoid unnecessary garbage generation.
Here’s a general information post about threads and coroutines, just in case.