Open World [Advice Required]

Firstly I don’t expect this thread to get much traction, but rather than fumble around like a presidential debate I thought I’d ask.

I have 76 [there WILL be more in the future] independent landscape >meshes< they already have all their heightmap files generated as .tiff files, clearly I should be using world partitioning for this the issue I have and can’t figure out how to get around is, how to import all the 76+ heightmap files into UE and move them about because most of the heightmaps overlap or merge together.

My current theory [method] is, load all the meshes in to blender, change the material to the heightmap file, and bake out one massive heightmap file!

For some reason I think there must be a better way, is there?

Currently the .blinder file is 2.3gb I estimate that by the time all is said and done for it to be around 6-8gb

Sounds like you might have a couple of different problems you’re going to have to deal with.

A big one is that all the height maps are going to have to be normalized to the same scale across all of them (i.e. whatever the highest point is across all of the height maps needs to have a white value of 1, and whatever the lowest point is across all of them should have a value of 0). If each heightmap is normalized to its own scale, you’re never going to get them to line up right in Unreal.

If you can manage to do that, the best approach from there is to merge all the heightmaps into one image file in an image editor and then import the landscape into Unreal. But if the resulting heightmap is super high res, you’ll probably run into the max landscape resolution limit and won’t be able to import it, and you’ll be forced to cut the heightmap up again and import separate landscape actors and align them manually (this may not be necessary any more in 5.4, but I haven’t tested it. I do have a project where I had six separate landscape actors created from 1m resolution USGS heightmaps and was able to line them all up, so I know it’s possible to do that way, but it was a real pain)

Umm, that heightmap 0/1 thing is because the height maps are a .tiff file, and yep that is an issue oddly the landscape meshs all slot together quiet well as long as one has the patience to line up a vertex to another on the overlapping mesh.

Keeping mind I didnt mention the size of the landscape mesh or the height map for that matter if your apply todays standards I could forsee something getting over loaded.

I am not at my PC at the moment so can’t give exact sizes of the height map files but from memory 389x389 is the minimal, and maximum 800x800 ish.

As you can imagine from those numbers the height maps or the data im working with is VERY old as in 2001 old, about the time Guild Wars was first released.

Forget heightmaps in unreal.

Work directly with a mesh from blender - you do have to section it off ofc. It’s a standard practice and theres 1001 tutorials with different ides on how you should cut it to optimize for whatver.

Reality is, when properly using meshes it wont really cost, or rather, factor into the final cost, too much.

Still, you want to keep an eye on the bare mininum tris cost of the final occluded scene. The less it is, the more items you can add on screen…

You definitely will need to introduce LODs to all the mesh pieces. For rather obvious tris count overload reasons.
Blender’s Decimate is pretty good at that.

Running a combo of Angle based culling and other similar options that turn your mesh analytical are a great starting point on this.

Then you need to make sure that LOD0 is convex and provides a decent convex hull to copy for collision that matches up 1:1 or just about.

With all that done for each and every slice, you bring them to the engine and fill a blueprint, add a hierarchically instanced mesh component and load up the different parts you need.
Hism will further help reducing the paint/instance cost. Also helps with culling/occlusion somewhat.

Following all these parameters you should always have around 120fps even when looking from one corner of the map to the other (which depending on howmany total drawcalls it is can be really taxing on the gfx).

Like everything you have to find that happy medium of Tris count to Draw Call count to MS render time to Look.

Doesnt really matter if your landscape has different “levels” as in heights or caves or whatever else.

You can force things to load/unload manually which is probably the best way all around.
Or you may even be able to levarage some of the new sh*t like data layers for it - using anything past 4.26 is probably ill adviced still.
Depends on end goal and final release date.

Also, you may as well start right, pull whatever engine you want from source, build from source and forget about ever updating it, so you won’t have issues in the future when they remove of fumble or flat out break whatever feature they’ll break next.
Seriously, with epic you are basically playing russian roulette with a fully loaded revolver everytime they push anything out :stuck_out_tongue_winking_eye:

Also, you may as well start right, pull whatever engine you want from source, build from source and forget about ever updating it, so you won’t have issues in the future when they remove of fumble or flat out break whatever feature they’ll break next.
Seriously, with epic you are basically playing russian roulette with a fully loaded revolver everytime they push anything out

I actually understand this frustration but from a different point of view, I’ve never really had any issues running the latest builds and getting what I want out of it but for the one issue that allows me to relate, that being YouTube and or in general tutorials they are sometimes completely wrong, most of the time left and not updated, I don’t hold the tutorial creators at fault but the revolver that someone else was holding when the bullet was fired. If not fixed I can for see that it’s actually the glitch in the giants armor that will someday be part of what makes him fall, you cannot have a monolith of an engine such that unreal engine is and constantly have a moving targets, it’s the constants that allow people to create content to help others along their path, that in turn gives a product more value.

[back on topic]

I shouldn’t really be posting videos of what I’m actually up to which of cause makes things problematic (clue in my 2nd post on this thread). (happy to PM video links though if you’d like)

I think I’m just going to have to bite the bullet and glue the heightmaps together, as I don’t trust blender to output a heightmap from the mesh that is equal to the original source material, as too low/high the mesh objects that cover the map will float too wide and they won’t be in the correct x,y position.

