Terrain Optimization

I’ve been working on a terrain optimizer for our huge project. I managed to cut the entire file size of the terrain down ~36%, with some individual islands seeing reductions as large as ~57% file size reduction. This reduction is visually lossless.

Before and After

image

image

Whole place files
image

Individual island files
image

Rounding the occupancy of every voxel to clean fractions gives a significant reduction to file size, however it only really benefits load times. I found that this rounding has minimal impact on visual fidelity of terrain with fractions of 1/8 or smaller (f125 and f065 in the file list above). Doing this doesn’t benefit client memory because fractional occupancies are stored as fractions of 1/256 in memory ( see this blog post from @zeuxcg )

The real benefits come though from “filling” all of the terrain that is not exposed to the surface. This is easy to do by accident while creating terrain, and on our place I managed to correct 50,292,997 voxels which were not even visible. I believe this optimization should benefit memory usage quite a bit.

I have some other ideas for further optimization but I don’t currently have the time to continue working on this, at this point I think any further benefit would not be worth the time it takes to implement.

13 Likes

Does this affect Roblox’s level of detail stuff, where it simplifies terrain the further you get away from it? Filling in everything with regular grass was something which has come to mind, but I wasn’t quite sure how that’d affect terrain… And I’m not really a scripter.

That’s a rather impressive decrease in file size though! Surprised we can’t do something like this already with the terrain tools Roblox provides us.

LOD isn’t really affected, and there’s not really any visual indication that the terrain has been optimized. This purely effects terrain performance in terms of memory requirement and file size. I think it makes the most significant impact on mobile devices.

1 Like

I’m a bit confused. By saying you’re removing the terrain not visible on the surface, does that mean you’re hollowing it out?

1 Like

From experiments, removing the underneath of terrain helps reduce terrain memory usage, however it can be detrimental to performance. It’s a balancing act.

No, I’m changing terrain occupancy that isn’t visible to be 1, removing any fractions which are otherwise stored as fractions of 1/256

1 Like

I’m curious. What other optimisations did you have in mind? I’ve never looked at the raw terrain data but I imagine examining how the data is stored and how it is transmitted to the client might provide some insights.