Detailed Inquiry on RHI and RDG Changes from UE4.24 to UE5

Development Rendering
, ,
1

Hello Epic team, Thank you for the previous response. As suggested, I am opening a new ticket for more detailed questions:

1. What are the major changes made to the RHI and RDG modules in UE5 compared to UE4.24?

2. What were the primary reasons behind these architectural modifications?

3. If we attempt to implement or port UE5’s new rendering features (such as Lumen, Nanite, and Virtual Shadow Maps) based on UE4.24’s underlying RHI and RDG modules, what potential risks should we anticipate aside from possible performance issues?

We appreciate any insights you can share to help us evaluate the feasibility and challenges of this approach.

Thanks!​

2

Hi,

Thanks for the follow-up and for outlining your questions. A short answer upfront: We don’t support or recommend attempting to backport UE5 rendering systems (Lumen, Nanite, Virtual Shadow Maps, etc.) onto UE4.24. Those features rely on extensive changes across RHI, RDG, shader/tooling, asset formats, build configurations, and platform backends that don’t exist in UE4.24. Because of that, we’re unable to guide a backport.

To address your points at a high level:

RHI/RDG changes in UE5 vs. UE4.24 (high level)

UE5 includes a substantially refactored RHI and an evolved Render Dependency Graph with different pass/lifetime/barrier models, PSO management, resource aliasing, async/parallel work scheduling, and tighter integration with modern APIs (D3D12/Vulkan/Metal). These changes underpin Nanite/Lumen/VSM and are pervasive across the renderer and tooling. Attempting to backport all of these features is a next-to-impossible task.

Why were those architectural changes made?

UE5’s features assume those foundations, primarily performance on modern hardware, correctness and memory efficiency (barriers/aliasing/lifetimes), scalability for large scenes, and maintainability going forward.

Risks of trying to implement UE5 features on UE4.24

Beyond performance: stability/correctness issues, undefined behavior under load, shader/tooling incompatibilities, asset/content pipeline mismatches, platform regressions, and a codebase that will be difficult to maintain. We can’t support or triage issues arising from such a fork.

Recommendation

If you need UE5 features, the supported path is to migrate to the latest UE5 release and evaluate with those systems as-designed. We’re happy to help with high-level migration questions or point to relevant documentation for moving from UE4 to UE5.

We appreciate your understandin,g and if you have any further questions, please let us know.

Cheers,

Tim