Wanted to thank you @ for the incredible work! We integrated your implementation for our next project and it transformed our test interiors right away! Here are some comparison screenshots of what we’ve got and what we would have to deal with if not for the IBL :
Contribution Factor for IBLs in this level is 0.8 so that we could get some skylight in - this way it helps to see time of day change while inside (there are some other components for that not shown here).
Btw, we run this on 4.23.1 and everything seems fairly stable.
Sure hope you can keep supporting this in the future!
hi all, I’ve started working on the 4.24 port I have yet to compile and test it, but
so far all the code seems to fit into the same places so I’m not expecting any problems at this point
[edit]
everything compiles and works fine
I’ll update my branch shortly but at this point it’s really the same to integrate it from the 4.23 version
Why is there no way for us to vote features like this? Epic’s response makes absolutely zero sense. If they are so worried about newbie engine user, then just put an advanced tab into rendering where we can enable stuff like this and make it hidden on default.
and here’s another sample: the Modular Seaside Town scene, lit with one single Directional Light (outdoors sun), Skylight with DFAO (outdoors sky), one single spotlight, and Localized IBL for the indoors ambient.
btw @Ju2das I also tried adding a secondary reflection for metals but the results were bad.
simply adding the same reflection again but at the highest mip like the IBL lighting does, produced a blurred copy of the reflection - definitely not convincing, just more ‘muddy’
I also tried inverting the reflection vector to simulate some sort of light rebound, but that lead to more undesirably incorrect results - more often than not you’d see an incorrect reflection coming out of nowhere.
bottom line: metals will still only reflect the direct lighting as always. but in scenes with some more geometry and indoor lights it’s enough to produce good results (just look at all the non-simplistic samples in this thread)
Hi @. I am planning to implement this technique to our project but first I wanted to ask if I am planning it correct. Our project is going to be VR project. There will not be full day night cycle but not fully static either. 2 or 3 hour of day (Exmple from dusk to night) in each chapter + togleble lights in each room (Mostly stealth game). Levels will be open but not big. Mostly 1kmx1km. May be max 2kmx2km.
So, how I planned to light scenes. First of all. I cant use DFAO, because UE4 for some reason cant use DFAO in VR. It is known problem and looks like Epic isn’t going to fix this anytime soon. So I want some kind of AO. I tested IBL, it looks amazing but I cant use AO. So what I want to do, use stationar skylight to bake AO (and skylight blocking will be anyway) + use dynamic sun to shift time of day and decrease skylight intensity/indirect light to get rid of baked information for nights. + use IBL for interior lightings ‘GI’ and still be able to switch it on and off.
So is it good idea to use IBL only for GI effect (I know I cant move lights but from what I understad I can toggle light on/off with IBL, I will use 1 light per room and for every room 1 IBL volume) but block skylight with stationary bake?
Is it good Idea to use IBL in VR for performance reason? Can there be big performance difference betwen lets say 4 IBL volume and lets say 200 IBL volume? I can test it myself but I cant reach my PC very often so if you can answer it would be huge help for me ))
So for clarifire.
Moveable directional light (may be + LPV if there will be free space but I dont think so)
Stationar skylight to block skylight leaking + AO since DFAO doesnt work for VR.
Movable local light per room to toggle on and off with IBL per room for fake GI.
hi,
if you read the description in the original thread you’ll realize you need a movable skylight. so no, this local IBL system is not the right thing for your setup.
the entire system relies on the UE4 limitation that the movable skylight works as a general ambient light that acts everywhere in a very homogenous way, and my system uses the reflection probe data to ‘blend out’ the skylight and replace it with the reflection colors acting as IBL.
the system is aimed to improve upon the limitations of fully dynamic (movable) setups.
in your case since you’re already using a static setup for the stationary skylight I suggest you bake everything that you need as static/stationary and put movable lights on top for any dynamic effects.
if the amount of lights in your rooms is small (you mentioned 1) you can use stationary lights so you can get good baked GI and also be able to switch them off at runtime.
a static/stationary skylight coupled with a dynamic directional light can produce visually good results. you get a bit of the worst of both worlds (you need lightmap UVs, wait on light build times, and the performance cost of dynamic shadows on the directional light) but a bit of benefit from both worlds ( since your skylight gets baked you get good baked AO, and you can still rotate/color the directional light, and tint the skylight if it’s stationary)
this is the result of such a setup that I made some time ago. a stationary baked skylight + a movable directional light
https://i.imgur.com/LSTIuBj.gif
Thanks for answer. This is sad, I thought I still can get local lights IBL effect with stationary skylight.
About turning on-off stationary local lights. Am I missing something here? I know that technically I can turn stationary local light off and disable GI effect via post process volume to make it 100% togglable. But isn’t it limited with inside of post process volume and it will affect all the lights+directional light’s GI effect at same time? Almost all of my rooms interior is visible from outside. So is there any other way to turn statinoary lights and their GI effect individually?
And lastly, don’t know how technically possible, but it really would be awesome to have local lights IBL effect with stationary skylights :rolleyes::rolleyes::rolleyes:
I mean just turning off the light itself, but yes that does -not- turn off its GI contribution. you’d need stationary lights with minimal or disabled GI contribution so it doesn’t feel weird when you turn them off. might not be worth it depending on your art style.
like I said the Local IBL blends in into the dynamic skylight pass, blending out the skylight. but stationary sklights go into a different shader path.
it might be technically possible to add the IBL contribution on top of the baked skylight but I estimate it would be a huge effort (basically redoing the whole thing) - a long time of the kind that I can’t afford.
however it miiiiight be possible to have a baked skylight, and then a second skylight set as dynamic, with a black color, and then use the local IBL on top. it would give you what you want - a baked outdoors skylight and IBL wherever you want. you’d get some rendering cost though.
Yeah, You have already done huge step forward for dynamic rendering and huge thank for this. Hope one day Epic will implement something like that for all of the rendering methods.
Yesterday night I checked different methods, and as you mentioned in first page, adding another fill light with ‘0’ specularity somehow looked OKish. And now I will check second dynamic skylight method and will show the result. Thank you.
Now, I tested your suggestion @, but it didn’t work. Looks like dynamic and stationary skylights cant work together. When I put dynamic skylight over baked stationary skylight and activate IBL scene became too bright (This is normal). Then I made movable skylight color black to see only baked stationary skylight and IBL from point light, inside of the room everything worked as intended but when I went outside, where indirect color is only affecting by skylight (directional light is movable), everything gets black because dynamic skylight overwrhite itself over stationary skylight. Then when I changed stationary skylight color, everything gets normal, but the room with IBL effect gets black because stationary skylight overwrites itself over dynamic one and IBL effect turns off automatically Looks like only one of them works and when I adjust one of them it triggers that skylight and other turns off.
So now, I will stick with stationary skylight + local + fill light method. But don’t know how it will work when I fill the whole level with 2x movable local lights (second one shadow cast disabled). I think I will need optimize scene like crazy + I wanted some destruction with IBL contribution for gameplay mechanics. Anyway, thank you very much again for answering.
PS. It is awesome Epic added distance field indirect shadows. Now movable objects shades even more accurate and works like DFAO with stationary skylight too. At least this is good news for me
Probably a silly question… what exactly is the installation process from the zip file if I already have a source build in use?
edit: I see I must rebuild the engine in its own folder.
Dear Epic, this is a feature that really needs some attention… I am not confused by a new feature I desire, I’m confused why it hasn’t already been implemented. Dynamic lighting is ruined by skylight in it’s current state. Please consider taking a few days to iron out this bug.
edit2: got the build running and played around with it a little this morning. Way cool. Definitely needs to be a baked in feature on the UE4 engine.
EDIT3: Is there anyway to cook this into a plugin form? unless there’s been some major updates to DFAO in the last couple months… last time I tried dynamic lighting indoor scenes looked laughably unrealistic due to being lit by the moveable skylight. This feature NEEDS to be implemented in the base engine.
I’m trying to integrate diffuse IBL into my project, but I cannot use the compiled version of UE4 due to limitations. I wonder if I can modify the .usf and .ush to implement the diffuse IBL. For me, keeping the diffuse IBL always on is acceptable.
I just successfully produced a version that does not require .cpp, and can be easily released in the project group through .usf and .ush.
r.LocalIBLFromCaptures and ContributionFactor can be replaced with const in the shader.
it’s still there, it’s the usual with github and ue4. you need to be logged in with github and make sure your github account has access to the ue4 source (link it in the ue4 user settings). then you’ll be able to see it.
ah, interesting. you won’t get the modifiable ContributionFactor and Brightness values but those were added bonus
additionally you don’t get the code that allows capturing non-static things into reflection captures, so you will not be able to capture dynamic lights or dynamic objects into the IBL.
might not seem like much but this makes a more strict separation into IBL being a fully static thing and any dynamic lights/objects existing completely outside of the IBL. something that my implementation makes a bit more flexible.
but sure, I understand the great benefit of not relying on a custom build and at least you still get some proper static ambient lighting for big indoor areas. I might even consider it for an own project
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)
-OR-
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
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…
:
Looks like only one of them works and when I adjust one of them it triggers that skylight and other turns off.
+ I wanted some destruction with IBL contribution for gameplay mechanics. Anyway, thank you very much again for answering.