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

Out of the fact the API need to improve I think hardware power need to improve to fully exploit Nanite running at the same time than RT.

Ampere runs ray tracing parallel to other loads. AMD on the other hand doesn't because rt implementation uses tmu's for memory access and compute for going through BVH. Turing is also more limited than ampere despite having dedicated hw for ray tracing.

Ampere can fill the otherwise idle bubbles in pipeline with RT load. Very similar to using async compute to fill in bubbles and get better utilization.

The new GA10x SM allows RT Core and graphics, or RT Core and compute workloads to run concurrently, significantly accelerating many ray tracing operations.

https://www.nvidia.com/content/PDF/nvidia-ampere-ga-102-gpu-architecture-whitepaper-v2.pdf
 
Out of the fact the API need to improve I think hardware power need to improve to fully exploit Nanite running at the same time than RT.
As far as I can tell from all the information available now the only thing which need to improve currently is the geometry grouping for BVH building - and then you'll be able to use RT h/w instead of Lumen's s/w cone tracer.

Now if you want to use per pixel RT with Nanite meshes you'll need these improvements to BVH handling which current APIs don't have. Currently you are limited here to tracing the proxies instead of Nanite.

But note that Lumen's s/w approach doesn't trace Nanite meshes either - it traces through two step scene simplification in form of SDF volumes and "cards". So I don't see how RT h/w is at a disadvantage here really since you don't in fact get what you'd got with it through Lumen's s/w path.

Demon's Soul's have a GI system
GI system can be anything. Quake's lightmaps is a GI system. If global lighting isn't dynamic then it can be faked very accurately with rasterization. Hence why it's important to choose proper comparison targets.
 
I've seen people comment that the lighting in Metro Exodus: EE actually exposes the last-gen quality of the underlying assets, and in that sense makes the game look worse. So I am not sure if it shows that improved lighting can do most of the heavy lifting.
 
Ok, clicking around that df video. Demons souls is a great looking game but there's virtually nothing impressive here. Gi is flat and about a zillion objects are missing shadows or any kind of ao contribution. Nothing close to what metro offers (although ds has much better art assets and art direction)

Look at the scenes with the flaming boss and seriously tell me you think they're doing a good job faking that lighting environment.
f64b62e1-1703-458b-983b-8a63feab8dce
 
Ok, clicking around that df video. Demons souls is a great looking game but there's virtually nothing impressive here. Gi is flat and about a zillion objects are missing shadows or any kind of ao contribution. Nothing close to what metro offers (although ds has much better art assets and art direction)




f64b62e1-1703-458b-983b-8a63feab8dce

DS have much more geometry density. This is not art. It counts a lot. After this is a first game on PS5. They can probably improve everything.
 
DS have much more geometry density. This is not art. It counts a lot. After this is a first game on PS5. They can probably improve everything.

Tessellation is '10 year old rendering tech' too. It's totally art quality -- the polygon counts are a fraction of what's in the ue5 demos, for example, and i'd consider any object in des better looking than a given object in the ue5 scene.
 
A detail version of the model fitting our screen area has approx 128^2 * 2 (for back sides) triangles. We reach this level of detail after 128 tree leves, so we get a speed up of 5.5.
I don't know how you calculated this)
Ray Tracing has log(o) complexity because each next level of perfect BVH4 tree (for example) has (o)^4 elements, so to trace 1 000 000 triangles you need to go through at least 10 levels and tracing 16 000 triangles would require visiting at least 7 levels, with wider BVH the difference can be even lower.
Of course that's not always the case in reality since there is overlaping which depends on geometry topology, but the difference between tracing 1 000 000 and 16 000 triangles should not be 5.5 times.
 
For games trying to looks realistic or hyper realistic polycount and geometry casting shadows is very important too.
From a selfish point of view, I appreciate you pointing that out :)

The two things that really let you see the differences between high detail geometry vs. normal maps are 1) silhouettes and 2) shadows. Screen space shadow traces can get you a ways, but if you try and push them too far they produce various artifacts. One of the things that has actually improved a lot since last years demo is that we had to rely more heavily on screen space traces last year, whereas this year they are very short rays with a large amount of detail being represented at high precision directly in the virtual shadow maps.

The discussion of raytracing still seems slightly orthogonal to me... you can't just assume you have a fully-built BVH sitting around down to the level of detail that these scenes enjoy for any real game scene. It's completely infeasible both in terms of memory but even in terms of tracing. You still want LOD for RT because you don't want every ray to fully diverge by the time it hits the leaves. And you still need to stream those LODs and move objects around freely which means you must consider the cost of iteratively *building* the BVH's and the associated tradeoffs that you must make between build vs. trace performance.

