Standalone HLODs are only available when using the Runtime Hash. It is not supported by the legacy Spatial Hash. That would be the reason why the Standalone HLODs are currently not showing.
It is recommended that you upgrade to the newer Runtime Hash. All the WP improvements since 5.4 are only available with this Hash. The editor will convert automatically your Spatial Hash settings when you change the Hash in the World Setting panel.
The benefits are :
Streaming quality
No more spurious grid promotion. Actors are placed by bounds center, not aligned bounds, so straddling a cell boundary no longer pushes content up a level — the long-standing “why is my small prop persistent?” problem largely disappears.
Cells stretch instead of promoting. The Loose Hierarchical Grid lets an actor overhang its cell by up to a quarter cell per axis (up to ~1.5× the configured grid size) before moving up a level.
No grid-origin or axis artifacts. Content near the world origin or grid axes no longer gets promoted differently from identical content elsewhere.
Variable cell size adapts to actual content bounds rather than forcing everything onto one rigid aligned lattice.
Capability
True 3D partitioning and streaming — not just 2D grids with unbounded Z. Valuable for vertical worlds, multi-floor interiors, and underground.
Mix partition types in a single hash. LHGrid, Persistent, and LevelStreaming partitions can coexist in one list; Spatial Hash only ever offered one scheme.
Extensible without forking the engine. Subclass URuntimePartition and your custom partitioning scheme gets HLOD and Data Layer support for free — previously that meant reimplementing the plumbing yourself.
Per-partition HLOD setups. Each partition carries its own HLODSetups array where every HLOD tier is itself a partition with independent cell size, loading range, and spatially-loaded flag — a much more direct mapping than Spatial Hash’s global HLOD-grid derivation.
Backed by an R-tree spatial index (Hilbert-sorted, 2D or 3D profile) rather than fixed cell-coordinate math.
Simplicity and maintenance
Removes a whole class of advanced tuning cvars. Grid promotion, pivot-vs-bounds placement, and grid alignment cvars are no longer needed — the behavior they patched is solved structurally.
Less micro-management for content teams. Epic’s own guidance shifts from “monitor and tune promotion” to “just build content.”
Simpler mental model for onboarding: one partition object per grid with visible, editable settings, instead of implicit multi-level grid behavior governed by console variables.
Adoption cost
One-click, undoable migration from the World Settings → Runtime Hash Class dropdown; cell size, loading range, priority, block-on-slow-streaming, client-only-visible and grid alignment all carry over automatically.
Full feature parity retained — OFPA, Data Layers, Level Instances, Streaming Sources, HLODs, External Data Layers all work unchanged.
No content re-authoring. Actors still map to partitions through the same RuntimeGrid property.
Already the engine default for new World Partition maps since 5.4, so it’s the actively developed path — new work lands here, Spatial Hash is legacy.
Measured results
Performance and memory in Fortnite BR were similar or better than Spatial Hash, per Epic — the upgrade is not a perf tradeoff.
The conversion steps:
Check out the map file (persistent level package).
Open the map, set World Settings → Runtime Hash Class → WorldPartitionRuntimeHashSet.
Inspect the generated RuntimePartitions array in the details panel — verify cell sizes, loading ranges, and that HLOD setups landed on the right partitions.
Decide on bIs2D per partition; the converter leaves you 2D.
PIE and compare with wp.Runtime.ToggleDrawRuntimeHash2D, plus wp.Runtime.HashSet.ShowDebugDisplayLevel / ShowDebugDisplayLevelCount.
Re-profile loading ranges — LHGrid’s variable cell size changes which cells your sources touch, so your old tuning isn’t automatically optimal.
Regenerate HLODs and verify, then save and submit the map.
>Standalone HLODs are only available when using the Runtime Hash. It is not supported by the legacy Spatial Hash. That would be the reason why the Standalone HLODs are currently not showing.
We understand the Runtime Hash requirement, but if Sub World Partition HLOD is still Experimental and rather risky to introduce it to our team, we would prefer to avoid using it.
According to the article below, Sub World Partition HLOD is categorized as experimental. Is this still the case in UE 5.8?
Sub WP HLODs are still considered experimental because we haven’t validated they work in all cases and there are still some missing features. The main missing feature is the support of External Data Layers (ie, DLs that are parts of Game Feature Plugins). There is no plan to refactor or remove them. They should be safe to use if you are not planning on using EDLs.
We are aware of titles that have used them successfully. Some are currently live and others ship soon.
Thank you for the reply regarding to the status of Sub WorldPartition HLODs.
We have also tried RuntimeHashSet, but haven’t been able to get it working properly, so we now have a few other questions.
1. When generating HLODs for LIs converted to SubWP, do we need to run the HLOD generation command individually for every LI asset?
- Ideally, if the LI is included in the main WP, it would be helpful if the HLODs could be generated automatically.
2. Even after generating HLODs for an LI placed in the parent WP, what could cause the HLODs for that LI area to not be visible from a distance in the parent WP?
- When opening the LI asset itself, the HLODs appear to have been generated correctly. (We manually generated HLODs in the LI asset for the time being)
There are a couple of things that you need to align so the Standalone HLODs are picked up. The levels must use the same grid name. The name(s) of the HLOD Partitions must match between the Main WP and Sub WP(s). Also make sure to set the Default HLOD Layer of the SubWP appropriately.
I’m attaching a zip file that contains a project (for 5.8) properly setup and a WIP doc. It was based on an older release so the image for the HLOD Partition configuration is wrong but the same rules apply in the newer releases.
We finally managed to generate HLODs for our Sub World Partitioned LIs thanks to your example project.
However, the performance gains didn’t meet our expectations, although we still have several things to investigate.
Another concern about moving to Sub World Partition is that generating HLODs seems rather complicated, as it looks like we need to configure the World Settings and generate HLODs individually for every Sub World Partitioned LI.
Anyway, since we managed to generate the HLODs successfully, you can close this thread.