So for the past 6 months, i have been working on generating planets with marching cubes and mesh interpolation. Recently, i got it working, but it causes an insane amount of lag. I know its from repeat loops (if i did my calculations correct, for each chunk, which is 16 x 16 x16. it is looping around 90 thousand times).
so for testing,
try to avoid creating new vectors or arrays inside loops and actually using float/ints directly could be much faster too,
check this video (starting from 28 - …) for more about that:
Mathf can be slower than Math, could use another thread instead of coroutine, divisions can be slower compared to multiplying, regular Random might be slower than alternatives…
I changed a few things, and it didnt change much. Currently im trying to generate the world in one frame, which takes 10 minutes. Either I optimize it like crazy, or i might be able to add some form of fast chunk loading.
Edit: I just found out i had the world size on a big number. Turns out it optimized the generation a very large amount. instead of 10 minutes, its now 30 seconds.
First of all… what am i missing here? 16^3 is 4096, what do you mean with 90.000 iterations?
How large is your world? If you are generating real-life-sized planets in realtime, like No Mans Sky does, you will have to include several levels of detail into your generation code - and likely even determine chunk size dynamically using Octrees, such that generating the basic planet shape can be done increadibly quickly, and the closer you get, certain chunks start to become more and more detailed.
If you only need to generate the world once, the generation time does not really matter too much. If you only need one such planet set, you can even pre-generate it and save the models it creates. If users are able to generate these worlds you likely want it to be decently fast. You can threat it as a loading screen tho, so 30 seconds would still be acceptable.
I believe you need this to work in realtime however. If you are using Marching Cubes, you likely also want to be able to edit the world, and thus need to be able to edit chunks efficiently as well. Realtime procedural terrain generation is sadly one of the very few topics where you need to care about optimizations to get a proper result. You will have to multithread the entire thing to run properly. When i played around with Marching Cubes i did so in my DOTS learning project, where i heavily focussed on Jobs + Burst. Not sure i can recommend it, since it’s a steep learning curve and you could also do “normal” multithreading yourself, but the performance was there. If i remember correctly, i was able to generate 1 or 2 chunks of size 32x32x64 per frame at 144 FPS. It is worth mentioning that i did not really do anything with UVs in that project, which would cut into performance… but on the other hand half the time was spend on my horrible memory allocation/management. Anyways, if you need this to run in realtime, you should look into multithreading.
Since multithreading is a bit of a scary and advanced topic, you should certainly watch some guides of people doing something similar. I can recommend the procedural generation youtube series by Sebastian Lague. While he only works with heightmap terrain in that series, he covers a lot of increadibly important topics, like chunking, dynamic chunk generation and loading, LOD changes, multithreading and more.
currently the world size is around 8 x 8 x 8 chunks. I want to expand it to around 28 x 28 x 28 chunks, and i definitly did the calculations wrong for each chunk’s repeat loops. I didnt know that Sebastian Lague’s procedural generation covered those topics, so ill have to go check the videos out.
![8448461--1120556--Profiler [RECORDING PLAY] - 3D game go brrrrrrrrrrr - 2021.1.24f1 DX11 9_18_2022 3_41_07 PM.png](https://europe1.discourse-cdn.com/unity/original/4X/8/4/e/84e322b18cc47b8542298c258f81fe351cae1fc4.png)
