koobas.hobune.stream
Creating a height value based on noise optimized
Hello! Im trying to create a procedural terrain with noise. I'm still not completely sure how 'infinite' terrain is done though. What I did was create a method that I could pass in the x and y cord of the vertice and the chunk position for the offset. This method returns a height value based on those values with perlin noise. This isn't simple perlin noise though. I have set it up with octaves, frequency, and amplitudes as well as scale and other values to make this terrain look amazing. But when the player moves (the chunks update around the player which means calculating a height value for each vertice again) it kills the fps. I have it set up to only update vertices when the player moves a chunk in a direction. This does work but not very well so I need help figuring out how to make this optimized. This is the third time re writing this code. The first time was just simple perlin noise which was not detailed enough. The second time I created a whole float[,] with the more complex perlin noise and it worked but I had trouble getting it to be infinite because I created the size of the map based on render distance so every time the player moved I had the same issue but worse. I tried making a bigger map so it wouldnt need to calculate it over and over and it worked but it wasnt letting me create a map big enough for the infinite illusion because of ran out of memory errors. And then now im here getting ONE noise value per vertex when the player moves and I guess now that I look at it we are still calculating the whole chunk. I'm stuck and I'm not sure what to do. Any help is appreciated thanks!
Runtime noise generations always need performance, but there are some things you can try. As you have mentioned, you have already tried reducing the update frequency by calculating only after the player has moved into another chunk. There are a number of things to get through:
Try another (less performance dependent) noise library
Minimize the octaves (with this option you are sacrificing the detail)
Use a coroutine for calculating, that way you can slow down the calculations but keep some framerate
If you are creating the chunks based on a render distance variable, do not move and recalculate every chunk when the player gets to a new chunk. Only move the chunks that are left behind, and recalculate their height. For example: if the player moves one chunk to the right, move a column of chunks from the left side to the right, and recalculate them.
You could use multiple threads but it's more error-prone.
That's all i can come up with. Hope it helps.
I'll give this best answer because though I haven't tried anything you've suggested yet, I can see how there isn't much I could do other then these few things which should help with performance to at least be not as noticeable as it is right now. Thanks and I'll keep you updated!
As for threading I think it's a great idea but I have no experience with threading. The last time I did threading it made cpu go up to 100% usage. Any good sources to learn how to properly thread safely? I mostly have trouble communicating with the thread to do something when the thread has finished its tasks.