Building these data structures is not dissimilar to rasterizing things. This is doing a lot of the same things that Nanite is doing, but with an additional layer of complexity and unsolved problems added on top. To be clear, we all want to see those problems solved and allow for more efficient indirect ray traces into high poly Nanite geometry (especially for Lumen, etc.), but it is not a "RT or Nanite" situation, it's how do we solve the *additional* problems that RT adds on top of the ones that Nanite already addresses. IMO it's almost guaranteed that an efficient RT solution would also use a lot of the mesh simplification and streaming machinery that Nanite employs.

Getting more efficient RT is more relevant in a discussion of Lumen than Nanite.

I have to admit, I didn't think that geometry was as big of a problem as it is until I saw the UE5 demos.
Same team. Since I've been looking at it every day for a couple years now, it's very obvious when it is missing. Good art and screen space effects (contact shadows, etc) can help narrow the gap a bit, but normal maps in place of geometry are just not good enough anymore for me...

Nanite does solve a bunch of other problems too, like cpu use and memory consumption. Or at least they claim big improvements there. I'll be very happy to not play games and have my fps mysteriously tank when I face a particular direction because of some weird draw call/submission bottleneck.
Right. Many of the quick demos people are showing off so far are less Nanite geometry demos and more GPU culling demos. Even with low detailed geometry you should enable Nanite on everything that it supports as this is key to both way more efficient instancing, but also the multi-view/multi-res/sparse rasterization that makes virtual shadow maps way more efficient.

The discussion of displacement and to what extent we still want that in the future is a more interesting one. It may well be we still want displacement for a variety of compression/art/animation/streaming and similar reasons, but that will effectively just add more detail on the very closest levels. I can't see *not* wanting the automatic fine-grained LOD stuff that Nanite is doing in the future... it seems pretty fundamental to efficient rendering IMO and solves some real problems.
 
Last edited:
And the geometry density is much better I don't care if tesselation is 10 years old. Here it is not use to improve art based on low poly geometry, this is part of the art itself.
I don't understand the argument you're making. Rasterized lighting is better than raytracing because... demons souls has a slightly above average polygon count per screen?
 
From a selfish point of view, I appreciate you pointing that out :)

The two things that really let you see the differences between high detail geometry vs. normal maps are 1) silhouettes and 2) shadows. Screen space shadow traces can get you a ways, but if you try and push them too far they produce various artifacts. One of the things that has actually improved a lot since last years demo is that we had to rely more heavily on screen space traces last year, whereas this year they are very short rays with a large amount of detail being represented at high precision directly in the virtual shadow maps.

The discussion of raytracing still seems slightly orthogonal to me... you can't just assume you have a fully-built BVH sitting around down to the level of detail that these scenes enjoy for any real game scene. It's completely infeasible both in terms of memory but even in terms of tracing. You still want LOD for RT because you don't want every ray to fully diverge by the time it hits the leaves. And you still need to stream those LODs and move objects around freely which means you must consider the cost of iteratively *building* the BVH's and the associated tradeoffs that you must make between build vs. trace performance.

Building these data structures is not dissimilar to rasterizing things. This is doing a lot of the same things that Nanite is doing, but with an additional layer of complexity and unsolved problems added on top. To be clear, we all want to see those problems solved and allow for more efficient indirect ray traces into high poly Nanite geometry (especially for Lumen, etc.), but it is not a "RT or Nanite" situation, it's how do we solve the *additional* problems that RT adds on top of the ones that Nanite already addresses. IMO it's almost guaranteed that an efficient RT solution would also use a lot of the mesh simplification and streaming machinery that Nanite employs.

Getting more efficient RT is more relevant in a discussion of Lumen than Nanite.


Same team. Since I've been looking at it every day for a couple years now, it's very obvious when it is missing. Good art and screen space effects (contact shadows, etc) can help narrow the gap a bit, but normal maps in place of geometry are just not good enough anymore for me...


Right. Many of the quick demos people are showing off so far are less Nanite geometry demos and more GPU culling demos. Even with low detailed geometry you should enable Nanite on everything that it supports as this is key to both way more efficient instancing, but also the multi-view/mutli-res/sparse rasterization that makes virtual shadow maps way more efficient.

The discussion of displacement and to what extent we still want that in the future is a more interesting one. It may well be we still want displacement for a variety of compression/art/animation/streaming and similar reasons, but that will effectively just add more detail on the very closest levels. I can't see *not* wanting the automatic fine-grained LOD stuff that Nanite is doing in the future... it seems pretty fundamental to efficient rendering IMO and solves some real problems.

