Unreal Engine 5, [UE5 Developer Availability 2022-04-05]

[Andrew Lauritzen]

No, software based solutions are not worth it. Epic has created new problems and now they are trying to solve them instead of going the obvious way with HWRT.

I dunno why I have to keep saying this, but while HWRT is great, it has a huge number of currently unsolved problems that no one seems to talk about at all. As long as it is still infeasible to do fine-grained streaming updates on a reasonable BVH and BVH construction in general performance is too low, it is going to be similarly limited to secondary effects in any suitable complex game. We don't need faster tracing primarily, we need faster data structure building (without of course tanking the tracing performance) and no one seems to talk about that part...

If you think things like foliage are a problem for Nanite, they are 10x more of a problem for HWRT. Honestly that goes for most things that are an issue for Nanite... HWRT paths just entirely don't do them at all because it's completely infeasible currently.

Guys stop forcing me to be the one playing the anti-RT side here. I'm normally the one arguing the other side . I do still strongly feel it is an important part of the future (and potentially everything ends up RT in the end) but it doesn't help to be unrealistic about its very real, and very unsolved shortcomings.

 

[Andrew Lauritzen]

I'd like to see the performance of SW lumen without nanite.

Both VSM and Lumen rely on Nanite for a lot of efficiency. While you can somewhat try and decouple them in specific cases you will usually get a result that is both worse quality *and* performance. This is definitely true for VSM in Fortnite chapter 4 and would imagine it's also true for Lumen.

From Lumen docs:
> Nanite accelerates the mesh captures used to keep Surface Cache in sync with the triangle scene. High polygon meshes in particular, need to be using Nanite to have efficient captures. Foliage and Instanced Static Mesh Components can only be supported if the mesh is using Nanite. [...] Lumen relies on Nanite's Level of Detail (LOD) and Multi-View rasterization for fast scene captures to maintain the Surface Cache, with all operations throttled to prevent hitches from occurring. Lumen does not require Nanite to operate, but Lumen's scene capturing becomes very slow in scenes with lots of high polygon meshes that have not enabled Nanite. This is especially true in scenes if the assets do not have good LODs set up for them.

VSM docs have an entire section (and various in-engine tools) devoted to how bad non-nanite geometry can be

Obviously both will depend on the specific scenes and use cases, but there are *many* performance cliffs present if you are not using Nanite, to the point that it's hard to imagine shipping something as open world and dynamic as Fortnite with Lumen/VSM and *not* Nanite or similar tech.

 

[Silent_Buddha]

If you think things like foliage are a problem for Nanite, they are 10x more of a problem for HWRT. Honestly that goes for most things that are an issue for Nanite... HWRT paths just entirely don't do them at all because it's completely infeasible currently.

Just out of curiousity, in this side by side comparison...

Lumen HW RT - Imgsli

Is that why the leaves in the tree in the middle of the screen appear to lose alot of lighting detail? Or is there some other underlying reason that the foliage often seems bleached or lacks lighting definition when HWRT is enabled?

Or perhaps it's just me and it's supposed to look like that.

Regards,
SB

 

[Dampf]

I dunno why I have to keep saying this, but while HWRT is great, it has a huge number of currently unsolved problems that no one seems to talk about at all. As long as it is still infeasible to do fine-grained streaming updates on a reasonable BVH and BVH construction in general performance is too low, it is going to be similarly limited to secondary effects in any suitable complex game. We don't need faster tracing primarily, we need faster data structure building (without of course tanking the tracing performance) and no one seems to talk about that part...

If you think things like foliage are a problem for Nanite, they are 10x more of a problem for HWRT. Honestly that goes for most things that are an issue for Nanite... HWRT paths just entirely don't do them at all because it's completely infeasible currently.

Guys stop forcing me to be the one playing the anti-RT side here. I'm normally the one arguing the other side . I do still strongly feel it is an important part of the future (and potentially everything ends up RT in the end) but it doesn't help to be unrealistic about its very real, and very unsolved shortcomings.

I assume a lot of this can be solved with a new DirectX Raytracing standard. Why is Epic not working with Microsoft to create DXR 2.0 which could solve a lot of these issues you speak of? It should be in the interest of both plus the IHVs to utilize modern GPUs and the Xbox consoles as much as possible in the most commonly used engine.

 

[Andrew Lauritzen]

