SRP Flares do not work with Overlay Cams in Unity 2022.2

Whenever I have a camera stack, and I have an SRP lens flare, any but the base camera stop rendering immediately. (however, UI, on a different camera, screenspace or overlay, works)

Flare off:

With Flare on (the flare is also rendered repeatedly, this isn’t obvious from the screenshots)

Setting the overlay camera to “Base” makes the flare show up (and its render contents), however, that light source / game object that the flare is on isn’t even in the (former) Overlay Camera’s culling mask, nor is the camera in the light source’s culling mask. :frowning:

If I turn the foreground camera back to Overlay and turn its Post Processing off, the whole output becomes this (the base camera’s content appears to be fully overwritten or discarded)

If instead I turn on “Stop NaNs”, “SMAA” (but not “FXAA” or “TAA”) on the base camera, the Flare disappears (interesting!):

Some progress: Turning off MSAA (the only good form of AA! and I thought it’s the only one really in hardware, with proper subdivided depth and stencil, etc?) will make the image and the flare show up on both cameras, but it gets rendered multiple times; even if this could be worked around by reducing the flare intensity, this doesn’t work for a camera stack where the world position is not identical for the cameras, e.g. in a floating origin system.

This also conflicts with the documentation, which claims MSAA is the most compatible, and will work with PP effects.

(I can do without MSAA and use Render Scale during preproduction, but a fix for the duplicate flares / proper culling of flares by layers and cameras would be much appreciated - I can’t even render the flare into a render target and blend that, because all the cameras are equally affected. … well I guess I could rotate it all 180° before rendering the render target, but this is getting silly)

I found a WEIRD workaround:
I can add the flare to the light that the Overlay camera uses (it will still hand it down all the way, so the camera next in the stack will also render flares), but even occlusion works (I have no idea why, depth is cleared but I guess it check against Skybox fragments).

This means an additional overlay camera can render the flares.
This only works until I need to rotate the cameras independently, and it doesn’t play nicely with the UI camera, which gets a misplaced flare itself (proably because of field of view)

Edit: Sadly, it’s not that easy, I just still get way too many flares, and the SRP Flare component also doesn’t seem to play well on gameobjects without a Light component. It doesn’t care whether that light component actually has a non-zero culling mask.

I can selectively turn off post processing, but the base camera will always render an excess flare because that cam cannot have no post processing.

I will try to move back to my suuuper old approach of having the base camera only for the Skybox… that’s pretty rough.

Nope, not a chance, the SRP Lens Flare feature is sadly quite borked. :frowning:

I have a similar issue in Unity 2021.3.19f1

As soon as a lens flare is enabled when MSAA is on, the overlay camera stops rendering entirely. If either the lens flare or MSAA is turned off, the overlay camera renders again.

Anyone found a workaround?

I just slapped in a simple placeholder flare for now, based on this: GitHub - ColinLeung-NiloCat/UnityURP-BillboardLensFlareShader: (1)Add a new Quad GameObject (2)Use this shader (3)Done! Now you have billboard lens flare shader for URP!
(doesn’t work with cameras that clear depth, but I can live with it)

Ain’t nobody got time for this. :smile:

Still broken in 2022.3.5f1 LTS with URP 14! The flares render for each camera, regardless of culling masks; meaning you get multiple flares if you have multiple overlay cameras.

But fret not! As an added bonus, Flare Assets can now no longer be edited.

This is very depressing. I really wanted to like the new lens flares, but it requires too narrow a setup to work correctly. I’ve encountered basically every problem in this thread, with the final straw being incompatible with MSAA.