I agree and the exciting part improvement will arrive too. I know character is the worst part of modeling now when Nanite will be skinned geometry compatible I am sure many artists will be so happy.

Not seeing pop in and shadow popin is exciting too.

Seeing Nanite, or improvement of hair rendering and I hope someone will find an idea for vegetation from a geometric point of view this is an exciting moment.
 
I don't understand the argument you're making. Rasterized lighting is better than raytracing because... demons souls has a slightly above average polygon count per screen?

Because you do like the geometry density is not part of the look of Demon's souls and only art. This is very important too and this is a part where Metro is not very good. It doesn't mean geometry can't improve UE 5 prove it.
 
Because you do like the geometry density is not part of the look of Demon's souls and only art. This is very important too and this is a part where Metro is less good. It doesn't mean geometry can't improve UE 5 prove it.

Raytracers trace against geometry, that's why all rtx hardware is focused on ray triangle intersections. How much geo you have is (mostly) orthogonal -- you could totally put a demons soul scene in the metro engine and render it on a modern computer. I don't understand what this has to do with RT vs raster lighting.
 
Raytracers trace against geometry, that's why all rtx hardware is focused on ray triangle intersections. How much geo you have is (mostly) orthogonal -- you could totally put a demons soul scene in the metro engine and render it on a modern computer. I don't understand what this has to do with RT vs raster lighting.

I just say than Demon's soul's look good because of the level of geometry and I said Metro would look better with more geometry. That's all, nothing more, nothing less.

I did not talk of the lighting it was just a remark because you talk about art asset. Art asset is good because of the geometry density too.
 
I just say than Demon's soul's look good because of the level of geometry and I said Metro would look better with more geometry. That's all, nothing more, nothing less.

I did not talk of the lighting it was just a remark because you talk about art asset. Art asset is good because of the geometry density too.
Ah, I'm sorry, I mixed up the point you were making with the argument tottentranz was making.
 
The choice is not between HFW geometry density with pathtracing and UE5 level detail with Lumen.

For gods sake lets hope the choice will never be limited to HFW graphics because then there will be dissapointment even more then we have now if we never get any better graphics then a cross gen title. UE5 doesnt scream cross gen at all on the other hand.

Ok, clicking around that df video. Demons souls is a great looking game but there's virtually nothing impressive here. Gi is flat and about a zillion objects are missing shadows or any kind of ao contribution. Nothing close to what metro offers (although ds has much better art assets and art direction)

Look at the scenes with the flaming boss and seriously tell me you think they're doing a good job faking that lighting environment.
f64b62e1-1703-458b-983b-8a63feab8dce

Agree, but hey, its a first try game, and just a remaster/remake afterall.

Raytracers trace against geometry, that's why all rtx hardware is focused on ray triangle intersections. How much geo you have is (mostly) orthogonal -- you could totally put a demons soul scene in the metro engine and render it on a modern computer. I don't understand what this has to do with RT vs raster lighting.

Listen, if the PS5 had more capable RT hardware, you wouldnt have had this discussion with some.
 
  • Like
Reactions: HLJ
I'd say Metro Exodus is a good case study of why the statement "we don't need RT, we can do lighting with tricks" is wrong.

They clearly did all they could with lighting tricks in the non enhanced version, and switching over to full RT still provides a hugh uplift.

Conversely, look no further than Lego Builder or even Minecraft RTX for how you can make a low geometry game look stunning with high quality RT lighting.

Not really, Metro's non-RT lighting was pretty bad compared to most of the good AAA implementations in games. This came as a shock to me when I first saw the game in action as in their previous games in the Metro series they actually had some of the best lighting.

For whatever reason they didn't put much effort into their non-RT lighting for Exodus and it shows. So, on PC their RT was dramatically better than their non-RT, which in turn make the overall lighting in Metro: Exodus on launch with RT look so horrible (inconsistent and large delta between non-RT and RT in the game when used simultaneously as they had to do whenever indoor lighting was needed). So, that made the enhanced version look even better when you compared it to the launch version of the game.

Don't get me wrong, Metro: Exodus Enhanced Edition is one of the best RT implementations in a game currently, but the non-Enhanced Edition isn't a good one to use for comparison of what non-RT lighting can achieve.

And even with that, there are some annoyances with it that RT alone can't fix, and as some have mentioned, the RT just highlights other areas that need massive improvements (like low poly geometry) as well as better use of RT (but this might be limited by current generation RT hardware).

Regards,
SB
 
Last edited:
Back
Top