Is that why the leaves in the tree in the middle of the screen appear to lose alot of lighting detail? Or is there some other underlying reason that the foliage often seems bleached or lacks lighting definition when HWRT is enabled?

I can't speak to the details and again I don't want to give incorrect information about what's going on here without looking at it. Naively it looks like something with the GI transmission is perhaps too high in the HWRT case and it's drowning out the direct lighting (which is providing most of the shadow detail), but it's hard to speculate specifically.

At a high level the scene representation that the RT is using is significantly lower poly (especially for the trees which are otherwise 300k+ polygons each in many cases), and I believe entirely lacks deformation/animation/world position offset. That said, the same is true for the SDFs, so I don't specifically know the tradeoffs there.

For very diffuse effects this can be fine, but obviously would not be sufficient for stuff like direct shadowing.

 

[Andrew Lauritzen]

I assume a lot of this can be solved with a new DirectX Raytracing standard. Why is Epic not working with Microsoft to create DXR 2.0 which could solve a lot of these issues you speak of? It should be in the interest of both plus the IHVs to utilize modern GPUs and the Xbox consoles as much as possible in the most commonly used engine.

You can safely assume that all the major ISVs/OSVs/engine folks are well aware of these issues and have been for some time. My main point is that it's far from as simple or obvious as some of you are trying to make this out to be in the thread here.

 

[Shifty Geezer]

Consoles should have launched with hw rt and perhaps ML acceleration too. I feel that Epic had to tailor to the consoles (naturally) as it is a install base you dont want to leave behind.
Now UE5 is still mighty impressive but not the leap we could have had if things were more current hw wise. Faster cpus than 3.5ghz wouldve solved things too as RT is quite cpu heavy.

Better wasn't possible. These machines are already big, expensive and power-hungry. UE5 also has to run on other GPUs than the best nVidia currently has to offer; Epic aren't going to leave that audience behind. The only realistic solution to your suggestion was launching 2-3 years later than they did.

 

[chris1515]

Consoles should have launched with hw rt and perhaps ML acceleration too. I feel that Epic had to tailor to the consoles (naturally) as it is a install base you dont want to leave behind.
Now UE5 is still mighty impressive but not the leap we could have had if things were more current hw wise. Faster cpus than 3.5ghz wouldve solved things too as RT is quite cpu heavy.

Still, UE supports HW RT too and things look bettet there, and i guess that will improve.

Again raytracing is heavy on CPU because of the BVH building. For static geometry, it is possible to build the BVH offline and stream it from the SSD on consoles and it is possible to do partial update of the BVH for dynamic geometry. This is not possible with DXR 1 on PC where you can't stream BVH and need to rebuild the full BVH when it is needed.

And console have HW-RT just not traversal acceleration and even RDNA 3 doesn't have special RT traversal unit but some optimization to help traverse less node with DXR flag and Bounding box sorting.

AMD doesn't want to take the same road than Nvidia and Intel.

 

[pjbliverpool]

Again raytracing is heavy on CPU because of the BVH building. For static geometry, it is possible to build the BVH offline and stream it from the SSD on consoles and it is possible to do partial update of the BVH for dynamic geometry. This is not possible with DXR 1 on PC where you can't stream BVH and need to rebuild the full BVH when it is needed.

This seems like a weird thing to not be possible. Does anyone know what the actual limitation is here and why it's not a simple fix for DXR?

 

[chris1515]

This seems like a weird thing to not be possible. Does anyone know what the actual limitation is here and why it's not a simple fix for DXR?

Because this is a black box for the moment. It will maybe change in the future but we need to wait at least DXR 2.0.

 

[Andrew Lauritzen]

This seems like a weird thing to not be possible. Does anyone know what the actual limitation is here and why it's not a simple fix for DXR?

They don't want to commit to a common/standard BVH format for relatively good reasons right now. Same problem as shader compilation... it's easy when you can just offline compile once to a fixed target. It's hard when it has to work on future targets and drivers that don't even exist today with potentially completely different tradeoffs.

 

[Dampf]

More HW/SW Lumen comparisons:

https://imgsli.com/MTM4NzA4

https://imgsli.com/MTM4NzA5

https://imgsli.com/MTM4NzEw

https://imgsli.com/MTM4NzEx

 

[Scott_Arm]

I'm a little confused about the HW RT option in Fortnite Chapter 4. Is it a totally different RT system using HW functions and a BVH (typical DXR approach)? Is it a combination of the Lumen surface cache system and a BVH for HW RT? Is it using the HW functions for RT somehow without the standard BVH approach? Do they generate meshes from the SDF to use in the BVH?

