Have tested in a blank UE 5.2.1 Project and a 5.3 Preview 1 Project.
Create a World Partition Map
Build HLODs
Build Fails due to an error with Virtual Textures
Remove VTs from project settings
HLODs build on smaller maps
HLODs fail due to the page file too small on large world maps (*My page file is 30GB)
I haven’t had great luck with W.P. Landscape HLODs either.
I have tried up to 5.2.1, and I usually get memory errors on my 128GB system.
I originally tried creating HLODs on large heightmaps on my R9-5950X 16C/32T, ASUS ROG X570, 128GB DDR4, ASUS TUF RTX-3080.
I have a new workstation now that I will be trying it on which should not have any memory problems any more: Intel W7-2495X 24C/48T, ASUS Pro W790 ACE, 512GB DDR5 ECC, ASUS ROG STRIX RTX-3090.
I will see if UE5 has other issues still with this much memory on some tests here shortly.
Note: Page File size almost never fixes every malloc issue, especially if the Page File has to be significantly larger than the RAM memory.
I tested building HLODs on a few sizes of Landscapes on my workstation, starting at 2017x2017.
For an 8129x8129 Landscape, at default LOD, it took 30 minutes and required 180GB of memory.
So if you have something like 64GB in your system, a 30GB Page File is way too small, depending on the Landscape size you are trying to HLOD.
For an 8129 Landscape you would require 64GB RAM + 128GB Page File at least.
I have my doubts that a Page File is going to save you, they have limitations.
Plus, if your Page File is not on a PCIe5 NVMe then your performance is going to be horrific.
DDR4-2166 memory is about 40 times faster than an SSD, so what takes 1 minute in memory will take up to 40 minutes or more on a Page File on an SSD.
It took my workstation 30 minutes to build (W7-2495X 24C/48T, 512GB DDR5) so if it paged out you could be looking at as much as 40x as long.
Further testing on the 8129x8129 Landscape…
A Landscape.All.LOD Distribution.LOD 0 Screen Size of 2.5 results in:
40GB of CPU memory
7GB of GPU memory
12 minutes build time
So you would require a system with 64GB memory and an 8GB GPU minimum.
This also results in a really large triangle size HLOD.
More further testing on the 8129x8129 Landscape…
A Landscape.All.LOD Distribution.LOD 0 Screen Size of 1.5, results in:
40GB of CPU memory
8GB of GPU memory
12 minutes build time
So you would require a system with 64GB memory and a 10GB GPU (8GB GPU is borderline) minimum.
This also results in a decent mid-range triangle size HLOD.
And further testing on the 8129x8129 Landscape…
A Landscape.All.LOD Distribution.LOD 0 Screen Size of 1.0, results in:
42GB of CPU memory
8GB of GPU memory
12 minutes build time
So you would require a system with 64GB memory and a 10GB GPU (8GB GPU is borderline) minimum.
This also results in a decent triangle size HLOD, which would probably be commonly used.
Note however, that I have ran into build instances where the HLOD Build resulted in some of the HLOD sections being different LOD levels.
This usually requires an HLOD delete and rebuild and possibly changes to the LOD 0 Screen Size value.
If you are building HLODs on Landscapes larger than 8129, such as 16321x16321, then I expect the memory requirements to increase.
I will test that next…
A 16321x16321 largest World Partition size Landscape HLOD build at “LOD 0 Screen Size of 1.0” requires:
NOTE: The entire Landscape is unloaded during the build otherwise the required memory is higher!
512GB of CPU memory + 220GB Page File (730GB Commit!)
28GB of GPU memory (24GB Dedicated + 4GB Shared)
100 minutes build time
So you would require a system with 512GB memory and a 24GB GPU minimum.
If you have less than 512GB of installed memory, I really doubt that any size Page File will save you.
For example, if you only have 32GB and try to make a 768GB Page File, then the performance is going to be horrible, and the editor will probably just crash.
Page Files aren’t technically “used when RAM runs out”, Windows does things things like “delayed malloc”, but it won’t allow “over commit”.
Windows can tend to “freak out” if an application starts allocating huge buffers and arrays that exceed free physical memory.
Often the app will “stop responding” while malloc allocates from the page file, which is really slow, and that can crash the app.
I develop high-end 3D software that supports up to 18 Exabytes of memory, and I have experienced that large page file allocations even to PCIe4 NVMe drives are so slow that application stalls often kill it.
Small Page File allocations in the area of 10% to 50% of the total amount requested by malloc are usually ok.
Trying to malloc 32GB of RAM plus 256GB of Page File often will just kill the app.
If you do get a 768GB Page File working and manage to build the HLODs, I would be interested in knowing how long it took. 
Since the 8129x8129 HLOD build of LOD0 Screen Size 1.0, 1.5, and 2.5 were all similar memory requirements, then I would expect the same on the 16321x16321 Landscape.
I will try a 16321x16321 at LOD 0 Screen Size of 2.0 tomorrow morning, it’s 2:00am here now.
This is absolutely bonkers, no one has that much mem or GPU mem, im running a 4080 which is nearly top of the range.
This is most definitely an issue with UE 5.2 as I could easily build HLODs in UE 5.1 with no issue on the same map.
Can you run any size test with Virtual Textures turned on?
no one has that much mem or GPU mem
Most people don’t have actual workstations. Epic’s engine coding is far from optimal, to say the least, I was surprised to see an 18-fold increase in memory going from 8k to 16k. But I’m not surprised. When I tried doing a 32kx32k World Composition to World Partition conversion, it took 26.5 hours.
I could easily build HLODs in UE 5.1
Not me, not on my 128GB system, 16k landscapes would always error out quite early.
And after seeing that the memory commit is over 730GB it’s no wonder why.
Windows won’t typically allocate more than 4x RAM for Page File maximum, so even with 128GB RAM you normally max out at a 512GB Page File. And 128GB + 512GB isn’t enough for 16k.
Video memory is even worse. Most GPU functions that Epic does will only run in Dedicated video memory. And Shared is only 50% of installed RAM. So a computer with 32GB of RAM and a 16GB GPU only has 32GB of Shared GPU memory. On my workstation I can get 256GB + 24GB total, which is required for some UE features to complete without error.
Can you run any size test with Virtual Textures turned on?
I can try that in the next while, I have a bunch of other work to complete first, and these tests take literally hours.
I am going to try a 16321 x 16321 landscape with LOD 2.0 to see how that fares, but I am expecting the same results as the test above.
So I decided for the fun of it to try a really high “LOD 0 Screen Size” on the 16321 x 16321 Landscape, a value of 5.0.
This results in mesh quads that are very large, but the time and memory are significantly better:
8 minutes to build
32GB CPU memory
6GB GPU memory
So a system with 32GB to 64GB should work, plus an 8GB GPU.
The decimation of the landscape shape is also more consistent from component to component of the HLOD, as seen in this image:
Whereas a lower LOD 0 value causes more varied decimation of the components as shown here:
This decimation issue will have to be considered for any specific landscape actor, as it might cause visual issues, and I don’t know of any way to bias the decimation action.
I will do further research on the HLODs, and add another couple of videos to the Demenzun Media World Partition Video Series on the YouTube channel.
Another few tests on the 16321x16321 landscape.
Once you hit LOD 0 Screen Size of 2.0 or higher, the amount of required memory really drops.
16321 x 16321
LOD 0 Screen Size = 2.0
9 minutes to build
50GB CPU memory
6GB GPU memory
This is just the HLOD meshes visible:
This is just the HLOD meshes in Lit mode:
I tried running UE5.2 in Simulation mode, and a LOD 0 Screen Size of 2.0 for a 16384x16384 landscape is more than high enough resolution.
So if you are building HLODs for large landscapes, try 2.0 or 2.5 for Screen Size during Building, it will probably be enough resolution.
I should re-test the LOD 0 Screen Size value of 1.0 to see if UE5 is consistent in the high memory usage.
It is rather odd that a value of 1.0 requires 512+ GB while a value of 2.0 only requires 50GB.
Previously, when I did build with my R9-5950X 128GB system the 16321 size landscape also failed with out of memory, so it is using more than 128GB + default Page File.
