Storing roblox terrain as parts/object/model

[771x44 (angel)]

I’m trying to store Roblox terrain (look picture below) in some type of folder, so the maps can restart upon victory/loss etc. in their original state (fyi there are shovels in the game which modify the terrain)

(^example creation using roblox terrain)

is there any way to achieve that?

[tnavarts]

You can do this with TerrainRegions, though it’s fairly expensive and awkward to set up.

For example, if you run this in the command bar (with the appropriate size of area you want to copy):

workspace.Terrain:CopyRegion(Region3int16.new(Vector3int16.new(-20, -20, -20), Vector3int16.new(20, 20, 20))).Parent = game.ServerStorage

You’ll see a “TerrainRegion” show up in ServerStorage which has a copy of the terrain in it. You can then use Clear / PasteRegion calls at runtime to juggle which terrain is loaded in.

[771x44 (angel)]

Define fairly expensive and awkward?
Is it performance eating?

[tnavarts]

• Expensive in that the terrain has to be re-loaded into memory from scratch every time. Compare with swapping out a scene made out of parts, where the parts already exist, you’re just changing what parent they have. It’s not wildly more expensive but definitely more expensive than swapping out parts.

Think of the TerrainRegion like a .rbxm file, it stores a compressed copy of the terrain data, which has to be processed and expanded to actually insert it into the scene.

• Awkward in that there’s no built in Studio tooling for working with the terrain regions. You can’t inspect what the contents are or easily swap them in while editing to tweak them.

Also if you’re actually going to ship something, don’t put it in ReplicatedStorage like I did in the snippet, it should go in ServerStorage so you aren’t doing unneeded replication.

[771x44 (angel)]

Is there any other method that isn’t so bad performance(memory)-wise? or is this the only way to do this?

[tnavarts]

That’s the only way if you want to swap out Terrain.

Well, kinda, there’s another trick you can use: Not actually swap out anything! If you have StreamingEnabled you could have both maps present at once, distant enough from one and other that you don’t notice they’re both there at once.

The downside there is that you’ll get larger amounts of floating point error thanks to at least one of the maps being far from the origin.

This is actually what a surprising number of games do, just move players somewhere else and pretend that a new scene loaded rather than actually loading a new scene.

[771x44 (angel)]

@tnavarts

you could have both maps present at once, distant enough from one and other that you don’t notice they’re both there at once.

wouldnt that be quite impactful on terrain wise maps? (as i do)
I know that’s a really good way on maps that are made out of parts/meshes and don’t change it’s shape; but I’d have to have atleast 50 of terrain maps, as players would modify every map differently, and I’m not sure what could I do when the maps run out (eg. if the session is long enough to shuffle to the 50th map)

[tnavarts]

@771x44

wouldnt that be quite impactful on terrain wise maps? (as i do)

Only if you’re bottlenecked on server memory.

If you have StreamingEnabled (with StreamOutBehavior = Opportunistic) and the maps are far enough apart player’s devices will only ever stream in one of them at a time.