… is live on all platforms (desktop/console/mobile)
This update includes:
A level of detail system, that progressively simplifies rendering geometry far away from the character/camera. This results in significant video memory reduction as well as significant performance improvement for both CPU and GPU on all quality levels (the bigger the terrain or quality level, the more significant is the difference).
A new compressed in-memory voxel storage that reduces the amount of memory voxel data takes, the simpler terrain is - the more significant the gain.
Improved tiling method, which hides texture tiling artifacts on some materials (the most obvious example is that Grass is no longer covered in axis-aligned bright streaks).
Significant performance improvements for water rendering for some cases (mostly apparent if you use water but don’t use any other terrain materials).
Improvements in logic that computes whether camera is under water or not.
All of this is active in both client and Studio; the “ExperimentalTerrainLOD” switch currently has no effect. The first item is similar in implementation to the experimental LOD that was live for the past few weeks, although it had seen a lot of tuning and bug fixes; all other items are completely new to this release.
The LOD system relies on voxel-based simplification, and as such has an unavoidable problem: if you have a single-voxel-thick layer of a certain material (such as water), and everything else is Air, it may have issues maintaining the exact height across all levels of detail. Developers who use big single-voxel planes of water are encouraged to work around this by having 4-8 voxels of thickness instead of 1, depending on the water plane size. This is now comparatively cheap.
Please post here if you are seeing issues because of this update.
Does the compression of voxel data by chance improve voxel lighting update speed at greater distances? We were having issues where time of day changing continually over time would sometimes result in voxels being lit by a previous time for seconds (the timescale we were using was 20:1 if that helps).
I was generating terrain in Terrain gen 2.0 - Roblox - it had StreamingEnabled turned on, but I’m trying it without to see if I can replicate the issue.
EDIT: With streaming turned off, the issue does not seem to occur.
As far as optimization goes it feels great; had one example of a place going for ~25 FPS to a constant 59.8 now.
That being said, in areas where speed is involved it feels like it goes for optimization over looks a bit too much. Like at walking speed everything looks OK, but when driving a car at 200 studs per second the terrain is updating too much. Like can we have some way to adjust it to gain back some quality over performance if we want to, like increasing the range that terrain is at max quality?
I don’t get any freezes on this place. You are testing in player, right? Can you post the specs of whatever you’re running it on, and a profiler dump (press Ctrl+F6, run around until you get a freeze, select Dump → 512 frames, it will save an HTML file to C:\Users\username - PM me that)
Yeah, I’m thinking about possible APIs for LOD control. Could make sense to tweak how aggressive it is (I think there were some feedback issues with just driving that off quality level), could make sense to make the vertical distance affect LOD as well. I’ll look into that.
Btw, can you send me a link to the place that you’re talking about (with the car @ 200 s/s)?
Not sure what they looked like before. In general if you want to preserve the material at the top it should have at the minimum occupancy not less than the material below, and preferably have an extra layer or two for safety (not always required). If the islands were supposed to have a glacier (?) bottom with a thin layer of water, you should make the layer of water a bit thicker.
The reduction in detail for the ice water around the island leads to really big and irregular holes as seen in my picture above. The entire terrain loses it’s bumpy texture as the LOD gets lower as it moves out. The terrain in the distance also looks “mushy” because the lacking of crisp lines like the old island. I’m glad we got LOD but until I have more control over it, looking at the islands from the sky is going to be subpar.
this is fantastic. i use a big smooth terrain map for one of my games, and i was only getting around 20fps while rendering the whole thing, but now it’s a constant 60!
This is great in some cases, but it would be terrific if it was toggable and/or adjustable. Two games I’m working on look like crap from short distances because of it, and one of the doors surrounded by terrain gets filled in around the corners.
Right, so the water issue is likely because the water layer is very thin - few voxels, and I suspect low occupancy values. In general LOD code tries to maintain the “cover” material to some extent. This may be tuned a bit more - can you give me a place link? But otherwise I’d recommend making water a bit deeper, and/or using full occupancy values for water voxels where appropriate.
For example, right now you can easily mishandle occupancy for procedurally generated terrain - you can have a 3-voxel deep water with occupancy 0.01 in all 3 layers and it’d render fine and the difference between that and occupancy 1 would be just a bit of the adjustment in the water height. With LOD, the material under water can overtake water with this kind of setup.
In general I suspect that this entire island was very taxing on the GPU pre-LOD so obviously this becomes a performance-quality tradeoff.
I don’t think toggling is a good idea. You have to think about the ecosystem with the varied hardware - like, when smooth terrain came out Quarry started using it at day 1, and good PCs were able to handle it fine - but a lot of users reported basically running out of memory, mostly due to rendering. While rendering memory was optimized at some point it still is not enough without LOD.
Now, adjusting the LOD parameters could work. I’ll need to look into how much a developer can relax LOD settings without causing issues for low-end (within reason) systems, and whether this can be tied to graphics quality or not.
