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

[cwjs]

Tbh Lumen looks a lot like tech aimed at running on PS4/XBO gen h/w which explains nicely why it does everything this way with such drawbacks.

I kinda agree, although I do think we should acknowledge that the 'drawbacks' are not going to be noticeable to a lot of eyes, they'll just shape the limitations of what kinds of scenes and situations get rendered. It may be a long time before it gets replaced though, one man's "last gen compatibility" is another man's "commercial engine that has to fit a ton of customer use cases"

 

[Deleted member 86764]

Would be nice to know the render resolutions of these videos and if they're using the scaling tech.

 

[DegustatoR]

I kinda agree, although I do think we should acknowledge that the 'drawbacks' are not going to be noticeable to a lot of eyes, they'll just shape the limitations of what kinds of scenes and situations get rendered.

We'll see but I think this will depend a lot on what other engines - especially those targeting next gen h/w exclusively - will do. Basically it will depend on what comparison points there will be.

 

[PSman1700]

Nice performance he's getting with his 3090. Very modest ram usage for what it is it seems. The 3090 is a much and much more capable gpu than the 2080ti i see (which isnt all that surprising but still).
Also, now im getting too comfortable seeing those graphics, i think it will take time before we actually see this kind of visuals in actual larger games.

 

[mr magoo]

https://twitter.com/x/status/1397636481913610241

 

[SlmDnk]

https://twitter.com/x/status/1397636481913610241

Already posted: https://forum.beyond3d.com/posts/2205957

Tip: Next time, run a search for the Twitter/YouTube etc. ID before posting.

▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬

https://twitter.com/x/status/1397894959164973057

 

[OlegSH]

Would be nice to know the render resolutions of these videos and if they're using the scaling tech.

Rendering is at quarter res with default settings (easy to check by disabling TAA or by reducing AA samples count to 0). Having 50-60 FPS with 2560x720 internal rendering resolution (5120x1440 output) on 3090, so I would not say that Lumen is particularly fast, especially for something which has tons of limitations.

I'm pretty sure that we'll see Lumen 2.0 down the line which will drop most of DX11 compatibility in favor of more modern DX12/RT approaches

They already merge SDFs into 1 large global SDF with lower res per object for performance reasons, so I don't know why they would not do the same for polygonal meshes with DXR.
Metro EE handles dozens of millions triangles in frame, so I guess they should be able to automatically simplify their meshes to this level of detail.

 

[chris1515]

https://www.resetera.com/threads/unreal-engine-5-dev-workflow-stream-today-5-26.431627/post-65867936

Interesting and probably how Nanite will scale with RAM size and I/O bandwidth.

I've noticed this too, I think there's two things potentially going on here.

The docs mention a streaming buffer size. You can increase it to decrease load on IO bandwidth, or vice versa. In the editor, at least, it's set to quite a modest 512MB. The docs mention that if the streaming buffer is too small, the streaming may never 'settle' even in a static view.

The docs suggest that you can change the streaming buffer size as a console command, or at runtime in the config file, but when I try to do that on the console, it complains that it's a read only variable. Haven't tried runtime config but will give it a go. So I think there might have been an oversight there in this version. The upshot is, that depending on what buffer size it's choosing in editor and at runtime and the speed of your IO, you might not always be getting fully resolved assets.

The second thing I've realised about the default Nanite settings for assets, is that the auto setting isn't always necessarily going to pick the max quality possible. There is a precision setting, which you can use to trade asset size vs fidelity to the original. So for example, with the asset highlighted above, I went into its static mesh editor - that forces it to resolve at the default precision setting, and it looks a lot better than the above. But if I tweak the precision manually, it can be made to look better again. In theory you could go and do that for all the assets, double-check Nanite has picked a good precision setting, and you might get better quality - but at the expense of asset size.

 

[JoeJ]

Got the source finally and peeked into Nanite, but i see more details than the overall idea ofc.
Seems a BVH over triangle clusters, with presistent threads doing traversal, culling and appending to SW / HW worklists. SW rasterizer is there and gives nostalgic feelings. It's true triangles and not point splatting from what i've seen.
Occlusion culling is done with Z pyramid form previous frame i guess, probably reprojected. Not sure here.
Adventureous stuff

They already merge SDFs into 1 large global SDF with lower res per object for performance reasons, so I don't know why they would not do the same for polygonal meshes with DXR.
Metro EE handles dozens of millions triangles in frame, so I guess they should be able to automatically simplify their meshes to this level of detail.

Merging meshes would not be enough. They would also need to remove overlapped redundant triangles below the visible surface, which breaks instancing, and then shared BLAS for duplicated objects is no longer possible - data explosion.
Idk how bad overlapping BLAS really is, but it looks like the very most of their triangles end up hidden and redundant for RT.

Aside partial BVH updates, it would help to disable clusters and their branches of BVH with a bit vector per instance, for example.

 

[Remij]

Finally figured out my issues with compiling. Having a bit of fun now.. too bad it's so short lol.

PS. Everything is better in UltraWide

 

[OlegSH]

which breaks instancing, and then shared BLAS for duplicated objects is no longer possible - data explosion.

I think you are overestimating importance of instansing. Pretty sure there is not too much of it in DXR games. Other than this, they can flexibly choose between the number of instances by merging more or less meshes. For the 200 meter distance where Lumen currently works this should be laughably cheap since it's static geometry anyway, so no need to update BLASes in every frame

 

