Localized-IBL implementation

[A-J-K]

are you guys actually using the system? @youarebritish and @A-J-K are replying here for the first time

@ you mean having the IBL probes capture the dynamic lights into their reflection cubemap right? you’re probably aware that changing a dynamic light’s properties at runtime does not update the cubemaps. any dynamic lights that change drastically during gameplay shouldn’t be part of the IBL captures or it would create inconsistencies (imagine turning a light off but having its IBL contribution still visible. or changing a light’s color but the IBL will keep the original color).
you can still keep the contribution to less-than-100% and change the skylight dynamically as you’re already doing - that would still work.
you’re probably aware of all this, but just making sure

something else that I need to check: if I keep the contribution value (overriding the ZOffset or Brightness) I might be able to make the contribution change at runtime. all my code is doing is setting the render state to dirty in order for it to force a shader update, and I think this might be doable without engine code changes.

if I can get this to work, and if I keep the Contribution at the ZOffset, I’d still have runtime-modifiable Contribution and Brightness.
the only downsides at that point would be the loss of Z Offset, and the inability to capture dynamic lights+objects into the IBL (and even that could be worked around with an editor blueprint script with a button calling a function that would turn all/selected lights+objects to static, then you’d press capture, and then press another button to revert the lights+object to movable). how’d that sound?

I’m working on a site scene using “Localized-IBL implementation” and i really like it! For me it’s mind blowing how EPIC has not agreed to put this in the main branch. Not much to say so far from my site, however once my site scene is finished i will post some screens and comparisations. By the way, i really appreciate your work!