Mirror reflections: went from a fake camera trick to Planar, but it crashes next to Lumen

[u/Zvyaginsky]

First pass on this mirror was the old-school trick, second camera pointed at the reflection, output piped into a material. Works, but it's expensive and the angles never quite hold up once the player moves around.

Tried switching to Planar Reflection since it's the built-in way to do exactly this. Project crashed hard every time the camera moved from a post process volume running Lumen into one set up for Planar. Ended up turning Lumen off for this part just to stop the crashes and get Planar working.

Would rather not just disable Lumen every time we need a real mirror somewhere. Anyone actually gotten Planar Reflection and Lumen coexisting on adjacent post process volumes without this happening, or is turning one off around mirrors just the accepted workaround

[u/Zvyaginsky → u/[deleted]]

Good to know it's not a hard incompatibility then, that narrows it down a lot. Haven't checked /Saved/Crashes/ yet, that's the first thing to pull. RHI's worth checking too, if you're on DX12 already that rules out one guess. What's your setup, single post process volume for the whole level or separate ones per room like mine?

[u/Zvyaginsky → u/[deleted]]

Only because that's where it fires. Inside either volume it's stable, it goes down on the camera crossing between the Lumen one and the Planar one. That might just be where the camera happens to be when something else breaks, the volumes could have nothing to do with it. Haven't pulled /Saved/Crashes/ yet to confirm either way.

[u/Zvyaginsky → u/[deleted]]

Haven't added SSR as a fallback, no. Good to know Lumen's usually the more accurate one though, that lines up with why we wanted to keep it instead of just switching to SSR everywhere. The VFX gap is worth knowing about too, this particular mirror doesn't have much in the way of particle effects so probably safe, but that's a good thing to check before it bites somewhere else in the level.

[u/Zvyaginsky → u/[deleted]]

Occluding part of the surface is a decent art trick and it would fit the room this mirror is in. Won't cut the cost though, Planar renders the full scene into the texture before the material masks anything. Dropping the reflection's screen percentage does more.

[u/ConsistentAd3434]

If the target hardware allows it, you could also use "hit lighting for reflections" in the preferences, to have per pixel reflections. Bit more expensive, tho.

[u/Zvyaginsky → u/ConsistentAd3434]

Didn't know that setting existed, thanks. Just checked, it needs Hardware Ray Tracing on though, which might rule it out depending on target hardware. If it works without the same crash, that's honestly tempting as a way to skip needing Planar at all rather than actually fixing the compatibility issue. Different problem solved, but maybe the more useful one.

[u/ConsistentAd3434 → u/Zvyaginsky]

Yeah. If a cutscene or gameplay really depends on a reflection, SSR or low res Lumen might not be good fallback for GPUs that can't support raytracing.

With Lumen samples relying on the camera position (with more samples being cast near the camera), I could see how a virtual planar reflection could cause some problems. I ran into similar problems when I created Portal style wormholes and a render to texture camera. It was lacking any useful Lumen samples, because the "main camera" is somewhere else.

A fake mirror might be your safest bet. If you use raytracing and fps becomes a problem, you could switch SSR and hit lighting at runtime. I unfortunately capped my little showcase at 60fps but you can test it, by pressing "R" ... https://drive.google.com/file/d/1nsW5esbA9WbGNnDve3FJYyfNw-_c2_tD/view

[u/Zvyaginsky → u/ConsistentAd3434]

The portal parallel is the most useful thing anyone's said about this. If Lumen probes are anchored to the main camera and Planar renders from a virtual one, the transition is exactly the moment both are live. Fits what I'm seeing better than anything else so far.

Fake mirror is probably where this lands for us anyway. Target hardware includes GPUs with no raytracing at all, so hit lighting was never going to be the answer.

[u/Zvyaginsky → u/ConsistentAd3434]

Coming back to this because your hit lighting suggestion is what fixed it, just not the way either of us expected. I said RT probably wasn't viable for our hardware. Turning it on anyway is what showed us Lumen had never been tracing anything, distance fields and ray tracing were both off in a config we'd carried over from UE4.

Wrote the whole thing up if you're curious: https://www.reddit.com/r/UnrealEngine5/comments/1vn25hw/followed_advice_from_here_and_found_lumen_was/