Just imagine for a sec how that would have looked.
Unreal Engine 5, [UE5 Developer Availability 2022-04-05]
- Thread starter mpg1
- Start date
Just imagine for a sec how that would have looked.
DavidGraham
Veteran
Well, not quite, I disagree a little.
Minecraft and Quake 2 RTX achieved almost full path tracing on a 2080Ti, well in excess of 60fps @1080p native, though 1440p native dropped that to ~45fps.
Most scenes in Metro Exodus Enhanced Edition work 1440p60 on a 2080Ti, heavy scenes drop that to ~45 fps as well.
Mixing a lot of RT effects (lighting + shadows + reflections) as in Cyperpunk or Control do 1080p60 on a 2080Ti as well.
Games with only RT reflections (with good resolution) can do 1440p60 on a 2080Ti.
The more powerful 3090 can achieve much more obviously, yet in UE5 SW RT all it can do is 1080p60.
DegustatoR
Legend
I disagree completely. Even the current Lumen approach is light years ahead of previous gen lighting. People just don't see it really because they don't get the distinction between static and dynamic global illumination. It will take some number of games for general public to get it.
We badly need such a tech showcase on PC, it would be so awesome. Imagine a tech demo that uses all next gen features. Mesh Shading, Sampler Feedback, DXR 1.1, DirectStorage, DLSS, VRS, and Lumen+Nanite too if its in UE5. Give them all to me in one single demo. It would blow people's socks off.
It has been a while since the last Nvidia tech demo and 3DMark. We really need tech showcases on PC back!
Yeah that would be.... i mean then we can talk leaps
Something like a 3090/6900XT, fast 12 core zen3 system, 7gb/s nvme (with direct storage compression on the gpu), 32gb of fast ram. Then this could scale nicely with settings to RDNA3/RTX4000 etc.Guess a tech demo could be done, actual game, probably not.
No matter if DXR is on or off. On a 1500 bucks GPU.
I tell you: We can do all this on a PS4, at higher accuracy and less lag. 'Realtime', not 'interactive' as shown. In terms of GI. For nice reflections next gen is needed.
Actually i'm mostly amused about industry attempts to solve GI, so no need to hurry. But proof is coming...
Yeah that would be.... i mean then we can talk leaps
Guess a tech demo could be done, actual game, probably not.
But then only a fraction of people, if any, would be able to run it on their machines. That would be a bit overkill.
Requirements for such a next gen showcase could be any DX12U GPU, 6 core/12T CPU, 16 GB RAM and any NVMe SSD to run it properly. Any lower and its sacrificing/holding back graphics. Any higher than that and its excluding way more tech geeks than needed
These requirements would exclude a ton of PC users already.Remember, scaling is important as well, even for such a tech demo. I assume scaling could be from 1080p 30 FPS with DLSS to 60 FPS on a 2060 up to 4K60 on a 3090 with DLSS Quality. That would make the most sense.
DegustatoR
Legend
I wonder how UE5 would look if it would require DX12U h/w. Something tells me it would be quite a different beast altogether.
DavidGraham
Veteran
The point is to show that hardware RT is still ahead in terms of performance compared to software.
A 3090 can render path traced Minecraft or Quake 2 comfortably with more than 120fps @1080p native, it can do 90fps in Metro Ultra GI @1080p, or do 1440p60 with ease, same in Control and Cyberpunk, games with only RT reflections achieve even more spectacular results.
A good question. I guess for mesh shading, not much would change as Nanite and its micropolygon pipeline is something else entirely. And they said for higher polygon sizes they will use mesh shading in the future, so that's as good as it gets in terms of DX12U support. It also depends on how good Nanite is going to be for deformable meshes and stuff later as right now its not supported. Could be possible Nanite really sucks at that even when its supported and devs might want to use mesh shading for any kind of dynamic geometry, then mesh shading would be indeed very useful.
As for Sampler Feedback, UE5 is already crazily efficient in terms of VRAM consumption going by the demo which is great news. But I do wonder if Sampler Feedback could push that efficiency to the extreme. Nanite, Virtual Texturing and Sampler Feedback (Streaming with DirectStorage) combined could be quite the dream team I imagine. No doubt support for Sampler Feedback will come at some point as well as VRS. Hopefully sooner rather than later. DXR 1.1 too with its inline RT capability.
So yeah I do think Epic is going to add these features at some point eventually. Then it's a decision at making the game require DX12U rather than an engine related decision.
That's expected. Otherwise we would not need RT hardware.
And still i've seen Metro goes down to 30 fps on a 3070. So the difference is not large enough to convince me.
Minecraft is not PT. They use caching (which can give the same quality in theory, but Minecraft is far from that). Quake2 or Marbles is PT.
However, no need to argue. We'll get that damn photorealism, and HW RT will be part of that.
DegustatoR
Legend
I think that Lumen would be affected the most by switching to DX12U baseline.
Alright hold on for one second here... it's a bit disingenuous to talk about "native" resolutions in cases like this where everything is so thoroughly denoised, temporally reprojected and so on. I guarantee you would not be happy with the raw path tracing samples being rendered every frame, and you'd be even less happy if the BVH's were rebuilt every frame (although obviously in the Minecraft and Quake cases, the geometry is extremely simple).
I'm don't mean to knock on any of those examples you gave as they are all great implementations that fit the content and art well. But there's not an apples to apples way to compare them in terms of "resolution" and performance the way there used to be, not without at the very least using the same content and camera movement.
It would be great if we could all rely on triangle RT fundamentally with highly detailed scenes fully represented in BHVs that are dynamically built and updated on the fly. The reality is none of these examples can do that - they are all making various sacrifices that fit with their content, much of it around only representing relatively static, low poly RT scenes. This is indeed a good tradeoff for current hardware, and it's one we'll likely have to continue to make for some time.
With a fully dynamic scene and no precomputation of anything (form factors, acceleration structures or otherwise)? I mean we all know things like Enlighten and such can be extremely cheap (like... mobile-cheap, not even PS4)... the expensive part - as always - is dynamic indirect visibility. If you have some special sauce for that I'm sure everyone would love to see the demo
Fully dynamic (rigid transforms or skinning, dynamic topology like fluid or non precomputed destruction would add costs), yes.
I trade some error for performance, but it's bounded, and invested to improve time complexity of the algorithm.
I'm done with that for years, but tools to preprocess data structure (surfel hierarchy) has thrown me into the rabbit hole of global parametrization.
To get some more profit from this work, i'm currently experimenting on how this could ease up content generation and level editing. Seems very promising, but... well, you guys have rejected things like geometry images for good reason!
So i need to finish all this first. Without tools there is no point to show a demo.
Frenetic Pony
Veteran
With a fully dynamic scene and no precomputation of anything (form factors, acceleration structures or otherwise)? I mean we all know things like Enlighten and such can be extremely cheap (like... mobile-cheap, not even PS4)... the expensive part - as always - is dynamic indirect visibility. If you have some special sauce for that I'm sure everyone would love to see the demo
That's my question for Lumen, all the other things I can get, but how do you update visibility even there? Guess the Siggraph talk will be revealing. Of course anything even better is uhhh, better.
Thinking through the question of moving objects myself... You know maybe you need a spatial cache of probes all over as well as surface cache, sparse probe grid like RTXGI etc. etc. That gives you all translucency and volumetric for one. But once you've got the spatial cache evaluating lighting on hit becomes much, much cheaper as well, as there's no recursive rays. That's how you do skinned models and small foliage, shadow maps give you direct lighting, probes indirect, you don't need to update visibility for skinned objects at all beyond final gather. They'd contribute to the final gather pass, show up in diffuse and reflections just fine, but as long as they're not injected into the multibounce lighting injection they shouldn't produce any artifacts. Sure there's no multibounce contribution off them, but if they're small enough that shouldn't be the most noticeable thing.
Taking it a step further, the multibounce for Lumen is just corresponding different areas of the "cards" cache with each other yes? Well if you correspond probe samples with the surface cache, you can do the reverse too. All surface cache lighting other than direct could come from the probes, not directly from the surface cache. Disadvantage is less spatial correlation, any tight/small area without a probe loses indirect bounces between each other. But all visibility is to/from probes! This potentially simplifies visibility updating and, perhaps just as importantly, eliminates noise. No surface cache noise at all like Lumen has, problem solved. Further, spatial probes are how you could solve large foliage too. Treat large foliage as static for probe visibility and surface caching, it contributes to multibounce and you get no lightleak or energy loss. However for final gather treat it like you treat the skinned meshes above, include movement and evaluate lighting on hit. You might need "special" higher res clusters of probes and tweaked probe visibility influence (like tweaked self shadowing), but in my head it seems to work out.
There's no recursion during Lumen sampling either right? My understanding is that to calculate bounce lighting at any pixel in the scene you ray march the SDF from that pixel and sample the surface cache just once at the hit point.
Given skeletal meshes aren't part of the Lumen scene how is it handling diffuse occlusion? If a character is standing in front of a wall that's receiving GI does the GI bounce "through" the character but ultimately get occluded by a shadow map? It'll be interesting to see how Nanite & Lumen hold up in indoor scenes.
Last edited:
Daniel showed a pretty neat indoor ArchViz type scene on the stream on Thursday. While ArchViz isn't specifically a target for Lumen, the results held up fairly well I think for real-time! Worth a watch if you missed it.
Yep I watched the entire video. You mean the bedroom scene? Looked really great but that was with quality cranked to 11 and it was all static assets.
Frenetic Pony
Veteran
As Andrew said, the stream shows off a lot. But you've got it right, characters and trees and etc. don't show up in indirect lighting at all right now except for in screenspace traces, which is used as combo detail trace and ray bias to prevent self shadowing artifacts; or in reflections if you've got hardware RT enabled (no diffuse).
Similar threads
- Locked
