Localized-IBL implementation

so I’m wondering: how many people actually use the dynamic properties of this system?

for the 4.25 update I could do it the way @IOchair did it - get rid of all engine code changes and rely purely on shader changes, making everything much easier to integrate (for all of you) and to maintain (for me).
the downsides:

  • it would stop capturing dynamic objects and lights. authoring reflection captures would rely on the purely static scene.

  • it would lose the ability to change things at runtime. that means no more changing the ContributionFactor or the Brightness during game time.

  • it would lose the ContributionFactor so all capture-IBLs would be blended in 100%, unless I use (and lose) some of the other properties that are passed into the shader:

  • I could make it use the Brightness value as ContributionFactor (but then it would lose the Brightness feature entirely)

  • I could make it use the CaptureOffset’s Z value as ContributionFactor (but then it would lose the capture offset Z, limiting it to X and Y offsetting)

personally I can live with the added limitations:
Having ContributionFactor is important to control the looks but I don’t mind sacrificing the offset Z (I never use capture offset at all).
Changing the ContributionFactor at runtime has limited uses like subtly linking it to opening doors/windows or having destructible walls, which I don’t see it being so important/needed.
And changing the Brightness at runtime is a nice bonus if you turn on/off lights during the game, but again it’s a limited use case.
The most important benefit -being able to block the dynamic skylight- would be present.

I myself don’t use the system because I stick to binary UE4 releases for time/maintenance reasons, but I don’t mind making shader changes (I already do for
other things). So for me it would actually mean the difference between starting using IBLs or not at all.

as I can’t make a poll in an existing thread please just reply with your thoughts about this potential change :slight_smile:

I’m following this project for quit a while now, isn’t the dynamic use of Localized IBL the actual most interesting part of this project ? Would be sad lose this ability… Just my opinion on this topic…

Seconding this. That’s the only feature I’m using it for.

Same here for us - i can’t see the point having this without compatibility with dynamic lighting.

Using Z Offset parameter though is completely fine - we have not used it in around 4,5 years across couple projects.

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

@Elocater 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 :slight_smile:

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?

@Chosker Okay i think i misunderstood you. If we are talking about local dynamic lights then yes - usually no-one want’s them to be captured anyways. And we already have a thing in place to convert Directional and Sky lights to Static for baking captures - but i’m not even sure now if we need it as both the default way and ours yield same results currently.

However i found an issue and since we’re here i’ll show it to you)

Here i have an enclosed space where i place a single capure:

The inside is perfectly dark as it should be. Then i add a single static point light with attenuation size 300 and place it closer to one of the corners of the interior:

And then i set it’s Indirect Lighting Intensity to 0 and build it:

My expectation would be to achieve the same result as on previous image. Am i wrong in assuming that indrect intensity set to 0 should nullify light’s contribution to IBL?

yes, we’re talking about local dynamic lights. if no one wants to have them captured into IBL reflections maybe I should stop them from doing so, streamlining the process. thoughts?

wait you’re using localized IBL together with static lighting? and your skylight is dynamic? :eek:
I never really tested IBL with static things aside it. it’s meant to prevent the dynamic skylight to appear as a general ambient light while not just blocking it but reusing the reflection probes, but once you go with static lighting I really don’t see any reason to go with a dynamic skylight (I’d simply go with a Stationary skylight if you need the sky to change color/intensity, and a stationary or dynamic DirectionalLight depending on the needs)

either way the Indirect Lighting Intensity only influences the GI contribution, meaning static GI (and maaaybe LPV contribution and/or SSGI contribution and/or RTX RTGI contribution), but definitely not Local-IBL contribution.
Considering that Local-IBL reuses the reflection captures’ rendering, the way to achieve what you intend is to reduce the light’s Specular Scale - since that’s what controls a light’s contribution to reflections.

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!

@Chosker No-no, we do use Directional and Sky lights as dynamic. And static lighting is disabled for our project. But we have to bake Reflection Captures, right?

What i’m trying to say is we had to convert the Dir and Sky lights to Static before building captures and then set them to be movable after. But it seems that there is no longer any difference in the end and i can’t remember why we did it in the first place.

The issue with a local light’s inderect intensity still stands though.

great, looking forward to see some shots :slight_smile:

right, I misunderstood you because you said you “bake” them (used to calling them “build reflection captures”) and I saw your light set to static
did you try setting Specular Scale to 0.0 ?

after a second thought, yes the Indirect Lighting Intensity having an influence was supposed to be part of my implementation. I’ll have a look at it when 4.25 is out and I do the version for it

render preview problem in 4.24 any idea we check 4.24 and 4.25 but both same problem movie render preview not show video but output video is fine any idea preview window size change???

wrong thread?

Great, thank you!

is this supported in forward renderer? I have a VR project with really weird lighting needs and I think this could be a good solution.

I don’t actively test in Forward so I don’t know at this point but I did try it when I first made the implementation.
everything seemed to work normally with the exception that toggling the feature via cvar would not instantly and would require to recompile all shaders (so setting the cvar in the config file before launching the editor would do it)

All the materials error out for me so I don’t think it works in forward. There are material nodes/functions being used that are not available in forward. I’d really appreciate it if you could look at that and see if you can do anything about this as forward render SORELY needs this project.

I’ll take a look when I do the 4.25 port.
do you have an example of a material that error out (and the error itself), or is it everything?

small update: the 4.25 port went smoothly since no relevant engine code changed (just some code functions that were moved to a different cpp file). it’s easy to integrate if you want to do it yourselves

I’ll start looking at the stuff mentioned in this thread soon, and the updated branch will come afterwards

hey, I gave this a try now that I have the 4.25 port working.

the issue happens only when your light is set to Static (like in your screenshots). if it’s set to Stationary or Movable then the Indirect Lighting Intensity influences the the IBL captures just fine.
working with static lighting gets tricky. if you’re going to build the lighting there’s not much point in using Local IBL anymore (you either go full static or you use Stationaries if you want runtime color/brightness changes)

so in general terms I’d say this is the expected behavior - the IBL is capturing whatever was baked into the static lighting in whichever way it was affected by IndirectStaticLighting when the lighting was baked. but either way this Local IBL is not meant to work alongside static lighting.
the only use case I can think of is if you’re disabling “Use Static Lighting” in your project settings, which means using “static” lights that are actually fully dynamic. in this case the IBL should capture them as if dynamic, and if not then it would indeed be unwanted behavior. is this your case?