Many thanks for that information. For this particular problem, making a mirror actually look like a mirror within a small interior space, @painx what solution would you recommend please?
Using a CaptureComponent2D camera and render target unfortunately isn’t a solution because there are objects directly next to the mirror, which appear distorted/out of perspective in the reflection.
There is no ideal solution short of hardware raytracing. This is part of the reason hardware raytracing exists and what it set out to solve (in addition to lighting, etc).
Without RT, planar reflections offer the most realistic reflections for flat surfaces like mirrors and bodies of water. It is effectively a specialized scene capture and as a result the performance cost is very large.
Generally any other method will have artifacts like misalignments and distortions. This is why almost every mirror in video games for the last two decades have been too dirty or broken to provide a clear reflection.
As was previously mentioned, the higher quality section (left) in that example is the “screen trace” and the lower quality (right) section is the hardware raytraced section. Raytracing in Lumen isn’t done with a full quality version of the scene even in hardware mode there will be compromises.
If you want to make the whole reflection raytraced to remove the discontinuity you can disable screen tracing using a console command.
There is no way to make the whole image as good as the left half with Lumen because you cannot screen trace something that is not on screen.
The only way to make the quality of a mirror reflection as high as the rest of the scene is to use another form of raytracing instead of Lumen which makes different compromises (like the nvidia RTX branch.) To be clear it is not without compromises either, but it doesn’t exhibit the blotchiness that Lumen does in this specific case.
That said, the limitations of hardware Lumen are far less noticeable in a more realistic environment. A totally smooth white box is one of the worst case scenarios because the lower quality of the lighting cannot be disguised as it would be in more complex and detailed scenes.
Also, side note - this is derailing the feedback thread a lot since none of this is new feedback and really just project specific so you may consider a specific thread for it.
I had hoped there might be a way to enable screen tracing to a greater extent, however that is understandable that it isn’t possible. I had experimented with disabling screen tracing already, and using other forms of raytracing, however the effect they made on how the other objects within the scene appeared was worse than the issue of the mirror not appearing like a mirror.
Thank you for that feedback, I will ask any further questions in a project specific thread.
What @BananableOffense said, you are left with this reflections system. My personal workflow is in most cases to turn off screentracing and let the surface cache do its work although even in that case the surface cache reflections are quite blotchy. I wish the devs could make it possible to use RTX reflections or some form of hybrid reflections (from 4.27) with Lumen together.
I have an archviz scene in USDStageActor in UE5.2 and I’m having a problem with the reflections in the mirror. Native objects like cubes and spheres, as well as imported .fbx files, are displayed correctly in the mirror. However, USD meshes stored in the persisted data are not reflecting properly. I am using Lumen GI and Reflections, Virtual Shadows maps and RT Shadows. I believe the issue lies with the USDStageActor, as it doesn’t allow Lumen to calculate these reflections. The problem only occurs with the standard mirror material, as other reflective acrylic materials appear fine. I hope this issue will be fix in UE5.3. Thank you!
Another one with reflection issues 
Please Epic, give us a highly precise RT reflection system, even if it’s so expensive! At least for ‘industry’ developers.
In the meanwhile, the best image quality and maximum realism can be achieved with baked lighting and RT reflections. But as RT reflections (deprecated?!) have some bugs in UE5 (already reported), I would use UE4.
Lumen is only useful for people needing dynamic changing illumination (or geometry), but it will give you less lighting quality, less reflections quality and a huge performance drop.
PS: Only use Lumen when really needed. Only use UE5 when Lumen (or other very specific tool, like PCG) needed.
Check the lumen debug scene under lit, that’s what lumen is working off. Lumen needs cards and mesh distance fields, otherwise it is screen space only.
Out of pure curiosity, what do you characterize as ‘highly precise’, versus lumen?
In my understanding, lumen is designed to fill a solutions gap between very cheap reflection captures and full-on path tracing. At the highest quality setting, lumen is almost indistinguishable from the path-tracer minus detailed GI in mirrorlike reflections. If you truly need that quality level, you always have access to the path tracer. If you’re thinking about some other solution in between lumen and the PT though, I would be interested in hearing it.
Hi blackwell,
I’m not an expert in rendering pipeline, but I would imagine something like a pure raytracing reflections, even if rendering the scene a second time, from the mirror (when in view, of course), is needed (it could be adjusted to render at a half of the resolution, for example, as you could do with RT reflections, or with render targets).
But yes, I’m thinking about a different solution between Lumen (which I think is becoming quite good in terms of lighting, but not reflections), and path tracing, as it’s not a realtime solution so totally useless for interactive ArchViz, for example. It would be a different story if it would be a realtime Path Tracing.
My other solution is the one commented: UE4 with RT reflections and baked lighting (but it’s a pitty this is the only alternative). Why UE4? Because RT reflections are deprecated in UE5 and buggy.
Do you think about a better solution for realtime ArchViz, realtime Automotive (and a long etcetera) and not being shamed in front of the client when he sees something like the Lumen reflections? I’m also very interested in hearing it because my work depends on it.
The problem goes from the USD export setting in Blender: it converted m to cm. As mentioned in the post below Lumen does not process small meshes. Also I would add to Yaeko’s post below that in an archviz scene please encapsulate/shield the interior in black protector meshes to prevent light leaking. To deal with reflections in reflections you can use this trick. Also I recommend to triangulate large areas like walls.
Now the mirror works in Lumen context, but of course it has some artifacts. But I hope that reflections become better and better in new versions of UE5. Also materials like chrome in MRQ using Temporal Sample Count have very bad smooth artifacts.
“Lumen is indistinguishable from the path-tracer” → This statement might be true from a person’s perspective who is almost not dealing with art everyday . As @Miguel1900 stated people need accurate reflections for their realtime projects and with the current system not achieveable. Best solution right now is probably to make RTX reflections work with Lumen; or simply revive and fix the RTX workflow from 4.27 and make it work in UE5.
Ah, I see. I’m both very much into rendering as a hobby and (to an extent) for my work, so I’m probably approaching this from a different perspective than others, that helps.
The current state of the tech? Multiple bounces of lumen reflections are already working as a feature on _main and are due in 5.3 I believe. Fundamentally, GI and reflections refer to the same thing, which is indirect lighting, it’s just the roughness that makes a difference.
I can’t think of good software that can do that sort of work in real-time (GI in reflections is a hard problem for a number of reasons), but baked lighting is probably a good option for now alas. The fundamental issue is that long, diffuse rays are extremely expensive to compute, which means you want to do it as little as often and reuse as much data as you can. Lumen does GI by tracing lots of short rays from probes and filtering and interpolating the results, but doing so for GI in reflections would mean making those computations again for every bounce. They instead cache that data, but the cache is lower-res than the scene itself.
Most of that was pretty technical, but the bottom line is that there really isn’t a better solution at the moment, but that’s not to say there couldn’t be one. Check out Nvidia’s branch of Unreal engine (NVRTX) and they may be able to scale higher in quality than Epic’s, in some ways.
I am actually working with the art side of things nowadays, but I can understand your frustrations. At the current moment, lumen supports everything RT reflections do and more. But I think there may be some confusion over what standalone RT reflections actually did.
To borrow unapologetically from the lumen team’s slides,
Standalone RT can look ‘cleaner’ than lumen, but that’s only because it’s missing a lot of scene data to operate off of. I suppose it’s down to whether or not you prefer ‘cleaner’ but less complete lighting, or ‘messier’ but more accurate lighting.
The lumen team did mention that they’re working on a ‘surface cache-less’ lumen pathway for those with very high-end graphics cards, so you all will likely get your wish anyways. I’m not trying to foment disagreement or argue that anyone’s use case is illegitimate at all, I’m just looking to lay out the technology and its current limitations.
What slide deck is this from?
The lumen team’s SIGGRAPH presentation, if you’ve ever really wanted to dig into why lumen does what it does, this is an asset:SIGGRAPH 2022 Advances in Real-Time Rendering in Games course
I had to reread it probably four times at least for all of it to make sense, but once it clicks, it became way easier (for me, at least) to understand what was making lumen act up and how to fix it.
Thanks, I had seen the Siggraph 2021 presentation regarding Lumen’s radiance caching but I didn’t know there was another one in 2022.
That’s so cool, what are the requirements for a PC to handle all this?
Depends on what you mean by ‘handle’. Lumen can scale pretty well to modern hardware. A Maxwell or GCN-era card is needed for it to run at all, but in pratical terms a 10-series card is pretty much min spec from the data I’ve seen, with 20 series being needed for HWRT.
I get your point @Jblackwell, we agree it would be quite expensive, but we don’t even have that opportunity.
Anyway, another additional idea: it should be technically possible, just with a powerful machine, as real-time pathtracer (with some tricks, obviously) it’s being developed by Nvidia and it has been already implemented in some games, like Portal or Cyberpunk, but still not in Unreal… nor a decent (complete, at least) alternative.