Would really like to understand the pros and cons of enabling and disabling the HW RT option.

Nevermind, the docs are pretty detailed:

Lumen Technical Details in Unreal Engine | Unreal Engine 5.1 Documentation

Wish it was more explicit about the difference between Lumen High and Epic settings. Epic is targetting 30 fps (assuming PS5 and Series X) and High is targetting 60fps. Probably just a difference in ray count, or is it also roughness cutoff?

Looks like the TSR quality settings probably map to the r.Upscale.Quality, which controls the image upscaling algorithm. I should check the performance between Epic and High to see how much it is and how much different the quality is. Should be 36-tap Gaussian-filtered unsharp mask vs 13-tap Lanczos 3.

Screen Percentage with Temporal Upscale in Unreal Engine | Unreal Engine 5.1 Documentation

 

[chris1515]

I'm a little confused about the HW RT option in Fortnite Chapter 4. Is it a totally different RT system using HW functions and a BVH (typical DXR approach)? Is it a combination of the Lumen surface cache system and a BVH for HW RT? Is it using the HW functions for RT somehow without the standard BVH approach? Do they generate meshes from the SDF to use in the BVH?

Would really like to understand the pros and cons of enabling and disabling the HW RT option.

They use Nanite fallback mesh replacing SDF. HW RT is used for GI and Reflections. The system is totally different than the SDF.

 

[PSman1700]

The only realistic solution to your suggestion was launching 2-3 years later than they did.

Which perhaps wouldnt have been too bad considering the problems were facing since launch regarding supply issues etc.

Again raytracing is heavy on CPU because of the BVH building. For static geometry, it is possible to build the BVH offline and stream it from the SSD on consoles and it is possible to do partial update of the BVH for dynamic geometry. This is not possible with DXR 1 on PC where you can't stream BVH and need to rebuild the full BVH when it is needed.

And console have HW-RT just not traversal acceleration and even RDNA 3 doesn't have special RT traversal unit but some optimization to help traverse less node with DXR flag and Bounding box sorting.

AMD doesn't want to take the same road than Nvidia and Intel.

Ray tracing is still requiring CPU cycles on these consoles, obvious from the performance their getting whenever any RT is used.

Consoles have HW RT, but not like NV or Intel no. Thats why its so slow regarding ray tracing.

Any official sources that AMD has given up? Where did they state that they arent intrested in competing with their competitors in the RT (and ML) departments?

 

[DavidGraham]

https://imgsli.com/MTM4NzEx

This shows more reflections on the HW side, as well as more light bounces inside the building and outside.

https://imgsli.com/MTM4NzEw

This is a bit confusing, on one hand, the character and objects closer to it (trees and ice cliffs) have better bounce lighting and reflections on HW, on the other hand, far objects have way different lighting in SW and HW, so either this is due to the better distance in HW, or due to random cloud placements.

 

[Andrew Lauritzen]

This is a bit confusing, on one hand, the character and objects closer to it (trees and ice cliffs) have better bounce lighting and reflections on HW, on the other hand, far objects have way different lighting in SW and HW, so either this is due to the better distance in HW, or due to random cloud placements.

The vast majority of differences in that image look to just be from different cloud shadows (via a light function) and streaming differences (some trees and rocks are different). A bunch of assets are just not streamed in the HW side at all for some reason... not sure if that's just a transient state or if for some reasons the settings are different when HWRT is on.

 

[chris1515]

Which perhaps wouldnt have been too bad considering the problems were facing since launch regarding supply issues etc.



Ray tracing is still requiring CPU cycles on these consoles, obvious from the performance their getting whenever any RT is used.

Consoles have HW RT, but not like NV or Intel no. Thats why its so slow regarding ray tracing.

Any official sources that AMD has given up? Where did they state that they arent intrested in competing with their competitors in the RT (and ML) departments?

Did I say they don't need some cycles use for raytracing? They need to build and update for dynamic geometry but much less than PC.

 

[PSman1700]

They need to build and update for dynamic geometry but much less than PC.

Going by performance reviews CPU vs CPU at the same settings (and matching GPU etc), thats not really visible in the real world at the least.

 

[Inuhanyou]

If unreal engine 5s lighting solution by default is lumen. What was unreal engine 4s default lighting solution?