Blender is better and more precise than unreal will ever be.
You just have to set the scale correctly and use the same normalized heifhtmaps or the correct setting on each individual heightmap.

This YouTube video helped a lot;

To create a decent heightmap from something that is quite immense in scale.

8192x8192 and unlikely to get smaller.

Oh boy, that’s a mess.

I’d definitely recommend splitting those two islands off into their own heightmaps and importing them as separate Landscape actors.

Id probably do that a LOT more than just those 3, but since I need to utilize the space around the heightmaps and the hole(s) in them (basically to build up mountains) for the exceptions of ocean shore lines, lakes and rivers etc.

You could say the project is basically planet building from a certain point of view I suppose, also to add to the ‘mess’, there large parts of map that requires going under the map to install a dungeons etc.

Ive imported a test heightmap the one above into the landscape in ue5 seens to be working well @ 120fps so i maybe doing something right.

I doubt it.
Unless you are making split meshes and importing something with a known tris count and proper LODs you are doing it entierly wrong.

But you can probably go on working and then start from 0 again when you realize why.
Nothing wrong with learning things the hard way.

Actually its working out just fine, just put the first map textures on, brought in the first few mesh assests, and discovered it was ever so slightly off scale x and y, which means rebuilding the map again, oh yeah even added the ocean in too.

So at this point it doesn’t look like the wrong way, im sure as heck not building the entire thing in blender.

I’m beginning to see your point I don’t think it’s a ‘failure’ just yet though or at least I didn’t fail lets put it that way, the problem is it didn’t work the way I expected it too. (I expected to be able [in editor] load and unload areas pop stuff into data layers and adjust the distance at which one can view etc. But since you cannot effectively unload/load areas of map to keep the engine running in a usable way it pretty much breaks everything, why am I unsurprised .

Oh this is why “epic you are basically playing russian roulette with a fully loaded revolver everytime they push anything out”

Are you [beeping] kidding me? : World Partition Regions Won't Unload: How to Fix — Mason Stevenson - Tech Art – fails on 5.4

The whole new landscape stuff has been nothing but complaints of the it don’t work kind since inception.

Epic buries or hides most of the complaints, leaving only visible forum posts of fixes and improvements (also the posts do just get buried on their own because what can someone say to “this don’t work” - its epic made, ofc it don’t work…).
They do so maliciously as to give people - namely 10cent - the very wrong idea that the engine is “perfectly fine and functional” when it really isn’t.
It has not been fine or functional since the first botched release of 5.

Landscapes particularly have remained effectively broken since the 4.18 update in which they enforced the LODs to transition based on screensize - in order to match everything else -instead of leaving them distance based.

Do with that as you will.

Also, thinking about it, Epic and Disney are pretty close as far as corp culture.
Maybe we ought to compain that the landscape is the wrong gender so they fix it or something.

I’ve seen people reporting the ‘regions don’t unload’ issue, but I’ve only run into it maybe once or twice myself, and either restarting the editor or rebuilding the World Partition Minimap (which forces the level to reload on completion anyway, so I might have misattributed what happened) has always fixed it.

My current project uses an 8km x 8km landscape and everything works fine (and my dev machine is a Ryzen 3900x, Radeon 5700xt and 32 GB ram, so I’m arguably a bit below spec for UE5) .

One thing that I found really useful (both for general streaming performance and HLOD management) was creating a new runtime grid that is aligned and sized to the landscape streaming proxies and assigning the proxies to that grid.

I’m also pretty sure that the Streaming Proxies can’t be in different Data Layers than their parent Landscape Actor, so trying to use Data Layers to manage your landscape’s in-editor memory usage is the wrong way to go.

You are working on the equivalent of absolutely nothing.
Try some 400km squared setups and talk about things after…

Data layers wise, just don’t use landscapes at all… problem solved :wink:

Mine is 4km although the ‘actual’ map size is likely 4-5 times that size, having said that it’s built on mesh data that was built in 2005-2007, by todays standards you couldn’t even install windows 11 on machines that old, I haven’t done anything ‘super nice’ to them either just loaded them into blender built a heightmap shader for them and joined them up.

i9-12900KF@3.20 GHz 32Gb Ram and a 3080TI

I’m also pretty sure that the Streaming Proxies can’t be in different Data Layers than their parent Landscape Actor, so trying to use Data Layers to manage your landscape’s in-editor memory usage is the wrong way to go.

I’m not as far as I know, I presumed data layers wasn’t for landscapes from the get go, they I think are supposed to be use for mesh objects that one might put on a landscape in order to only load in what is needed.

image
Seems loaded to me, even though it shouldn’t be.

** Loading it into an entirely new project however suddenly makes it work… weird.

Only thing I can think is double check that ‘Spatially Loaded’ is enabled for the landscape and all the proxies.

The only other time I’ve seen things not unloading is when their data has been improperly changed (like when i pin an HLOD actor, change something in its material and save it won’t unload the actor when I unpin it), but even then after I reload the level everything behaves as it should.

Guess you never ran world origin rebasing.
You would have seen similar issues in a ton of different situations.

The fact the EDITOR does not unload doesn’t mean that the final packaged end product will also work the same.
Which is why you have to periodically bench test…

Data layers are useful to introduce verticality into the loading system.
If you couple them with a custom octree loader you can get end products that really work… otherwise verticality is just not something the epic systems offer at all.