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 Chosker,
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.
okay that makes sense. Despite being dynamic I suppose static lights have a few optimizations (caching or otherwise) compared to movables.
I’ll have a look at fixing this use case - it makes perfect sense in the context usage of Localized IBL
@Elocater 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?
had a second look. from the samples I had only Parallax Occlusion Mapping on a Landscape material ever failed to compile. I fixed it by disabling “Use Static Lighting” in the project which as I mentioned above it’s the intended usage
please give me some more examples of where it fails
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.
@Chosker Hope you and your family are well and healthy!
Thanks a lot for continuing to update your fork! 4.25 was the hardest yet for me. Had to get help from a few people to solve some probs.
I read over everyone’s most recent posts regarding how it works in 4.25, and it appears to me everything is working as planned, so…
I’mma go ahead and merge it into my fork of doomfest’s toon shaders. Don’t hesitate to let me know if I should stop, or need to give proper credit - or if it’s still incomplete.
jsyk, it is not, and never will be, my aim to profit off of someone else’s brilliant/hard work.
Best! Keep safe, and thank you for being so helpful!
thanks, I hope you’re all well too!
yes the Localized IBL is working on 4.25. everything works as planned AFAIK, and I don’t spend time improving it because the few things I tried didn’t really improve it, and I’m also focused on other projects. Epic’s negative isn’t exactly motivating either.
feel free to merge it in your fork, no need to stop. proper credit would be good though!
Hi Chosker, great work I was hoping to use your 4.25 Localized IBL solution but unable to locate a working URL for your fork on GitHub as mentioned in setup. Would it be possible to provide a new URL for 4.25 please? I am using a dynamic day and night but want a subway and it must be dark, you solution seems the best working option to achieve this. Thank you in advance.
you need to be signed in to GitHub and with a linked UE4 account for it to work, it’s the usual thing with GitHub UE4 repos because of UE4’s license.
the 4.25 branch is right there, you just need to switch branches. here’s the link: https://github.com/Chosker/UnrealEngine/tree/4.25 - if this doesn’t work, once again make sure you’ve logged in to GitHub with an account linked to UE4
this solution is just one of many (as I outline in this post: https://forums.unrealengine.com/development-discussion/rendering/1806217-struggling-with-outside-inside-lighting?p=1806239#post1806239), all of which depend on your specific needs.
At this point I would not recommend using this Localized IBL branch. 4.26 will be the last engine version before UE5 and with Lumen coming to UE5 and the many expected engine changes that will come with it, I will stop maintaining this code (4.26 will be the last update I will do for this Localized IBL branch)
I asked on the UE live stream today for 4.26 if this issue was going to be addressed in 4.26 or UE5 with Lumen and I am not sure I want to accept the answer but they said it would not which if true is really unfortunate news. I managed to download your work on this, thanks for sharing, it really does help to solve the issue.
I’m revisiting the sky occlusion problem we have since the size of our maps forbid static lightning baking. Some parts with tunnels are completely lit which is terrible from a gameplay perspective. Among my options is to get your system, distribute probes uniformingly in a volume and store visibility in the probes to avoid leaks and eliminate artist placement time. I hope it is not out of my league.
FYI I ported it to 4.26. it was pretty straightforward, just a few line numbers shifted.
you can find the 4.26 branch on my repo
cheers
Hi, is your code still available somewhere?
Cheers.
yes my github fork still works. make sure you’re logged in to github and have your account linked to ue4, or you’ll get a 404 error