Is it possible to somehow update process of GeoMipTerrain? my machine is fairly powerful but LOD update still causes frame to get stuck. It is very minor but still noticeable.
I have a task that updates terrain lod according to main camera’s pos every second. In image you can see spikes caused by calls to terrain.update().
Enabling threaded rendering is great help in this situation because in standard mode issue is even more noticeable.
I somewhat doubt it - but is there a possibility to run terrain updates on separate thread maybe? Allowing update to complete over multiple frames should fix the issue.
I would suggest dividing a 1025 terrain into smaller ones like 257 , and manage the update by your own function.
my PC can’t update 1025 sized terrain and I prefer brute force, more work on graphic card and less work on CPU.
I use 1025x1025 terrains with LOD and no problems on a year 2004 computer.
Only call terrain update function when the camera moves say 128 units, depending
on the near far settings, just so that it loads in some higher poly count near the camera
when it really needs too.
For each of my 1025x1025 terrain ( actually loading 3x3 of those, making a total of 9 1025x1025)
block size = 64
near = 256
far = 512
min_level = 2
(I also have a camera far clip distance of 1024 since I have 3x3 grid of terrains)
When camera moves I call a routine to check the position with a saved position, when it moves
a distance of 128 units I update the terrain and set the save position to the current position.
I also do some things with task chains and tell other “threads” to run if they need to.(force_yield)
So if you want to play with your larger terrains with GeoMip LOD, try out the above settings and
be sure to not call the terrains update function all the time.
increasing minlevel is in fact not a solution of improving performance, but a way to increase speed at the cost of terrain detail.
if minlevel is 2 on a 1025 terrain, the terrain looks the same as created with a 257 heightmap,(only need to scale the node by 4) and cost more memory for storing vertex data. so why not shrink the file with image editor?
for me, minlevel is a way for temporary speed up in dev progress. so I don’t need to prepare a smaller image file on disk, only modify the script then the app loads quicker.
actually bigger problem now is border stitching.
I read in another thread that fixing this takes tuning block size and min level, however by doing that it pretty much leaves me without very detailed terrain. decreasing block size in order to keep min level as low as possible hits performance real bad. is there any other solution to make borders stitch properly? and what is real cause behind this weird stitching at all? Tiles of terrain are of same size, this does not quite make sense.
The border stitching is a hack to make the different terrains align without visible seams. It wasn’t designed to work perfectly, but the terrain system would need a good overhaul in order to make proper stitching possible. It’s been on my todo list for a very, very long time, but unfortunately I won’t have time to get to it any time soon.
The only solution to make the stitching better for now is to change the block size, I’m afraid.
I use stitching too and I had to make sure I had a 1 pixel overlap where the
terrains connect. I cut the 1025x1025 from 2048x2048 created with L3DT.
The stitching looks good. if there was anything else I did I’ll have to check
when I get home from work.
In L3DT under the ‘Extensions’ menu there is a option ‘atGrowTilesByOne’, which I use to get the one pixel overlap. Works pretty well, means you don’t have to crop or mess around, especially if you are using the mosaic option to render lots of images.
