Another update
Cleaned up the shader code a bit and re-added DFAO to the IBL-affected areas 
[ATTACH=JSON]{“data-align”:“none”,“data-size”:“full”,“data-tempid”:“temp_141314_1530394565099_928”,“title”:“IBL13.jpg”}[/ATTACH]
A few more screenshots:
Also updated the main post to reflect the status
Man, this is some super awesome progress! Need to try this out at some point
Regarding the Division stuff…yeah…totally out of scope XD But I just wanted to share it anyways as it has tons of info and we were still talking about local torch bounce light contribution^^
Also, not sure if my eyes are fooling me, but if you watch the proof video again, behind the light is a vertical beam that seems to be getting darker and brighter from the bounce light of the tube light as it moves…so I thought it was kinda working 
Anyways…great updates man!
Daedalus
shouldn’t be long until I make the pull request so you’ll probably be able to try it soon if you integrate the engine changes yourself 
I’m actually looking forward to seeing it in action in a real level!
oh you might be right, didn’t pay attention at the beam
so another small update
no actual changes this time around, just assembled a cave out of cubes and made a proper comparison screenshot
it’s almost literally day and night 
from this comparison now I’ve noticed that SSAO is behaving quite differently, as if the IBL is getting rid of it. I’ll investigate
WOW. :o Maan… I am noob about all those stuff, but maaannnn… What a difference. I always thought, there is something not right with dynamic light interiors of UE4 but couldn’t put the finger on, what exactly is not right. And this comparison explains many things to me now. One thing I didn’t understand. Why, the far wall is more green than the wall near to the emissive lights? Is this how it must work? Or this is because of SSAO?
And about Division video. I think after 0:23 bounce light is visible where the beam connects to ceiling. When light goes far, ceiling became brighter, and when it comes close to beam, ceiling becomes darker. But there is static GI too. For example same guy uploaded this video too.
Takes them very little effort to implement IBL. But the gain is a world of difference, as seen above.
Between that and this, you can hardly tell Epic supports dynamic lighting in UE4.
Instead of Epic adding everything and the kitchen sink to UE4, I think they should make the render and lighting pipeline more extensible so things like this could be easily added as a plugin without requiring a engine fork.
[COLOR=#252C2F][COLOR=#252C2F]
it’s been discussed and requested in quite a few threads in this forum for quite a while now
[COLOR=#252C2F][COLOR=#252C2F][COLOR=#252C2F][COLOR=#252C2F]the reason is the directionality of it. the reflection is captured from the center of the room which captures the strong light to one side, and projects it back onto the other side (because it’s a projected cubemap after all) - as of now I have 2 reflection captures in the fake cave
reflection captures suffer from the same, it’s just much less noticeable. on scenes like this with a strong directionality factor into the expected ambient light it’s best to use multiple reflection captures to make the ambient light even more “local”[/COLOR][/COLOR][/COLOR][/COLOR][/COLOR][/COLOR]
[COLOR=#252C2F][COLOR=#252C2F]
sadly it really seems to be the case
I’ve only added around 200 lines of code across C++ and HLSL to achieve what I have so far, and it’s taken me roughly 2 weeks on 1-2 hr coding sessions, and it’s only because: a) I’m not a graphics programmer and I had no idea how this system works, and b) iteration times are long because shader compilation takes a long time (which only gets worse because of point a))
Honestly I’d expect it would take a graphics expert from Epic less than a week if they’d wanted to do it
I wouldn’t mind the graphics pipeline being more extensible as well
here’s today’s update:
I re-added the SSAO contribution, and also re-added the SkyLight DFAO Occlusion Tint into the mix. so for anyone who for some reason wants a colored AO it’s now also being applied to IBL-affected areas just as it is for the SkyLight-affected areas[/COLOR][/COLOR]
Just wanted to chime in and say that this is fantastic work.
I can’t understand why Epic wouldn’t either do it on their own or take your push request (which I feel will be sadly the case). This technique may have it’s issues, but also can help a lot, even if not in all situations. Until we have some form of at least semi-real time GI, or some other clever fake solution, this would do the trick for many people.
thanks
right, this technique will have its issues (mainly transition softness vs light leaking). it’s not even semi-realtime (it’s basically an extra layer of baked static ambient lighting to help in dynamic lighting scenarios). but I don’t see a reason not to at least provide the option
I’m actually done with it by now. I just have to review all the changes again and make sure I didn’t forget anything and I’ll submit the Pull Request. will probably happen today or in the next few days
best part is that I made it using the UE4 4.20 source, so at least it won’t be rejected right away simply because it not working in the latest engine version
I have a bit of hope on the Pull Request because the changes in code are actually really small and everything ties in nicely with the existing engine functionality and usage… but you never know
it’s done!
Some comparison shots:
I’ll post the code and will make the Pull Request as soon as I figure out how
That’s looking really great. Those comparison shots are awesome.
^^ thanks. I can only hope
and pull request is done!
https://github.com/EpicGames/UnrealEngine/pull/4856
Upvote / like / share / etc!
if anyone integrates it into their engine please share some comparison shots as well. I’d love to see it at work on a real level
also by now it would be awesome to hear the opinion of @DanielW / @RyanB
Awesome !! it would be awesome to see it working on outdoor sceans and maybe an “IBL influence” slider to control the amount of skylight blocking in each probe would be nice for more control in semi occluded areas if feasable !
Anyway nice addition to the engine that a lot of games would use it (even fortnite 
) big up and hope to see more things from you in the futur
I don’t think fortnite would use it since it has a dynamic time of day. Recapturing the scene for an IBL probe is the same process as capturing regular reflection captures, right? It causes a very noticeable hitch in the frame time (I would love to have some sort of async re-capturing).
Nothing prevents it from working on outdoor scenes already. If the sun DirectionalLight doesn’t move it can contribute to IBL, otherwise simply setting its IndirectLightIntensity to 0.0 will stop it from contributing. So it’s simply a matter of placing the ReflectionCaptures in your forest or wherever and you’ll get LocalizedIBL instead of Skylight (it’s actually how it works in Ark)
I actually had the same idea a couple of days ago of an “IBL influence” amount (I called it Alpha) and got it working with very little effort. I should probably update the PullRequest with the change.
Since then I’ve been trying to make this Alpha something dynamic that can change at runtime. This way it would be possible to blend the IBL in and out based on gameplay effects (i.e. for opening/closing a door to a house for a subtle effect, or completely blending it out of it if the house gets destroyed as in Battlefield). So far I’ve had no luck, it’s a bit tricky because all the ReflectionCapture data is static and once again this is something new to me. But I’ll keep trying
Recapturing the scene is out of the equation entirely (it’s disabled on Cooked anyway). Blending the results of the statically-captured IBL probe is what I’m aiming for here
Ok this was much easier in the end, I was just going at it the wrong way
Changing the contribution value and then calling MarkRenderStateDirty() was all I needed to allow altering the IBL contribution at runtime
a simple interpolation between the localized IBL and the skylight can cause quite an impact!
Nice ! that would be awesome to see this get integrated in the engine ! please epic !!!
I’ve updated the code on the pull request to include the above changes
Just to elaborate on this, updating a reflection capture (or IBL probe) is an intensive process because on top of requiring 6 views of the scene to be rendered into a cube target it needs to generate the mipmaps for the resulting cubemap, which is far more CPU intensive than generating the mipmaps for a 2D texture since it needs to blur across the cubemap faces in order to obtain a correct result.
Yeah, I’d still love to have some sort of async capturing that would capture across multiple frames (resulting in a not necessarily consistent cubemap), but that’s a story for another thread.
