Localized-IBL implementation

[anonymous_user_a201f846]

@anonymous_user_a201f846 I found the issue.
For static lighting the reflection capture renderer draws each light as a bright-colored shape into the reflection cubemaps to actually have the light visible as a bright spot in the reflection. for non-static lights this isn’t needed because the shader fakes the light shape in the BRDF.
The bright shapes were making the reflection captures that much brighter, making the localized IBL unexpectedly bright.
As a fix I’m preventing the drawing of these shapes is the Localized IBL CVar is used. It’s already pushed into the 4.25 branch of my Localized IBL fork at github

but now this has made me further realize it’s pointless to maintain a “somewhat working” version of Localized IBL to work alongside static lighting, while at the same time it isn’t meant to work alongside static lighting.
I’m thinking now that I should only allow the usage of Localized IBL if the project has Static Lighting disabled entirely. it makes sense in terms of editor UX and perhaps it might make things clearer in a step towards Epic accepting the PR.
thoughts?

That’s great you’ve found it so quickly, well done!

About the static lighting thing i think i am fairly biased here as we don’t use static lighting at all so i don’t care if that is supported by your implementation. However, your point does seem fair as the way i think about IBL in dynamic lighting scenario is emulating a proper GI you get from Lightmass. So one has a better way of achieving what IBL provides if they bake their lighting.

Maybe someone else who uses both static lighting and your IBL implementation can provide a different point of view here.