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

Made a little test with UE5, HW vs SW Lumen

Hardware Lumen:

View attachment 6296

Software Lumen:

View attachment 6297

The difference is massive!

Plus, HW-Lumen runs a tiny bit faster (around 1ms)

I assume the more complex the scene, the faster HW-Lumen is going to be compared to SW-Lumen.

Good stuff!

Its hard to judge from one example, but kind of shows off the strengths and weaknesses of each aproach. HWRT can create sharper and more accurate contact shadows and reflections, but cannot do highly divergent traces as efficently as SDF tracing, thus the larger scale, more diffuse shadows are less rich on the HWRT mode.

In a perfect world, the engine would use both methods where each is best.
 
Plus, HW-Lumen runs a tiny bit faster (around 1ms)
What GPU are you using?
Keep in mind that HW RT is doing both Reflections and Global Illumination while ending up faster than software GI alone and SSR.

I assume the more complex the scene, the faster HW-Lumen is going to be compared to SW-Lumen.
Also HW Lumen will massively benefit from more capable RT GPUs that are equipped with many RT cores , much more than SW Lumen.
 
thus the larger scale, more diffuse shadows are less rich on the HWRT mode.
Without reference path-tracing shots, it's actually impossible to say whether these are "rich" diffuse shadows or improper shading (assuming that path-tracing reference renderer is itself unbiased and feature complete)
And I have not seen any data to back up the claims that diffuse SW SDF tracing is any faster than HW meshes tracing (and even if it is, there are other questions such as whether it worth spending SM's time on SW tracing rather than offload this to HW and do other stuff on SMs in parallel)
 
Its hard to judge from one example, but kind of shows off the strengths and weaknesses of each aproach. HWRT can create sharper and more accurate contact shadows and reflections, but cannot do highly divergent traces as efficently as SDF tracing, thus the larger scale, more diffuse shadows are less rich on the HWRT mode.

In a perfect world, the engine would use both methods where each is best.
Given how software lumen tend to overly darken concave things (they only receive screen space bounces) - I would not be so ready to say that it is producing superior results regarding diffuse shadows.

Yeah as @OlegSH syys
 
Given how software lumen tend to overly darken concave things (they only receive screen space bounces)
Oh yeah, can't agree more.
SW tracing solely relies upon the cards cache for shading in hit points.
There are no parametrization so that in case if the engine fails at capturing cards it can fallback to proper materials shading like with HW RT.
Complexly shaped objects often have black cards without any materials shading (those who worked with the engine would notice this immediately in cards debug mode), which would obviously turn SW GI into AO since there would be 0 brdf lighting evaluation in hit points and only darkenning can be calculated in that case.
 
Fair points. The deeper shadows looked punchier to me, but maybe that's a subjective preference, but not necessarely more accurate. Specially with such large light sources.
 
In a perfect world, the engine would use both methods where each is best.
I don't think keeping what amounts to two entire retained mode data structures in VRAM (and related updates) is going to make sense any time soon. It's probably still cheaper to just add a bit more sampling to hardware RT than to keep around/generate/update all the distance fields IN ADDITION to the RT structures.

Without reference path-tracing shots, it's actually impossible to say whether these are "rich" diffuse shadows or improper shading (assuming that path-tracing reference renderer is itself unbiased and feature complete)
Luckily there's also an increasingly good reference path tracer in the engine now as well a click away :)
 
Luckily there's also an increasingly good reference path tracer in the engine now as well a click away
Yeah, I know, have been using it since EA1, though it was broken in EA2 in my toy projects. Now it's fixed in the preview build. Anyway, many thanks for adding it, it's a great tool imo.

Guess you already aware of the weak spots of the reference renderer, such as overblurring of normals caused by denoising (most likely), hopefully this can be fixed too with better denoising.
 
Now thats 'next gen', what we all want. Again, its another demo. Though its done by just one person so thats impressive for being the results. He never specified what hardware he was using?
 
Just incredible. True next gen graphics.

What's even more impressive is that it just uses around 4 GB VRAM at high settings in WQHD and these textures look 2 gens ahead of everything we have now. True optimization magic.

Its topping everything else so far, tech demo or game. Wonder what hardware he was using?
 
Its topping everything else so far, tech demo or game. Wonder what hardware he was using?
I believe he's using a 2080 Super.

Sadly the game is running without HW-Raytracing and with DX11.

I would really like to see a brand new compiled version using the new UE5 Preview and HW-RT.
 
I believe he's using a 2080 Super.

Sadly the game is running without HW-Raytracing and with DX11.

I would really like to see a brand new compiled version using the new UE5 Preview and HW-RT.

That would sure improve its bad performance, it looks quite choppy but extremely good ofcourse. Hardware RT would make it look and run better, imagine how amazing that would look.
 
Sadly the game is running without HW-Raytracing and with DX11.
Virtual shadow maps + DX11 is also really slow... although this particular demo is light enough that it runs pretty well regardless. You can run it in DX12 mode with -dx12 on the command line though in any case.

Demo looks nice and runs well here. Definitely would be neat to see it recompiled for UE5 Preview/final releases!
 
Last edited:
I don't think keeping what amounts to two entire retained mode data structures in VRAM (and related updates) is going to make sense any time soon. It's probably still cheaper to just add a bit more sampling to hardware RT than to keep around/generate/update all the distance fields IN ADDITION to the RT structures.


Luckily there's also an increasingly good reference path tracer in the engine now as well a click away :)

I mean, the question for the next seven years+ is surely "does it work on the Series S". Maybe a solution is to get better at approximating what SDFs are good at using RT hardware, namely cone tracing? That's basically what RESTIR is and what world probes are for. Maybe switching from spherical harmonics to another function like ambient dice would give good enough quality for rough specular. And with things like probe grid adjustment, having them shift out of the way of dynamic objects, you might be able to cut down on direct trace length for specular quite a bit, at least for rough spec. PC hardware should start advancing again soon, so if you're considering ditching SDFs, you can count on that having RT functionality where necessary eventually, but the baseline will still be the very lowly Series S for quite a while.
 
I mean, the question for the next seven years+ is surely "does it work on the Series S".
For sure, but they sorted it out for the Matrix demo at least so that gives me more hope than I had previously. Obviously significant compromises need to made on Series S but it would certainly be far from ideal if that involved major algorithmic and data structure changes.

I doubt the engine can/wants to ditch SDFs entirely any time soon, but the hope is that most games will be able to use one or the other on a given platform at least. May or may not be possible depending on content though.
 
Back
Top