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 
@ 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?
@ 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!
@ 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
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?
gave it a try. on basic materials Localized IBL works fine in Forward rendering in 4.25.
since you mention “material nodes/functions being used that are not available in forward” I’m getting suspicious. my IBL engine changes are not using any material nodes/functions -at all-, it’s all engine code and engine shader changes.
it might be your materials not being built for deferred (i.e. it wouldn’t work on a stock precompiled UE4 build either). or maybe somehow my changes are conflicting with some of the more advanced material functions (those that rely on custom HLSL-code nodes).
to be sure I’ll have to test the same material in a precompiled UE4 build.
a couple of screenshots with Localized IBL in Forward renderer.
default map with a half roof and a green floor propagating green IBL:
seaside town from marketplace (which has many materials of its own). this had a compilation error in the Landscape material, which was fixed when I removed the ParallaxOcclusionMapping node
Hey ,
Yup, that is our case. We do have “Use Static Lighting” disabled yet still we had some recommendations to keep any lights that are not supposed to change during runtime as Static. This did seem to matter especially when porting to Nintendo Switch - i’ve noticed a fair bit of a difference between movable and static lights when profiling there.
So yeah, the issue still stands.