this issue has nothing to do with the twosided foliage he had to revert… this still is the overshadowing problem that is supposed to be fixed - hence why my trees arent black completely like in another post futerh above.
I couldn’t tell you precisely the CVar, but I know Lumen uses a hack for rough specular lighting (like yours above) that generally ignores fine specularity above a certain roughness threshold, so it’s functionally just clamping your light away, I believe. That being said, I’m surprised Screen Space rays aren’t picking it up. In hardware lumen and hit lighting reflections, the roughness optimization is removed.
By the way, I’m familiar with the test map you’re using, although I didn’t know where it was available for UE5. Might you know where I could find a copy?
Does this mean the sponza scene would be imported as a single mesh, or is it USD?
I just imported it as an FBX and setup the materials.
So I’ve been doing some experiments with metallic objects to try and improve the quality and I have a few notes. The attached GIF demonstrates using the RayTracing Feature Switch within the material to better integrate metals into the reflected scene.
SSR: Just to remind us how far we’ve come 
Lumen SC: Reverts to matte base color. Not a great look.
Lumen HL: Much better and sharper reflections in general as expected but now our metals look black in reflection.
Lumen SC + Fallback Cubemap: Metals are starting to appear integrated into the scene reflection, but results vary highly on the quality of the cache, as expected. Good result.
Lumen HL + Fallback Cubemap: Reflected metals are now approaching the Path Trace in appearance, very good overall and not dependent upon cache quality.
A few more notes:
Scene Captures do not support Lumen. The fallback reflections would integrate much better if the global illumination was captured. In my example scene, the scene is too dark without GI. This is the most obvious difference between the real time and path traced scene. I would love to have support for Lumen in captures.
I found getting good results with the cubemap required using the emissive channel, the base color alone didn’t usually integrate well. However, there doesn’t appear to be a way to prevent emissive materials from casting light. This is what causes the faint glow on the bottom of the cubemapped spheres.
There also really needs to be a way to disable emissive materials from actually casting light into the scene for the sake of artistic control. In this case, I just reduced the strength until they seemed well integrated but not glowing.
6 Likes
2 Likes
Worked like a charm, thank you. I searched but never came across that post.
Left - Original: Notice the glow behind and beneath the sphere from the emission.
Middle - Custom node: Glow is fixed, but the reflection is still too emissive at the base, this effect could be nice for fake caustics but bad for a metal ball.
Right - Custom Node + Occlusion Mask: A simple gradient to mask out emissive near the base of the ball. Some kind of distance field gradient may work well here too.
Edit: Nevermind on the distance field gradients - it appears neither the surface cache nor hit lighting reflections display distance field outputs. You can see my attempt at using distance fields as a mask below. The reflected ball does not have any distance gradient, making it impossible to use as an occlusion mask. Bummer.
1 Like
Lumen’s art directability has definitely been second to establishing a baseline PBR realism , and the amount of hacks and cheats I’ve found already speaks to some concerningly complex material development for a system that’s meant to ‘just work’.
Pretty much all my work has photorealism as a target so Lumen’s development has generally been good to me, but I understand for nonrealistic rendering it’s very hard to use. The biggest problem seems to be getting screen-space traces to understand what to do, as there’s no easy way to tell them more information about the scene than what’s on-screen (I’d imagine some sort of hack with a mask could be used, but no dev work has gone into a solution from what I’ve seen.
The big problem for me is the lack of multi-bounce specular lighting or a sufficient fallback method. Your work @BananableOffense is very helpful for me to understand the strengths and weaknesses of the different reflection methods, but cubemaps get us back into the same problem we’ve been trying to ray-trace out of (namely static scenes and limited perspectives). I do understand that multiple bounces of reflection incur a significant cost, and a single bounce is generally enough for many non-archviz art cases, but I’ve seen lumen reflections break entirely in any scenes with dull metal, and that’s not something I want to have to hack/art around.
For sure. True raytracing mostly just works. But in this simple scene RT cost an extra 5ms at 4k compared to Lumen. Also because RT unfortunately doesn’t support GI in reflections - even on the first bounce - metallic objects in a scene like this end up looking very poorly integrated.
The biggest flaws for me in this method is the amount of effort authoring a cubemap and a material that effectively uses it. The actual computational expense of this material is very low. Also like you mentioned, the screen trace leaves something to be desired and the effect looks its worst when the cubemap doesnt align well with the trace.
Ultimately its clear that the Lumen result is still vastly superior to SSR or cubemaps alone (especially in a real time scenes) and the amount of cases where someone will be able to heavily scrutinize the second bounce in gaming is very limited. Artists are already used to avoiding mirror finishes, now they’re at least a possibility.
For a dull metal, I’d probably force a very quality low mip on the fallback cubemap to mimic the scattering. Here’s a very quick mockup with results that aren’t completely awful.
I’d love for this stuff to be handled automatically though.
1 Like
You said it, I completely agree with you. For me, I work at 1080p and use TSR, so my actual RT cost is low enough that I have some performance headroom. And I should clarify, do you mean standalone ray-tracing (SRT, just for ease of use), or Lumen RT? I have discovered you can make them look more comparable by letting SRT evaluate all material roughness, but the performance cost is absolutely not worth the (minor) visual improvement.
It’s not that cubemaps are necessarily bad (CryEngine’s Neon Noir raytracing demo used them for dull specular, because you practically can’t tell), but they are a PATA to author, configure in such a way that looks acceptable, and check that your materials will look good with them. Not to mention, they break with dynamic worlds, although I do know that some of Lumen’s multi-view capture tech was rolled into the new cubemap implementation, so I wonder if the performance has improved enough to allow for practical dynamic cubemaps.
And you’re totally right, modern PBR art pipelines already generate content that hides many of lumen’s shortcomings, but now that we have the chance to do so much more with Real-time lighting than we used to be able to, I don’t like the thought of a minor technical limitation holding back all that potential.
And thanks for the hack, I really appreciate it. I’ll float an idea: UE5_Main now supports mirror reflections on translucency (and I will say now, Lumen and PT are almost indistinguishable in most scenes), but 5.0 is stuck with their radiance probe projection trick, which does solve light leaking at least. I wonder if it’d be possible to have subsequent bounces of reflection to simply grab from the nearest radiance probe, it wouldn’t be excellent quality but it would certainly be better than returning black.
2 Likes
Are specular reflections on rough materials at glancing angles any better with 5.1?
1 Like
In my trials with UE5_main, yes. They matched the path tracer better, but I also wasn’t rigorous with confirming material roughness and setting. They just finished a massive refactor of the global distance field that made some substantial improvements, but I don’t know about the tracing quality in particular.
1 Like
High resolution on Movie Render Queue works with lumen (rock solid)?
I did some archviz tests, and seems to work better with exterior renders, like these:
With interior renders, some GI artifacts appears.
High resolution (tiled) interior in Movie Render Queue:
Interior render without High Resolution:
Again, High resolution (tiled) interior in Movie Render Queue:
Same interior render without High Resolution:
High resolution (tiled) interior in Movie Render Queue:
Same interior render without High Resolution:
Outdoor scenes being a higher quality than indoors makes quite a bit of sense: With outdoors, it’s a lot easier to terminate rays early because they can’t bounce as many times before hitting the skybox. The combination of high albedo (near-white) plaster and a glossy floor would definitely stress-test lumen, especially as most of these scenes are almost entirely indirectly lit.
The artifacting is bad, although I don’t know why enabling high resolution seems to be causing problems. It’s particularly struggling with any small occlusions, and the general solution I’ve found for that is to just crank Lumen’s quality settings to the max and supersample. Expensive, but acceptable for the MRC.
1 Like
If I may ask, how are you achieving the reflective water? Unless you’re working with an experimental engine version (mirror translucency/SLW reflections didn’t make 5.0), I’d presume you’re using either Planar reflections or a render target?
Artifacts only appear when I enable the Tiled high resolution option in Movie Queue (for high resolutions screen shots). Cranking Lumen GI settings dont work
With high res disabled, no GI bugs
Translucency - Ray Tracing