How to change Terrain size without stretching mountains and roads?

I have terrain 500 * 500 size. I want to enlarge it to 500 * 700 or 700 * 700 (for example).

The problem is: when i change the size, it stretches my existing roads, mountains etc. How to avoid it and change the size by just adding new flat space to the existing terrain?

It’s the fastest way to do this.

1 Like

Is there way to make it with a single terrain, but not adding Neighbor Terrains as suggested above? I have 1696.575x2048.764, and I it’s critical to keep the shape, because it was made according GoogleMaps (initially was a mistake to take a weird scaled map, convert to glb and create a terrain from that object) and representing a real map, days and months spent to make it feel real in VR.
But now I need to make 4000X4000 map (will be sliced in 500X500, or smaller chunks using some tool), so I could create new square terrains to reach 4000 size, but I need to round the existing one before slicing, for example make my 1696x2048 terrain 2000X2000 (so add and cut a little), but do not stretch/move any landscape details, is this possible???

ps. Adding neighbor terrains also looks weird in my case, here’s screenshot.

at least one way would be,
manually copying terrain heights & data with script, into new terrain (requires making custom editor script to do that)

I think I’m in trouble with this terrain, because it was made out of object (using script Object2terrain) and I don’t even have data file, not sure how it works. Is there any Stitcher that can combine terrains into one terrain (so I can create additional terrains on the sides and stitch them all together)?

i mean you can read that current terrains data and manually copy into new one,
but i don’t know if there are any ready to use scripts for that…

May be understanding the logic behind “squeezing” and “stretching” will help me to create a correct heightmap. Will try to explain what I mean.
Here’s a terrain 1835x5000, and I want to make it 5000x5000 and keep the shape.

The heightmap raw image is 4097x4097 - so what I see on the rectangle terrain is a “squeezed” version of a square Heightmap, or heightmap is a stretched version of terrain, whatever ) Now I have to adjust the raw file, but how to calculate the correct size?
The best result I was able to achieve in order to fit a new 5000x5000 terrain is when raw image size: 1500x4097 (and canvas 4097x4097 of course).

Why ~1500 was the best heightmap width (out of original 4097) to fit a terrain with new 5000 width, instead of original 1835?
It’s just the same proportion between the original terrain dimensions and the heightmap resolution, 1835 is 36.7% of 5000 - this is the key.
So apply the same logic to the heightmap: 36.7% out of 4097 is 1503.599.

I created a simple excel sheet for all my terrains to speed up calculations.





Yeah my method worked, and I’ve created a single 5000X5000 (4097x4097 heightmap) terrain out of 5 completely different terrains and kept the landscape (you can see how those terrains looked like).

Basically I had to calculate the new sizes and positions based on them (you can see excel sheet screenshot), and after adjusting the size I pasted adjusted raws in the places they suppose to be on the 4097x4097 canvas.

Now There is another challenge - textures, because when I import new RAW into initial terrain (which is 1865x2253 “Terrain” in the center of the picture) all the textures stretched withing the entire 5X5k area.
UPD textures resolved! Exported splat map 4096x4096, changed size of the image = size of modified heightmap for that terrain, and placed it on the canvas 4096x4096, same position as terrain on the heightmap, keeping in mind heightmap up/down are mirrored (because heightmap size is 4097 so the same values).

Now, when I have a single piece, I’m going to cut the terrain lol, but this is another story (I will be using paid asset, for optimizing mesh, culling, cutting in equal chunks etc, so I needed a good square terrain)…





Don’t forget to take into heightmap resolution if you are changing the size. Also, I those are pretty big terrain chunks especially for VR, but it sounds like you might be re-splitting them later as part of your mentioned optimization workflow using a paid solution.

You also asked about “terrain stitching” …Nature Manufacture makes an asset called “Terrain Stitcher” (it’s $10 USD at the time of this post).

Yes, I was waiting for FlashDeal and just got the whole NatureManufacture’s bundle )

1 Like

I agree with their optimization approach to open world building. NatureManufacture is the real deal. I haven’t personally tried their newest version of world streamer, supposedly it’s more user-friendly than the first iteration. It’s got you covered on what you need for a VR world that size, including things like floating origin jitter and such which will definitely need to be addressed for first person on a world that size. Good luck, let us know how it goes!

Just one thing to mention - there is no goal to run my game as standalone VR application, I don’t think it is even possible to make a nice realistic open-world game for Oculus etc, it is a desktop VR only, and I’m trying to run it smoothly with at least my RTX3070, and already have not too bad results with other Forest packs with tons of vegetations… For example this is one of the areas, and it works smooth enough (hope will be even better, because I only used LODs for optimization before, no culling):

upd Want to upload a couple of screenshots from my VR project with NatureManufacturer Demo scene, looks stunning and runs smooth!



My 7 square kilometer city core asset is being tested soon in a 32v32 multiplayer VR game. Sorry for my confusion your username threw me off and I made an incorrect presumption.

Use per camera layer culling instead of LOD’s. Vegetation creates alot of overdraw. Also, there are very few assets out there that are remotely any where near being ready for VR. I don’t want to publicly diss any assets for their optimization but if you want to pm an asset store link to what you’re using, I can tell if they are optimized at all usually by just looking at the package contents and whether or not they use atlases.