How are large terrain maps possible?

Help and Feedback Scripting Support
,
1

I have a map that is large smooth terrain map being around 20000 x 20000 x 10000 and am having issues with the place being too large to publish. I was wondering if people knew of methods to either compress terrain more efficiently or use some other method that allows having a massive smooth terrain map.

I have seem older posts like this one Pushing the limits of Terrain/Voxel Compression that show off compressing terrain and talk about being able to make a 20000 x 20000 x 20000 stud map which if true would make my map possible.

I have also seen smooth terrain maps like [Demo] Map of Europe - Roblox that claim to be 16 million by 17 million studs and was curious if anyone knew how this sort of map works as even though it comprises of different loading zones it never makes you change places as far as I’ve seen and was curious how that could be possible.

Any help would be appreciated as I’ve been trying to figure this out for weeks now.

4 Likes
2

The only solution I can think of is generating the map as needed for each player? There is no way 20000 x 20000 x 10000 map has to be accessible at any given moment?

3 Likes
4

You can store each chunk of terrain in a folder, and load, deload, and save chunks when needed. Just use a script for this.

3 Likes
5

There’s a multitude of plugins available for compression and decompression but that’s not what you need . It’s a map renderer that loads in the map based off of a users vision, not based off a render file which allows for extremely efficient experience

1 Like
6

Could you be a bit more specific? As far as I know using things like terrain region doesn’t change the file size and changing it from one terrain to 20 pieces of terrain also doesn’t change the actual file size the data takes up. I may be wrong on this so please correct me but as far as I know the only way is using things like read voxel and data stores which is what the link I posted talks about and is what I’m would like to know how he does it.

1 Like
7

A map render does seem like a good addition, but I don’t see how it would change my current problem of the place being too large to be published. While it sounds like it would make the place run smoother, I don’t see why converting the terrain into chunks would change the size of the file. I am rather new to roblox dev stuff, so please correct me if I am missing something or am saying something incorrect.

1 Like
8

Hi there! I am the OP of Pushing the limits of Terrain/Voxel Compression.

This is a topic that I have done a lot of research on! So from what I am understanding, you have a pre-designed terrain map that you want to publish but can’t. Following that logic, here is a recommendation if you haven’t tried them already:

If you already have the terrain inserted into your Studio, you could potentially use Terrain Regions! These cool little guys basically compress terrain into instances that you can keep in ServerStorage or wherever you want. Please paste the code below to get an idea of what the instances look like in ServerStorage:

workspace.Terrain:CopyRegion(Region3int16.new(Vector3int16.new(0, 0, 0), Vector3int16.new(100, 100, 100))).Parent = game.ServerStorage

The second solution I suggest involves a more tedious solution that, judging from what you have said, is a very complex topic that is not meant for beginner developers. However it is still a fascinating topic should you want to pursue it.

Solution #1 (the easiest)

Edit: I just read some sub posts after making this section. From my personal experience, it doesn’t hurt to try TerrainRegions. I know of many games that use this method and it is much more effective than saving the voxel data manually as these instances get stored using engine-made instances that don’t involve the bloat that you see if you are trying to save them with Luau.

As the documentation suggests, you would simply create a for loop of regions following the Region3int16 limits all the way til you reach your 20000 or so map size! Then what you can do is completely wipe the terrain from the map and only load in the chunks near any players! One way I suggest “testing” it out is by creating a copy of the studio and doing it on that one just in case you run into any issues or if the method doesn’t work :sob:.

If it does, your next course of action could be making a different place that holds the terrain part of your game. Then, make your edits on there and every time you are done, run the scrips and replace all your TerrainRegion instances with the new one! You can ever go as far as making it a package so you can simply have it update on the other game whenever it’s changed!

Solution #2 (a slightly harder implementation)

Another, more painful solution, would be to compress the chunks you already have. This can be done with BitBuffers. There are many modules out there that do this for you! I personally had mine made in-house due to specific specifications that I needed. However you may find that one works for you that someone else has made! A great place to start would be wally which hosts many community made modules of all different purposes!

Once you have your module and method of compression, I’d look into finding ways to store it. Some that come to mind immediately would be a set of Module Scripts for each chunk (that way you don’t put it all in one module script. That would take quite a long while to require). Then, you can easily require each one in accordance to which chunks you want to load! Another, much harder, way of doing it, would to be use DataStore. I say it is harder because you have to use primitive types (JSON types only) and base all of your data to be compressed enough on order for you to not go above the DataStore limit (this was the pain point I described in my post).

I also don’t recommend doing with DataStore because from what I understand you are not changing this terrain in any way during runtime. This is a great thing for you because it removes the pain of having to deal with DataStore limits.

In Conclusion

That is all the advice I can think of for now! I’d love to hear if any of the two solutions works as I am always fascinated when people find unique workarounds with the limited Terrain utilities we are provided.

Thank you as well for shouting me out in your post! I am glad that terrain compression is getting more attention!

I hope your project goes well!

2 Likes
9

Hey thanks for the in depth reply and sorry for this late response. I’ve been busy with school stuff this past month and haven’t been able to do much work on it. I did end up trying the solution one and used a script to turn the map into terrainregions chunks and when I turned that terrain regions chunk folder into a model file it was 200 mb while the original map place is only 160. I’m not sure if maybe I did it wrong but as far as I could tell from my testing it doesn’t seem to compress the data better than the normal terrain compression stored in the workspace.

I read over your solution #2 and it seems promising, but I don’t think I understand how to do it. I’ve never used a bitbuffer or Wally and after a bit of research it seems like unless there was a guide on how to do something like that, It would take me a long time to figure out.

Recently as I’ve been having less and less time to figure out compression, I’ve just been thinking that while I would prefer not to split the map into multiple places it might just be the simplest solution. I’ll try doing more research on bitbuffers and see if I can figure them out, but if I can’t I might sadly just have to move onto to researching how to do pretty seamless transitions in a map like [Demo] Map of Europe - Roblox.

I loved your response though and it has given me alot of things to research!

10

You can see when you play the Map of Europe game that it’s generating smooth terrain just in a small area around your character, probably locally, and using triangle terrain (wedgeparts) to render the terrain outside that circle, to some larger radius, and likely with larger parts and decreased level of detail the farther out it goes.

The smooth terrain and triangle terrain are likely using the same height and materials maps to store the terrain data. How exactly it’s done, you’d have to ask the developer about. It could be in Lua tables of course data that’s interpolated at runtime, or it might be pulling height data from an external source (e.g. over HttpService to a dedicated server). There have been several map demos on the platform that use HttpService to talk to geographical data services to download topographical data on the fly.

With smooth terrain, you have to limit the amount you have in memory on any given computer (client and server), you can’t just pre-generate enormous worlds and expect to spin up servers using GB of RAM each. Roblox’s smooth terrain compression is optimized for worlds that are flatish in the X and Z directions; large amplitude height (Y axis) variations are considerably more expensive to store. It’s pretty typical for smooth terrain chunks larger than 10k x 10k with lots of height variation to just cause the server startup to timeout or fail for lack of memory. You pretty much have to do large worlds like the Map of Europe does, just locally (client side) rendering the terrain around where the player’s character currently is.

1 Like