MegaLights feedback thread

@Krzysztof.N & @TiagoCostaUE

Feedback regarding MegaLights that relates to the 1# most voted feedback on the forums here. (Anti frame smearing dependency(TAA, DLSS, etc) seen in various UE5 effects like SS shadows,VSMs, AO, GI, Virtual Textures, and more)


I’m very much a fan of the independent temporal commands for Megalights. It’s a good step away from the usual AA/Upscaling smear abuse in the engine. But if it’s going to be temporal, shadow lines need to be less noisy without AA.

Krzysztof.N
Still it feels like a necessary step in order to be able to remove RT shadows

That’s a painful sentence to read. RT shadows are plenty viable for productions that optimize geometry and provide high quality, noise free(cheaper too with no denoiser) hard shadowing.

One thing that’s bothering a lot of people and myself is the noisy shadow edges with mega lights. Raytraced shadows and other shadow techniques allow users to stick to sharp shadows exclusively to rule out the need for denoising cost/TAA abuse/ visual noise. It’s a trade off a lot of devs would take. So we are asking to prioritize this issue.

Right now, cascaded shadow maps are not supported as a fallback for the directional light. That’s a major issue because that leaves users who do not want the performance impact of RT shadows, the visual issues with VSMs, and want some sort of non-noisy soft directional shadowing via CSM. There are two logical options that accommodate for the growing goals from developers and consumers who fund this engine. This would also help cut the cost of the neighborhood clamping.

  1. Add support for CSM directional lights

or

  1. Focus on mega light support for the directional light as long as noise from mega light shadows can be removed by(at least for the cost of soft shadows).

Seeing masked objects as unsupported is quite sad. This would be a major improvement for many game scenarios, if not the second best improvement with the first being the accommodation above. Hope to see it soon.


As seen with Lumen, your team doesn’t work on support for non-nanite meshes because of the “nanite is priority” agenda. People rather budget their scenarios for megalights by saving performance using LODs want the poly count tied to geometric aliasing. Do not tie Megalights to a poor rendering system like Nanite.


Do not develop megalights with temporal AA or super resolution on. If Brian Karis had done this with Nanite’s development, maybe he would have seen Nanite has plenty of popping and geo aliasing. If you develop something to appear clean without AA, people can use TAA if they want and nothing horrible happens if TAA is turned off or configured to be more clear. If you develop megalights with a TAA/Upscaling abuse, you’ll be punishing those who do not want the TAA smear with noise.