I disagree. I think this is something the Epic team needs to see as they have made this mistake in their 6 billion dollar game(FN) . My post 1048# and 1044# shows how and we need micro-optimizations. For the record though, I did recently find something very interesting in the VSM documentation. 2 things that may save me the performance I’m talking about.(nope, already enabled in project)
The lumen team needs to know not everyone thinks like the casual, dlss-craving majority when it comes to UE5’s performance. This includes the Lumen team.
I have said my peace and made my case for the Engine Devs(Even the Lumen Team) .
Slapping on an upscaler and thinking we need better gpus than the current gen to resolution scale is unaccepted to one of their customers.(Me,my studio, and plenty of gamers included tbh)
They get plenty of sugar coating from casuals. I have to balance that crap out since no one else will.
We should just entirely stop abusing the Lumen thread for something this nonsensical (even if related)… I would actually prefer it to be used for Lumen again, not for "Epic, cant run lumen at XX fps.
To go against the grain here, I would like it if the team would actually lower the performance even more, so we could have even lower frames per second
For quality reasons of course.
This seems aligned with Epic interests. They seem interested to push Unreal for films, but in order to get Unreal to replace offline renderers - a higher quality is needed.
One could reply that I can already do that with MRQ, but in fact no matter how much you push the settings and the CVARS - even if you get 1 frame per second - the quality hits a ceiling. For example you cannot get high quality or sharp area shadows generated by secondary bounces. You can only get very blurry and low quality ones.
And the Pathtracer is not a good replacement for Lumen. At least in the shape it is now.
And Lumen is almost there, we need just a few more improvements.
Fingers crossed for that surface cache-less version being a work in progress, I very much like the surface cache but it’s going to take a while before it gets into its peak quality wise; I’d much rather brute force, even if frames are going to be terrible, upscaling should help a bit and hopefully with further TSR and other upscaler improvements, a surface cache-less Lumen would fulfill all the quality head’s needs until SWRT catches up (I am praying for a caustics implementation sometime down the line!! Even a simple approximate or faked caustic shadow overlay would be awesome, like how those minecraft shader mods do colored shadows)
I am seriously in agreement with you there. While I do really enjoy lumen’s role as a game technology, I think I’m starting to see the incredibly utility in having something that can be ‘interactive’ without needing all of the shortcuts that game lumen has. Baking things out with MRQ has given me pretty astonishing results.
I’m not arguing with you, but I’m curious if you have an example of the phenomenon you’re talking about?
When I’ve compared maxed-out lumen vs. PT output, I agree that there is optical behavior that lumen simply isn’t generating, but in my experience lumen has two main breakdown points:
Contact shadows. Maybe this is unavoidable, but even with the HWRT version of their contact traces system, lumen can very much have a ‘painted-in’ appearance to the fine shadows in corners and crannies.
This is a slide taken from the lumen SIGGRAPH presentation last year. It illustrates their different light transportation methods by range, and IMO the area lumen struggles most profoundly at is between contact AO and their screen-space radiance probes. Where I see the path-tracer consistantly outperforming lumen is when there’s detail that’s less arbitrary than AO shading, and still smaller than what the (very very downsampled) screen probe gather can resolve).
Specular noise and resolve. I’m absolutely beating a dead horse here, anyone who’s seriously worked with lumen+all the engine devs know that lumen reflection is very unstable at high roughnesses (.2-.4). If you have noise in the diffuse final gather and you want to render it via the MRQ, you can just crank the quality setting up higher and you’re fine. But if you increase the lumen reflections quality slider, noise gets worse. There is no way, no matter how far you crank the settings, to get genuinely stable reflections out of lumen, and I think that was part of the point @Sebastian was making, if I understand you correctly. And even with all that noise, lumen often over-blurs fine features, so detailed specular lighting can get smeared into uselessness.
After the noise improvements and transparent reflections from 5.1, the improved foliage support, surface cache, and thin feature shading from 5.2, and the (inbound) multi-bounce reflections and HWRT optimizations of 5.3, lumen is absolute leagues a more capable system then 5.0. When they get substrate fully working, I think we’re really close to having something that can fully match PT in quality. I’m really excited.
We need to keep Lumen separate from non-realtime applications.
This is biggest problem with Unreal, is all of the rendering crap. The more muddled Unreal becomes, the harder it becomes to optimize.
We have PT, deprecated Hardware GI etc, that don’t need the fixes Lumen so called need.
Krzysztof.N did say that struggling to improve the surface cache representation quality has been a major bottleneck of lumen. I’d be really curious to know what a surface cache-less version of lumen is, would it just be the ScreenProbeGather used recursively somehow? How would they stop performance from exploding? Is it just hit lighting for GI? I’m truly curious and really don’t know.
Well I have good news for you then. I heard that the Substrate team is working on colored shadows RN, although I don’t really know when it’ll be coming out. I got to try out colored shadows on NVRTX, and while the effect itself was really really impressive, the UI was so unintuitive that it really wasn’t practical to be using it unfortunately. If epic can make it ‘just work’, I think we could be in a very exciting place.
Fortunately I haven’t yet found issues with reflections. But I’m mostly rendering vegetation and maybe non mirror metals. I also found AO ok, even if imperfect and yes lacking in contact where it comes to details, but still ok in my projects.
The V shadow maps can also be dialed in a way that can provide good contact shadow and with some engine tweaking maybe even reasonable soft or area shadow where the shadow is at the distance from the object.
Maybe I’m not explaining very well, but I rendered some images to show where Unreal could benefit from improvements. Look what type of shadow the object has from indirect lighting. It’s sharp at the point of contact with the ground but gets very soft as the shadow gets some distance.
In the second image there’s a light projected on the wall and that projected light generates again a soft shadows but sharp at the base or at the contact points.
And a bit off topic here, but as far as I know, you also cannot get this kind of depth of field. Where the DOF is so large, the area in blur gets semi-transparent. And the edges are - again - transparent. If you can get that, please tell me, because I wanna build my own solution for that in Unreal, and I’m guessing it will take me quite some time to get that.
Virtual shadow maps are definitely closer to traditional shadow maps in terms of still requiring tuning to get good results. I’ve never had to do more than increase the SPP for RT shadows and enable the nanite ray correction, but VSMs required a lot of tuning for acceptable results. There’s a reason the documentation says ‘plausable’ contact shadows and not ‘physically correct’.
I see what you’re saying here, but in my eyes, that seems like pretty appropriate radiometric behavior. If you have comparisons to the PT however, that could shine more light onto the behavior. The path-tracer is the ultimate ground truth for Unreal, and I think inter-engine comparisons would require exporting the scene as an FBX and comparing against other renderers.
If you’re referring to UE rasterizer’s bad DOF, I’m not exactly sure what it would take to fix that actually, as that’s a very specific series of optical phenomenon. The big issue may be sorting problems due to translucency, but I’m not sure how a custom solution could performantly improve on that unfortunately.
In Unreal PT would get a similar type of indirect area shadows like in the images posted. Lumen amazingly can also get that type of indirect area shadows with the difference that they completely lack the contact part - instead of being sharp at the base, they already start very very soft or blurry.
And about the correct looking DOF, I meant to say I already know how to build that, I already did it back in 2010. I don’t wanna post the link to my website but you can find it if you search “cryengine film tools”.
But maybe someone else already did that, or maybe the engine can achieve that already, in that case I would prefer to not spend weeks trying to build something already possible with Unreal.
This is a great demo someone on my linkedin did. All of you can try it, and check how poor performance and noisy Lumen is for an actual game scenario: Corridor by Dylan Browne
PS: Will DLSS 3.5 save Epic from noise? (So hyped about this)
Although I’d like to see it running live in a game (sans video artifacts), I think this sort of intelligent ray denoising could make a very big difference in certain game scenarios.
The bottleneck is, of course, the fact that it’s proprietary. If it can’t run on consoles, Epic’s probably not going to implement it; especially considering that it requires specific hardware acceleration to run. However, if there is some way they could implement a NN to do specific reconstruction work, it could potentially make a big difference in RT lighting quality.
Sure. But if Epic is incapable of achieving it, it will be a solution for, at least, some (a lot) of the users, usually the high-end ones (which, anyway, will usually be the only ones using heavy ray tracing)
I also am not exicted about or interested in the frame generation, but Frame generation and Ray reconstruction are presented as being independent from each other But i also don´t have to worry about that, because I cannot use Frame generation, since i only have a RTX 2070, so if anything, i could only get ray reconstruction, and thats the one i am excited about.
And since they used Cyberpunk as one of their testing grounds, i tried to find that place, they showed in the video, so that once Phantom Liberty and DLSS 3.5 gets released, i want make a comparsion to what it looks for my system.
So it will be interesting to see, if Ray Reconstruction really will be a separate option to turn on and off, just like its right now with Frame Generation and f.e. DLSS Super Resolution.
And i found it, its in Heywood - Vista del Rey, close to the Metro Congress and MLK fast travel point, if someone else want test it ^.^
How i read that image, the important part is in the brackets right below those listed categories, and under Frame Generation is still “RTX 40 series GPU” listed.
Thats how it currently looks in my options menu in that section:
As you can see, DLSS Frame Generation is greyed out for me, because i just have a RTX 2070, so no chance to get that, and DLSS 3.5 would not change this. It even says it ingame, that this requires a RTX 40 series card.
But Ray Reconstruction is listed for all RTX cards, and all info i could find for that points into the same direction, that it is independent from Frame Generation, just like f.e. Nvidias DLAA is a separate feature and a separate option in the game.
Take a look at this screenshot from Nvidias video, there Ray Reconstruction is only tied to Super Resolution, and Frame Generation comes way later in the Pipeline as basically the last step in the chain.
nvidias (and AMD/Intels) “toys” will never be a solution to anything, and in fact they are the very thing causing the issues - because instead of optimizing stuff, people are like: “yeah, whatever”
There were games recently, that had a 2080/5700XT as minimum system requirements, WITH DLSS/FSR einabled - for 1080p!
This isn’t related to anything currently being discussed, but I did want to share my wonder at something: Upgraded an old UE5EA test level scene to 5.2, and I am blown away by the performance difference. in EA, this scene (HWRT, what counted for hit lighting at the time, ETC) wasn’t getting a consistant 20FPS, but largely CPU bound. Now, 5.2, I’m hitting a stable 60 with much higher settings. Their work was truly astonishing. That scene included emissives, tons of tranlucent and alpha-tested effects, volumetric fog, all of it. Even with SWRT, the performance and visual quality are way better. Between streaming improvements and the lumen scene feedback mechanism, reflections by and large hold up really well.
I guess all I’m saying is that I’m blown away by how much better lumen has gotten in such short time. The technology really has come a long way, and it’ll keep getting better.
:
But i also don´t have to worry about that, because I cannot use Frame generation, since i only have a RTX 2070, so if anything, i could only get ray reconstruction, and thats the one i am excited about.
