I have created up to 32km x 32km 1024 sq km with just a grass foliage auto-material.
It’s usable but things really start to get heavy at that size.
The maximum that my computer can create before failing is 44km x 44km.
I run out of video memory on worlds larger than that.
R9-5950X, ASUS ROG X570, 128GB DDR4, RTX-3090 24GB.
The old system only runs out of video memory on import when you have the world mini-map open.
And, you can batch blocks of tiles to create larger worlds.
The largest to date was 244km^2 and it was working off a 1080ti.
Claiming there are limits due to hardware is nonsense.
There are limits due to knowledge.
If i understand your measuring correctly, this is partial nonsense too.
You use impostors, not the landscape when the distance is greater than 500m or so.
The only situation in which landscapes irrevocably cauase perfromance issues is when you sit at the intersection of 4 of them and all of them are actually loaded in memory at rhe same time.
As such, you can benchmark your player’s worse possible performance by keeping 4 levels always loaded.
Thats your worse possible baseline.
I’ve been sitting on the sidelines of this conversation watching for days. I haven’t seen much discussion on optimising tile sizes. Years ago I wrote my own landscape system that used octrees to load in landscape chunks, each of which used roam to reduce the poly count based on distance to observer. While things like roam are a waste of time these days, streaming in tiles still needs to happen, but, I’m unsure as to what the best approach is to tile sizes. My understanding based on reading the docs is that all the object vertically aligned to that tile bp’s, etc are also loaded in too, so the tile size we select should be 'big enough so that all triggerable actions still work, but no bigger.
Is that the right approach?
The reason I ask this is that I need to assess whether starting with say a 2k tile is acceptable and whether I can slot that in to a bigger WP map later on or whether the whole map needs to be defined up front like a stock 8k x 8k landscape.
I’m building a high density cbd citiscape in the middle of a terrain and I’m concerned that the landscape will be a load and even though not seen occlusion may not remove it sufficiently. Happy to eb told to go read some other doc if this si well covered elsewhere.
By “old system” I assume World Composition?
This is a UE5 thread, we are discussing World Partition.
I am aware that tiles can be loaded in batches with World Composition, and arranged in the World Composition window.
That still doesn’t get around the fact of total heightmap sizes and total project sizes, which become unrealistic for the majority of use when larger than about 64km x 64km.
Especially for distribution of average retail games, or something created or ran on the average Steam Survey computer system.
Creating 1000km x 1000km worlds becomes unrealistic for the majority of people.
The proper term is sq km.
LODs have a render cost.
Large open worlds typically have a 5km or greater view distance, so 500 meters is nothing for distance.
What size terrain are you creating?
World Partition defaults to a 511x511 Component, with automatic sizing, so tile sizes are not the same setup as World Composition.
There is no such thing as optimal with the engine.
5 or 4 alike.
You have to do the math to balance how many drawcalls you want wasted on landscape.
Based on that, you pick a tile size that can work.
1km^2 is a decent size tile, but if you need 200km^2 total, you’d be loading in 200x200 tiles / impostors.
That’s 40k drawcalls just on “background”.
The only ok thing about the system is that the size doesnt really matter when you sculpt and export the PNGs for height and painted layers.
Making it possible to change direction after starting with minimal loss and just more work.
Start by figuring out your overall size, split that by 8k (max size) and see how many drawcalls it nets.
Then you just quadruple the number to get the total for 4k, and quadruple it again to check 2k.
Chek into the procedural generation that was being worked on / showcased a year ago.
Its probably much, much better than the landscape system would ever allow for.
Also, we professionals usually stay away from doing things in engine (being it has basically never worked well) - try Hodini for world generation for instance.
I have started the process of trying to convert a 60x60 km map of 12x12 tiles with 2017 res (not pow2, ik…). The 4.27 project was opened as 5.0, and now I’m loading the map. This first load took an excessively long time (~1 hr). I imagine that will be the case for every load.
What is the consensus on these long load/conversion times? Will they get optimized away, or will we need better computers?
Between the 2 engines?
Just start from scratch in the new engine. Export your layer paint / height map, and re-import.
Who the hells has time to wait for stuff to load in 2022?
The (Aug 6, 2022) 60x60 km conversion took about 5 hours (64 GB Ram, GTX 2060, SSD). Far less than the 24+ hours that @noone experienced. That was a relief. I was expecting much longer.
Before the most recent 5.03 update, I had started from scratch and that was a complete wash. Plus, I’ve made some edits to the map anyhow. So this is what I’ve got. I’m happy with the result.
There are other issues now, but I was able to get farther than before, so there’s hope…
As far as I understand it now… and let’s face it, we won’t seriously know the real deal until Epic decide to update the “UE5 World Partition Technical Guide” in the UE5 documentation, but from what I’ve learned: Tiling is now out of the window because it causes inefficiencies, much better to import the terrain as a single large tile and UE5 will auto split that into it’s relevant sector sizes according to your settings in UE5 world partition details panel together with any further optimisation settings for HLODS etc, etc…
I do seriously suspect that much of peoples issues with World Partition are simply because they still don’t fully understand how to use World Partition or set it up properly in the details panel for what they want to do… and many so called World Partition tutorials being posted on YouTube are just compounding peoples mistakes because most of these people don’t fully understand what they are talking about…
This is why it is very important and “URGENT” for Epic to update the UE5 documentation Technical Guide for UE5 World Partition like now, yesterday, to stop all this supposition from others doing their own testing and mistakes and giving people the wrong and contradictory advices over and again… as is demonstrated in this thread in some cases.
Please Epics Technical Writers… this needs your serious attention to stop further confusions and misunderstandings concerning World Partition in UE5 for once and for all… Let’s have the UE5 documentation “World Partition Technical Guide” finally UPDATED from UE4’s “World Composition” & properly explained to us all, because it’s plainly obvious that no one, despite all the testing people have done, knows for sure what the real technical details are.
Hey there @AntiGravity, on the technical mod side we tend to help people with their Unreal issues, make bug reports if we come across them, and identify trends in the community to pass along information to help the team keep a pulse of the community.
We’ve identified that there is a consensus that the community would like clearer documentation, especially on the newer UE5 specific features and this post also confirms it. We definitely hear you, and I’ll be adding this into my report as well. We’ll continue to do our best to help the community!
It’s no secret we’re here to help, just want you guys to know we’re working to make the community stronger in every sense. 5.0 has brought a ton of changes, so I expect there to be some growing pains, especially with such a massive leap.
I’ll check in with the team to see what plans we have around updating the documentation—to be clear, in your reference @Hawk_UK, is it this page you’re referring to?
In the meantime, you can drop questions you have on World Partition in Ask Unreal Anything: World Building | August 23, 2022 at 12PM EDT, as the team will be joining us next week to cover World Building in general.
Please keep in mind, these AMA-style events are not technical support sessions for specific projects, but they should be able to address questions you’ve raised in this topic.
Hi Amanda… Thanks for the reply…
The page I’m referring to is the actual “UE5 Landscape Technical Guide to World Partition”, here: Landscape Technical Guide in Unreal Engine | Unreal Engine 5.0 Documentation
It’s still the old UE4 documentation relating to UE4 “World Composition” NOT UE5 “World Partition” but is flagged(at bottom of said page) as needing updating for UE5.
It’s the technical guide pages that give the required deeper technical information for us to fully understand and learn about the parameters and limitations of “World Partition” and not simply how to implement & learn how to use it within the editor, if that makes sense. Lol. 
I just feel that there is SO MUCH confusion regarding the limitations and implementation of, especially massive real world landscape data height maps, lidar maps etc, that this subject/issue seriously needs to be addressed and properly explained by Epic to avoid bad practices becoming the norm.
I will certainly try and attend the live viewing of Ask Unreal Anything: World Building | August 23, 2022 at 12PM EDT this should be very interesting.
Thanks Amanda!
Bad practices have been Epic’s norm since the start, particularly when it comes to landscapes.
The new system is just as big of a mess as the old system.
This is mostly due to wanting to add glitter on top of a compromised basis to try and maintain a “competitive” (yet fake) appearence of “being good”.
IF - and thats a big if - they scrapped and re-created the system following the best industry standards, then maybe the glitter on top (think of the water system with rivers or additive layers as the glitter) would serve a purpose and function properly.
If you want to have a look at how to do things better, you - and the epic team themselves - can probably have a look at the procedural generation put together by @MaximeDupart.
There are also a few keypoints that can be mentioned:
Overall, the landscape mesh needs to have the same ability to stream as any other mesh. Eg:
At runtime, the culling has to happen per tris not “per landscape component” as it currently does (at least in ue4.27)
at runtime, the material needs to be baked down and cost next to nothing while preserving the editor capibility.
In all versions of this engine, landscape materials have always been too expensive - to the point that to get 60fps on Kite Demo at 1080p which is literally nothing the landscape material had to re-use the R pin of the base color as a faux opacity over a dedicated texture.
This is wolly due to the way things are managed - if the engine baked down the map layers correctly on publish, then the number of layers one adds wouldn’t negatively impact performance to the point you have to manually bake things and work on 3 different level instances just to get to something you can publish.
It would also not run into the most common problem wouldnt it? Running out of texture samples.
Runtime sculpt is the required standard. During game play. Not in editor only.
Using voxels obviously; even if enough plugins that make your life better do exist.
The engine itself should just ship with a landscape system that does this out the door, and not require a plugin to do what is a “basic” indy dev requirement.
(One could argue it isn’t an indy requirement, but games that do it well are usually indy games!)
in engine spherical distortion options:
ESRI standards are standard for a reson. By setting the longitude and latitude you can calculate the needed distortion of a flat height file. This could be done automatically do for any map size stretching across multiple meridians/time zones.
Plus - the unreal system is completely flat, which is an issue in itself when attempting to create something real - like architecture visualization for instance.
Having the landscape actually curve properly via internal systems would already solve all architectural distance visualization issues - for one.
last and perhaps most important.
The landscape - and water - need to use an adaptive mesh by design.
Not a quad system which is then cut into the messiest and absolutely worst of the industry system for LOD reduction.
Doing this properly would:
A) eliminate the shaded triangles on lanscape which can also be seen in Fortnine - since epic only cares about that.
B) elminate calculation and visual shift issues when transitioning between landscape component LODs.
C) Allow localized analytical based density increase on high inclines, providing a good solution towards creating believeble sand dune environments / cliffs / about a million other natural landscape features.
D) adopt a system which has been the standard for 3d rendering since 2006, in 2022. That alone should be a reminder of just how dated the landacape system acrually is…
Sure, updating the documentation would be useful - but it really isn’t critical when the whole system needs to be overhauled…
As for updating the documentation: It sure is indeed critical for Epic to do so when we have multiple examples of contradictions leading to confusions for readers in this thread alone from those who think they know what they are talking about when they actually do not!
I think many people who have posted in this thread need to read this and properly understand the implications, because so long as you never expect to load in all large terrain data at once then you can work on individual sectors till one has finished the whole given that at runtime only a very small part of the whole map will be streamed in at any one time thus allowing for massive open world maps to be created… many times larger in map data size than ones RAM or VRAM could hold at any one time…
So surely the limiting factor is simply the amount of HDD/SSD space any ones system has installed or access to to hold the base pool of map data that UE5 would need to pull from?
Read this quote from the Unreal 5.0 World Partition Documentation:
“To support the development of large worlds, all grid cells are initially unloaded. When the Level opens, the Editor will only load Actors that have their Grid Placement setting marked as Always Loaded, such as environment backdrops and managers. This supports the development of large worlds where it is impossible to load the entire map in the Editor.”
PS: The UE5 Landscape Technical Guide here: https://docs.unrealengine.com/5.0/en-US/landscape-technical-guide-in-unreal-engine/ still has not been updated to reflect the technical changes and subsequent changes in workflow needed for UE5. 
This thread has gone off the rails. Bashing Epic (or others) won’t help us understand the features of UE5. The original thread was examining the technical details of WP. I found that interesting and useful. That’s what I would prefer to discuss here.
Maybe these other opinions could be discussed in a different thread?
I’ll be getting TerreSculptor as soon as I get 2 more RAM sticks, to max out at 128 GB.
I’m very hopeful it will really help us.