btw I’ve update the code to 4.20.3. no changes really, just that slight change in the engine code that shifted a few lines
the 4.20 version of my IBL fork now rests on its own branch, https://github.com//UnrealEngine/tree/4.20
soon I’ll start updating my fork’s main branch to the latest UE4 master branch 
I’m honestly really surprised Epic haven’t approved this PR yet, cause this looks fantastic!.. How long does this sort of thing normally take?
Ah great. That makes things much easier ha.
I made fix for how reflection captures handle specularity. Old model replaced enviroment reflections with non chromatic indirect irradiance when rendering reflection captures. This caused second bounce of specularity to miss color of light. This is very crucial for metals. In general it’s also missed some amount of energy. Change was really simple and this is how many other engines handle reflection captures too. It’s just forces materials to act as fully rough when rendering reflection captures to not have any view dependant light info. This should directly affect localized ibl too.
https://github.com/EpicGames/UnrealEngine/pull/5109
Reflections in scene with strong colors. Notice missing light color.
http://www.framecompare.com/image-co…rison/0BB1NNNU
Reflections in room with lot of metal. Notice missing energy.
http://www.framecompare.com/image-co…rison/WLLGNNNX
interesting. I did notice at the beginning the behavior you describe (I had a full-chrome sphere and it was being captured pitch-black)
my code handles it elsewhere but it’s not so straightforward and doesn’t derive from EnvBDRFApprox as your fix (it just forces it to full-color) which probably means it gains a bit of energy
I’ll review my code to integrate your change. it’ll probably make both our PR’s conflict with eachother but since yours is a bugfix I think it has a higher change of being accepted first - if PRs ever get accepted at all again :rolleyes:
Sorry for that question but I get the 404 error even though I’m sighted in to GitHub. Is there way to search there for this?
as usual, a 404 error in GitHub means you’re not logged in properly. or not allowed to see Unreal’s code - for me the link works
the other way to see the code is to check my fork directly: https://github.com//UnrealEngine/tree/4.20 - but its probably tied to the same restrictions as the UE4 github
I remember I had to unlink my account and relink it again for some reason before it would work. I think it took like a day or so.
I can get to your profile but there is shown “no activity” for each year so I guess I simply do not have access for some reason (I have no idea how this works and only made the account recently). Nevermind, hope Epic will implement this.
Just curious… in semi-closed areas like forest, is the transition anyhow visible?
Is this works with NVIDIA’s GameWorks branch, especially the HBAO feature? Anyone merged the IBL and HBAO together? Thanks.
semi-closed areas are even better when it comes to the transitions since they are already somewhat exposed to the outdoors.
the trickiest part is when there are really closed areas that need to transition to really open areas, and moreso if the transition happens in a very short space. so in a place like a forest I’d say in terms of transition it should work fairly well (as shown in Ark)
I’ve never tried the Gameworks branch but I don’t see why it wouldn’t work with HBAO. IBL happens during lighting and uses the existing reflection capture probes tech - while HBAO is a postprocess that happens later
btw I’ve already started porting this to 4.21. Epic made some changes in the engine as to how shaders are initialized but nothing blocking my IBL
Hi guys
Im absolutely new to github, engine compiling and all that stuff, so my question, probably, would be sounds stupid as hell!..
Does i understand in properly: for making (compiling) UE4 engine 4.20 with what IBL feature, i need to download files from https://github.com//UnrealEngine/tree/4.20
and follow instruction further on that page?
the instructions on that page aren’t relevant to the IBL feature, that’s just the readme from UE4. but yes that should work since the way to get it up and running is the same
note that the repo is based off the master branch. if you’re using 4.20 you’re better off switching to the 4.20 branch of my IBL fork and getting that instead.
however just downloading the files would make you get stuck in that revision and you’d have to repeat the process when moving to 4.21, and then again to 4.21.1 and so on.
another option would be to set up a local repo that you can update from the source (my branch) so you can just pull and recompile to stay up to date whenever I update it. however this isn’t so ideal either because if you base it off the 4.20 fork, updating to the 4.21 fork would require you to rebase your local repo (or set it up all over again from the 4.21 fork). it’s some work and you need some git knowledge for it.
another option would be to set up a local repo directly from the UE4 source (not my fork) and integrate my changes manually. you get more frequent updates directly from Epic without waiting for me to update my fork (but Epic changes might break my IBL code until I fix it)
as you can see there’s no easy way to have a working, always up-to-date source-based UE4 with my changes - it will always require some work from your side 
It’s compiling shaders for the first time, just wait.
First of all: thats a really great feature! ** **thank you for sharing this!
IBL really can bring some “GI-ish” feel to scene and its quite easy.
One problem what im have sometimes with test scene: on editor window everything looks fine. When you play in viewport/window, lighting are changing and some part become more brighthness.
Ofcourse im check eye-adaptation and postprocess stuff and so on. No, its not that cause the problem.
Probably its some restriction to overlapping sphere reflection captures, maybe? I have 4 of them, overlapping each other. When i delete 3 of them, viewport show me the real and actual image where lighting are brighter.
update:
Fun part… situation may changes 180’. Now lighting on viewport are bright, and darker on runtime
glad you like it!
maybe it’s the overlapping indeed. it’s hard to tell from your screenshot but those 2 captures look way too close
I never noticed any editor/PIE/game inconsistencies though. all I can suggest is make sure you save the map :rolleyes:
Probably it was just a bug.
During more test im noticed what it looks like ref.spheres doesnt correctly affect any gloss material. If i starting to decrease roughness of materials and especially if metallic >0 material starts to become too dark. Looks like more darken whan he should.
its absolutely similar to situations with VXGI when you uncheck “specular tracing”.
Maybe im just doing something wrong? 
@ Any ETA for 4.21.0 support? Thanks.
Read this post:
heh, my opinion about engine changes maintainability are not related to the frequency of which I’m supposed to support the feature 
I actually have it working already, I just have to update my local repo to the latest again and make sure everything works and then commit the new thing. the most time consuming part is updating, resolving conflicts, compiling everything again, and rebasing my fork to the latest UE4 version :rolleyes:
I’ll try to get it done sometime this week