None of these affect the reflection quality or look. 5.2 is a big downgrade compared to previous version in terms of reflections.
1 Like
And perform worse
That is true, and it’s because (to my knowledge), you’d need multiple concurrent depth peeling passes for that to be possible, as you’d need transparent surfaces to be able to recursively discover other transparent surfaces. With how radiometrically complex that scenario is though, at that point you’re just better off with the path tracer.
Now that is interesting, I was doing some profiling of my own and it appeared to be running a fair bit better, and SWRT quality was improved as well. How do you mean a downgrade?
By ultra, do you mean cinematic? I’m just trying to understand.
It appears that your car lacks surface cache representation, I’d definitely do the surface cache visualization and see what it’s telling you. For lumen to look passably similar to the path-tracer, you’re going to want hit lighting reflections, which do not appear enabled in your video either.
Lumen is alas not a 1-1 match for the path-tracer, and for best results you’re going to want analytical light coverage so that lumen can do good highlights in reflections.
It’s all enabled on highest setting, I did a more simple scene to show the reflections problems. It doesn’t matter on what ray lighting mode I work, they all do the same reflections, only the quality slider really does a slight quality improvement. You can see how much screenspace dependent the reflections are and if you look at the surface cache reflections they look weird too.
There is no possibility it can match the path-tracer but I thought we can have a lite abstraction of RTX reflections back from 4.27.
Is it possible to override the max trace distance scale even further through console command? I have a large scene and need Lumen to trace much further than what is does currently.
However, the path tracker cannot use exponential height fog, which is also an important function in building visualization
Just a quick heads up:
Never do performance-comparisons “in editor”, or in development builds, since this is not representative of the actual performance. (Create a shipping build, and compare actual fps.)
If Epic added some debugging stuff in the background etc. this can and will have an impact on in-editor performance.
For example, my project currently performs almost twice as good in shipping builds than development, and editor isnt even something to consider.
From my experience, 5.2 performs pretty much the same as 5.0 - at the same settings. (but some settings changed, which is why it looks different etc.)
EDIT:
Actually, I can show that your comparison doesnt work.
I marked green what is faster than 5.1 and red what is slower:
All of this lies within “margin of error” within editor (and the results you get can change a lot from frame to frame too…), especially if the frame is that different.
Here is the exact same scene, without moving the camera or anything, in 5.2, but I asked the Engine twice to give me the performance values.
As you can see, there are large differences between each request, despite nothing changing:
Even IF everything would perform equally between 5.1 and 5.2, you still would get random differences each time you tell the engine to make that list.
The fact that lumen runs as good as it does is kind of a “miracle”… my game runs at (barely) 30fps on a (fast) 1060 with it enabled (but some other settings tuned down), native, 1080p… and your 3060 is roughly 2x as fast as a 1060…
CPU: Ryzen 3700X
GPU: RX 6900 XT
Keep in mind, I am running 1440p in my screenshots, my numbers are not directly comparable to yours - but your card can run my game at roughly 60 fps, with lumen enabled, probably more. (1080p, native)
But my games have a “fallback mode” (aka: when Lumen is off), which makes them look like they would have in UE4 - so I dont really care that much if I get 55 or 65 fps on a 3060, or about older hardware.
The path-tracer actually can, you just have to enable it with the right settings. I used it a few days ago in 5.1.1.
Honestly? That looks like essentially the correct behavior for lumen. Lumen does diffuse GI very well, but mirror reflections aren’t going to look good if there isn’t an analytical light source to let lumen do the NxL on. If you increase the roughness by even a bit, a lot of that effect will go away.
The GI is screen-dependant because the surface cache that lumen traces against does not (and without hit lighting, cannot) match the GBuffer lighting. The best you can do is hide screen traces, or disable them, but you can’t create a good quality match in the worst-case scenes.
Plus, unlike standalone RT reflections, we have accurate specular occlusion, but I still hear your frustration with some of lumen’s limitations.
Thank you for that profile, and your comments on putting a fallback in place for the non-lumen users.
I gave some feedback on the UE documentation for lumen that I felt there wasn’t enough coverage on the CVars and necessary quality levers to get lumen running well, and while I’m unsure if it was me or others who wrote in as well, they did actually listen and create this:
This has a variety of CVars, corner cases, and limitations/solutions documented to maximize performance out of lumen, and it covers basically everything I feel like wasn’t documented before. I’m very happy with it.
I feel like expectations for lumen aren’t well set because the technology and its’ limits aren’t particularly well understood. It’s an amazing piece of technology, but it has frustrations and design limitations like anything else,
2 Likes
I think your post is missing something, in particular the thing Epic created 
Yep, had a saved edit there and didn’t realize I failed to post it, whoops!
iirc, I said the same at least once in this thread, but a while ago - since Lumen was quite the blackbox to deal with. (and technically still is for the vast majority of people)
I sometimes get likes for my rather old posts (which sometimes are nanite stuff, because people confuse lumen/nanite) in this thread, where I told some tips/tricks for lumen, because people dig through this 850+ post thread to find information about Lumen. I also regularly find something new to work with (or around), like the Mesh Distance Fields for Plants (one of my more recent posts here).
Lumen is absolutely awesome and I am more than happy that we have it, AND that we have rather easy access to the Lumen team through this thread.
I am very grateful for that, yes. I’m always a bit amused when people lump lumen and nanite together when they’re talking about rendering problems, as the two systems are very much not the same thing (even if they are interdependent in some use case ways).
And I’m with you on the black box comment, lumen from the PPV largely seems to be a magic button you hit that gives you GI and reflections, and you just sort of take what you are given. I remember in EA when you had to enter ‘4’ into the reflections quality slider in order to get hit lighting reflections at all.
And while things are much improved now, there’s still a ton of stuff people do not understand, including the basics of how lumen works to begin with. For a lot of the non-rendering people I’ve talked to, it’s thought of as this magic machine that takes in perf. and spits out GI, but it’s so much more versatile than that.
Personally, I’m really looking forward to the future developments the team talked about a while ago: explicit sampling of emissives (still don’t know how exactly they’ll pull it off, maybe borrowing from the linearly-transformed cosines paper perhaps?), and even if it’s not ‘strictly’ indirect lighting, I’m really excited for colored shadows.
Is there a tutorial that can be implemented? I am talking about fog with exponential height fog, not volume fog, and I have tried many methods. There’s no way to achieve it，On path tracing
I have two questions about the reflection.
First in 5.0 the lighting is only movable, if I set to static and build, there is no light. This is not big issue for my project, but in 5.1 and 5.2 the indirect lighting is only static, the movable lighting does not have indirect lighting. Is here any parameter that can allow movable lights to have indirect light in 5.1 or 5.2?
Second, in 5.0 when the light fall on the texture it make indirect light that make the scene to look more natural while in 5.1 and 5.2 the indirect light decrease too linearly when the distance from the source is further away. This is completely different compared to 5.0. Can I achieve this effect in 5.1 or 5.2?
Works fine for me in 5.2, so you might want to check your settings/setup for Lumen.
White light on colored surface, same grey box you use, and an additional white tile at the bottom to more clearly show the color-change of the light:
This is confusing… you dont build lighting with Lumen.
1 Like
Distance fog, on the path-tracer? I wouldn’t know if that would be possible, as it’s somewhat workflow-unintuitive to combine physically-correct rendering with a nonphysical fogging scheme. Let me try a few things out.