I have a really large smooth terrain map, its pretty much solid all the way through. I am wanting to make a lot of caves and hollow areas inside, so … will hollowing out areas ‘improve’ load time, or render time, due to the fact there are less voxels? Or will the hollow areas ‘stress’ load times and render times, due to RLE and the fact that there are more ‘faces’ on the exposed voxels?
I’m not sure what the terrain engine values more… more voxels, but less faces, or more faces and less voxels. How bad of an impact on loading would a more broken terrain cause?
Is there anyone with any actual knowledge of how this is handled C-side, that might know? Yes, I’m sure as in all things, you trade something for another, most likely you trade load time, for render speed, etc… However, just as the post above, this is a guess, and I would really like to know how the actual terrain code treats hollow areas, because if less voxels is all that really matters, I would hollow my whole island.
Not 100% but before the LOD system, it was just that more terrain made it lag more. Now, it’s more about how much memory it takes up rather than how many triangles it takes to render and all that. Hollow is probably better.
AFAIK the rendering stress is based on the surface area, but memory size is based on amount of chunks (?).
So hollow terrain would actually strain the rendering system much more, as it has to render the surface inside as well.
Hollow wouldn’t really save much memory either, as you’d need a large empty space for it to make any difference.
I’m just guess on that chunk stuff, as I haven’t looked into it much, but the rendering is definitely based on surface area; although with LoD I don’t think the rendering cost is as big a factor.
In truth, it depends a lot on the character of the holes. Long tunnels can be practically free (no more costly than solid filled baseplate), or they can be horribly expensive in both file size and load time, it depends on how irregular you make the surfaces, and how they align with the voxel grid. If you can make stylized caves using mostly entirely-filled or entirely-empty grid-aligned voxels, and hide the regularity by using rough materials like rock and basalt, and sparing use of actual irregularity, you can get something that performs well and doesn’t make a huge file. Such a creation must be roughed out by script or Part-to-Terrain, not brushes. The pathological scenario is a map full of voxels with all different partial occupancy values (not empty, not full, not all the same level full), such as you would get from filling a region with occupancies on the open interval ]0,1[
Here, for example, is a “map” I made with A LOT of holes in it, and it’s a 592k file despite having 16 times the smooth terrain surface area of Jailbreak, and almost 40 times the total extents volume. It’s a 4096 x 4096 x 4096 stud Menger sponge (well, a variant anyways), and it is not problematic for performance in any way. In fact, it’s highly compressible despite the apparent complexity.
Thanks for the details, that is really interesting, I didn’t think the partial voxels made much of a difference, but once you explain it, and think about it, yeah they would increase data storage, probably increase the complexity of the rle, and have more render processing due to more calculations.
In my case, I was wanting to have lower load times, its a huge map close to 2048 voxel x and z with about 1000 voxels y. and very smoothed. I think after reading all the posts, once I carve a few caves, I will most likely run a script and remove all voxels inside the terrain, leaving maybe a 5 voxel thick border with the outside, but now I will be sure to carve that inside using grid aligned full spaces.
In a nutshell, partially-full voxels account for most of the storage space requirements of a typical map (one made with the terrain tools, and not deliberately optimized with better compression in mind).
