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
@ 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.
@ 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 , 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//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
2 Likes
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
4 Likes
Since the github links apparently didn’t survive the forum migration, for anyone looking for this:
https://github.com/Chosker/UnrealEngine/tree/4.26
1 Like