Unreal Engine 5, [UE5 Developer Availability 2022-04-05]
- Thread starter mpg1
- Start date
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.
https://www.nvidia.com/content/PDF/nvidia-ampere-ga-102-gpu-architecture-whitepaper-v2.pdf
DegustatoR
Legend
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.
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.
Subtlesnake
Regular
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.
Look at the scenes with the flaming boss and seriously tell me you think they're doing a good job faking that lighting environment.
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)
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.
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 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.
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/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:
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.
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.
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.
Ah, I'm sorry, I mixed up the point you were making with the argument tottentranz was making.
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.
Agree, but hey, its a first try game, and just a remaster/remake afterall.
Listen, if the PS5 had more capable RT hardware, you wouldnt have had this discussion with some.
Silent_Buddha
Legend
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:
DegustatoR
Legend
Exodus rasterization based GI is exactly the same as in any other game with dynamic GI of the previous generation h/w. It may not have the art to the level of RDR2 and such but it's tech is on part with these games.
I agree completely. Geometry should have been prioritized ahead of raytracing. As in we should have had mesh shaders in DX9.
Playing Dishonored now (2012 game) and there are wheels that look like they're made out of 5-6 triangles. Terrible.
Similar threads
- Locked
