Announcement

Collapse
No announcement yet.

Localized-IBL implementation

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • replied
    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

    Leave a comment:


  • replied
    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.

    Leave a comment:


  • replied
    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.
    Last edited by odzta; 10-22-2020, 05:29 PM.

    Leave a comment:


  • replied
    Originally posted by odzta View Post
    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/deve...39#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)

    Leave a comment:


  • replied
    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.

    Leave a comment:


  • replied
    Originally posted by kusogaki77 View Post
    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!

    Leave a comment:


  • replied
    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!
    Last edited by kusogaki77; 05-23-2020, 06:22 AM.

    Leave a comment:


  • replied
    Originally posted by Chosker View Post
    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?
    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.

    Leave a comment:


  • replied
    Originally posted by Starkium View Post

    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.
    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

    Leave a comment:


  • replied
    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?

    Leave a comment:


  • replied
    Originally posted by Elocater View Post
    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

    Leave a comment:


  • replied
    Originally posted by Chosker View Post
    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?
    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.

    Leave a comment:


  • replied
    Originally posted by Starkium View Post
    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.
    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:
    Click image for larger version  Name:	IBLindoor.png Views:	0 Size:	464.5 KB ID:	1757506

    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

    Click image for larger version  Name:	IBLseaside.png Views:	0 Size:	474.0 KB ID:	1757507
    Last edited by Chosker; 05-08-2020, 01:21 PM.

    Leave a comment:


  • replied
    Originally posted by Elocater View Post
    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:

    Click image for larger version

Name:	Issue_1.jpg
Views:	882
Size:	269.3 KB
ID:	1748292
    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:

    Click image for larger version

Name:	Issue_2.jpg
Views:	886
Size:	200.8 KB
ID:	1748293
    And then i set it's Indirect Lighting Intensity to 0 and build it:

    Click image for larger version

Name:	Issue_3.jpg
Views:	884
Size:	270.2 KB
ID:	1748294
    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?
    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?

    Leave a comment:


  • replied
    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

    Leave a comment:

Working...
X