Hi! I created a script for generating heightmaps with basic perlin noise and reusing terrains that are too far away, unfortunately when terrain is moved to a new position and gets new heights it appears to have weird shadows on itself, all baking is turned off and terrains are marked as non-static, shadows disappear when I camera moves closer to that chunk and It has to change LOD. Also I’m updating 2 terrains at a time and setting heights for their 257x257 heightmaps which causes 20ms, is it how it’s supposed to be or is it too much of a lag? I’m linking 2 screenshots, one to each problem.
Ok, for anyone with the same problem, shadows disappear after I flush() terrains.
I’m guessing you’re also using SetNeighbours() to make them seamless.
Your framerate is probably okay for most monitors (definitely not VR), 20ms is the same as 50fps, but it depends on the platform, hardware, user… Usually I try to stay under 10ms.
You might be able to lower it by modularising your algorithm and using multithreading, but if you’re unfamiliar with it then it’s probably not worth the hassle.
I can’t multithread it, from what I know Unity functions aren’t thread safe. I’m aiming for pc but it’s weird for me that just setting heights for such a small terrain takes 20ms(I’m sure it’s only this function because of deep profile). Btw it’s in form of spikes, not 20ms all the time, only when I set heights.
Nonsense! I’m doing procgen too and 90% of my world creation code is in different threads =)
I was going to use the builtin terrains, but I found them far too limiting. You can create your own using meshes but it’s a bit more in depth, I think the tradeoffs make it worth the while though.
Also a spike can often be more noticable than a consistent FPS at the same rate, in fact some games (and every console I know of) artificially slow their frames to keep it at a constant 30 rather than as fast as possible. Similar deal with VSync.
I’m going to move generation to compute shader but thanks for saying that I can apply changes to terrains on other threads, btw what I meant was that it’s in spikes but very frequent ones until generation is done so the game is not frozen but also not at 60fps. I thought about custom terrain system but I don’t know if I want to use mesh colliders and from what I know there is no heightmap collider so writing a custom one would cause me to write whole physics engine and in c# that’s not the best idea.
Hmmm, true, but I don’t think mesh colliders will have that much of a significant impact over terrains.
The reason I use mesh colliders is because heightmaps wont give you overhangs, which I wanted. Some calls are still made in the main thread after generation is done, but it depends on your implementation really. Terrains may be different, Unity doesn’t allow some calls to be made from other threads, but most of my work was done outside it because the Mesh class is reasonably happy no matter what thread it’s in.
Which calls are you making that are threadsafe? Currently I’m calculating my custom terrain meshes on other threads, and then setting to the mesh class on the main thread. I thought none of them were threadsafe?
Ah, nevermind, old code ;p
Just took a look back through the generation functions and it’s doing it all in my own classes, right up until the point the chunk gets loaded in which case it sets the vertices/tris of it’s assigned Mesh component.
Bah, here I thought I found the holy grail 
Sadly enough the builtin terrain system is a bit of a tire fire, I don’t think it has been updated at all in the past years. It’s still Unity 3 or smething. Your best bet will be to find an asset on the asset store (I haven’t used any so I can’t really vouch for them) or program your own using base meshes & meshcolliders/terraincolliders. If your terrain tiles are all the same size / vertex layout you can re-use the meshes as well, making it a lot quicker.
With compute shaders you get a bit of a different problem, which is getting any results back without blocking the main thread. That’s its own can of worms (native plugin floating around somewhere). Or work around it in terms of game design.