[JoeJ]

I think you are overestimating importance of instansing. Pretty sure there is not too much of it in DXR games.

UE5 is entirely build around instancing. I mean, while we talk about fancy 'compress geometry by putting it into textures', their main compression mechanism is instancing in the end?

Otherwise i agree RT should work well using some max distance and maybe constant but lower LOD. Even then their triangles form a volume more than a surface. The stuff below the surface has to be culled to make a merged model. Using SDF this would be pretty easy even at runtime, so they might do it.
But there is no big win then: Their GI using DXR is not better. High frequency lighting like shadows and reflections wants geometry at full resolution. And finally, RT likes instancing too, so why try to get rid of it?
I hope they push API progress to achieve this over some half assed RT support just to have it.

 

[OlegSH]

UE5 is entirely build around instancing

Just because of the sheer assets sizes. They would have not needed it otherwise. But we were talking about RT anyway, so by merging and creating more low poly proxies, the larger number of individual instances would have not affected performance to any meaningful extend.

their main compression mechanism is instancing in the end?

For rasterization path - yes, it doesn't mean it should be the same with RT where way lower poly count would not affect image quality (even for offline lightmaps baking there are lots of examples when people simplified geometry to bake it faster, this was the case for SW Battlefront 2).

Their GI using DXR is not better

Their GI using HW Lumen seems to be broken atm.
Here is out of the box difference with all enabled - https://imgsli.com/NTU2MTA
And here is the difference when you disable indirect diffuse lighting with Lumen - https://imgsli.com/NTU2MTE
All these fine and precise shadows produced by HW RT are being removed when merged with indirect diffuse lighting for some reason.
Probably Lumen HW RT doesn't work at all at the moment, these fine shadows can be produced by HW RTGI, which was super slow in UE4 too.
Ok, just checked r.RayTracing.AmbientOcclusion in console and it controls AO shadows here - https://imgsli.com/NTU2MTE, without RT AO image is the same as with SW Lumen here https://imgsli.com/NTU2MTE , disabling RT AO has 0 impact on performance because it's clearly being limited in some other place, not by tracing

 

[JoeJ]

For rasterization path - yes, it doesn't mean it should be the same with RT where way lower poly count would not affect image quality (even for offline lightmaps baking there are lots of e

I agree on geometry for RT can be lower res, or even should be for optimization. But then we need dynamic LOD to adjust this, so character fingers are high res and a house in the distance can be lower.
Then we get optimization and increased quality, while constant LOD always is a bad compromise disagreeing with perspective projection.
We want dynamic LOD for both raster and RT, for the same reasons. You know computer graphics is about two things: visibility and LOD. That's the two key problems, independent from algorithms we use to render our images.

 

[Karamazov]

https://twitter.com/x/status/1397636481913610241

 

[Dr. Nick]

Runs well on my 3080, 35-40-ish fps at native 4k

Reading through their shaders it seems they have a fall-back path that uses either a vertex shader or primitive shader based on the h/w support (for the raster path).

I did not read the papers myself but if what you said is correct wouldn't that put hardware that does not have primitive shaders at a disadvantage? From my understanding only certain AMD GPUs and APUs have the hardware for primitive shaders. What about Nvidia's RTX GPUs, GTX 1600 series and I'm guessing the Xbox Series APU's?

 

[manux]

I did not read the papers myself but if what you said is correct wouldn't that put hardware that does not have primitive shaders at a disadvantage? From my understanding only certain AMD GPUs and APUs have the hardware for primitive shaders. What about Nvidia's RTX GPUs, GTX 1600 series and I'm guessing the Xbox Series APU's?

Nvidia has had mesh shaders since turing. AMD got dx12 mesh shader support in rdna2. Primitive shader from older rdna1 hw never got exposed to developers and rdna1 hw doesn't support mesh shaders. I'm not sure if sony is just calling mesh shaders primitive shaders or does ps5 have older version of gpu that isn't fully mesh shader compliant.

https://devblogs.microsoft.com/dire...on-shaders-reinventing-the-geometry-pipeline/

 

[Deleted member 86764]

Rendering is at quarter res with default settings (easy to check by disabling TAA or by reducing AA samples count to 0). Having 50-60 FPS with 2560x720 internal rendering resolution (5120x1440 output) on 3090, so I would not say that Lumen is particularly fast, especially for something which has tons of limitations.


They already merge SDFs into 1 large global SDF with lower res per object for performance reasons, so I don't know why they would not do the same for polygonal meshes with DXR.
Metro EE handles dozens of millions triangles in frame, so I guess they should be able to automatically simplify their meshes to this level of detail.

How can it work on console if that's how a 3090 is performing, the internal resolution is <720p and the settings are dialed back?

 

[manux]

How can it work on console if that's how a 3090 is performing, the internal resolution is <720p and the settings are dialed back?

Good optimizations or pc lacking optimizations? The engine is in preview, not final. From documentation console target is 1080p and then use TSR to scale into 4k. PC could also be enabling more features than console versions are using.

 

[Jay]

Saw someone say having fun messing with it, shame so short.

I'm surprised Sony didn't release it as a micro demo. Or even MS.
Sounds crazy, but video from last year went viral, petty sure this would've also.