@ :
Do Scenes with static Skylight and Stationary Directional Light benefit from this?
it replaces / blends out the dynamic skylight, so no, a static skylight would not get any benefit
At the moment I’m looking at using depth for improved parallax correction and more intelligent blending between captures.
I tried the mod, it seems reflection captures are not working, ibl or not ibl.
seems interesting indeed. is this something you want to try yourself? I can point you to the right place to get the depth as alpha on the captures. I’m just not sure I want to invest much more time on this anymore, since Epic rejected the PR and I’m not even using the system in an own project (as a hobbyist I want to make research/games, not maintain engine code)
strange, it works for me.
can you share more of your setup just in case? (what kind of lights, if movable/static/etc) I can give it a try later
It’s the default new level, I duplicated the platform, both lights set to movable, nothing else changed. SSR is working. I tried in 2 projects.
edit: btw, I noticed engine ini files have unix line endings, so in notepad they appear without line breaks, maybe that’s related?
Yeah, I’ve actually made a very incomplete mock-up of what I’m trying to do, but it’s just using a single cube map texture asset since I haven’t completely worked out how to manage this with actual reflection captures. Some tips regarding passing depth through the alpha channel would probably save me a lot of time. Replacing the existing parallax correction turned out to be pretty easy, so I think depth is the only missing piece.
I’m hoping that this approach will be equally applicable to both reflections and diffuse, assuming it actually works at all and with acceptable quality.
it works but the ContributionFactor needs to be set to 1.0.
apparently it’s set to 0.0 by default which is wrong. I’ll fix it at some point
interesting. what’s the effect on the parallax correction so far?
anyway to capture depth into alpha go to ReflectionEnvironmentShaders.usf and replace line74 which looks like:
Alpha = 1 - smoothstep(.8f * MaxDistance, MaxDistance, RadialDistance);
for something like
Alpha = RadialDistance / 65536.0f;
and then you need to change the way the blending works in the composite function, since the MaxDistance of the probe isn’t accounted for anymore. so far I was factoring CapturePositionAndRadius.w in the blending to compensate, but haven’t done it properly yet (the process is long and tedious because the smallest change causes all shaders to be recompiled)
Perfect, thanks. That’s exactly what I was looking for. I’ll try to share some results as soon as I can,
Yeah, so this is definitely a bit slow.
That said, I’ve made what I consider some modest progress. Right now, all I’m doing is attempting to replace the existing simple alpha underlay compositing with something that sorts by “accuracy” (i.e. how closely does the sphere projected capture ray agree with the sampled pixel’s depth)
The results look a bit like a garbled mess since there’s no fading between between captures, but it does reflect the actual scene geometry more accurately than the existing blending. I also need to find a way to ignore self-hits, since they cause quite a bit of unfortunate contamination.
The next step is the actual parallax *correction *aspect. I think adding ray marching for this purpose will be pretty trivial to implement, since I really only need to generate multiple “virtual” captures with different radii (but the same center point and IBL data), and let the depth sorting figure out which one to use on a per-pixel basis. I’ll probably try to refine the result a bit further with the classic parallax mapping technique.
After all that is done, I should then be able to feed the result into the final accuracy sorting, which will choose from among a bunch of hopefully-now-much-more-similar options.
I’ll start a new thread and stop derailing this one.
amazing tech. hope that this will be implemented in the engine!
Latest dev-rendering merge in master branch created serious conflicts with the implementation, we were using this actively in our development. Is there any chance to get any early implementation for 4.23?
I want to know this also 
hi all, since Epic declined the PR I’ve been focusing on other projects. As the entire custom engine fork maintaining is a big time sink I usually just stick to ‘final’ UE4 releases
I can’t promise an early implementation but I’ll see what I can do about 4.23
https://github.com/ProjectBorealisAd…264a27bd0ccf46
I did a quick merge for latest 4.23 branch, I will let you know when I confirm it’s working without any problem.
Edit: Unfortunately, after few attemps, I couldn’t make it work:
https://github.com/ProjectBorealisAd…6c9e142096e89b
https://github.com/ProjectBorealisAd…5d22483ad30c90
It would be awesome if I can get some feedback on this
Edit: Looks like it’s abandoned, I’m not suprised with that… I don’t recommend making your project’s lighting deeply bounded to this implementation. Possible replacements:
- Enlighten
- Nvidia VXGI2
- Nvidia RTGI (If you have RTX card)
- LPV
- Static Lighting
sorry I missed your reply
It’s not abandoned. I have many things to do so I can’t actively work on maintaining this on partial UE4 releases.
the latest UE4 release is 4.22 and this works on 4.22 - can’t really call it abandoned
once the ‘final’ 4.23 comes I’ll port it over
quick update: I got this implemented on 4.23.
I have to double-check but I think I have some issue on translucent objects, but shouldn’t take much longer.
unfortunately I’ll be out until early next week so at minimum next week there will be no working release from me
cheers
Localized IBL for UE4 4.23 is now updated
grab it on my github: https://github.com//UnrealEngine/tree/4.23
I’ll update the original post in the following days but there’s one big thing to consider:
Translucency with Local IBL only works using the 2 Surface lighting modes - the other 4 modes (the volumetric ones) had some big issues that I could not fix. I suspect they were always there before but I never noticed them.
As a result I’ve disabled skylight on volumetric-lighting-models translucency entirely - otherwise the translucent objects without local IBL would display the skylight which is exactly what this system attempts to avoid. This results in translucent objects being pitch-black on non-lit interiors with local IBL - so you might want to add some subtle ambient light in your translucent materials. If you still want the old behavior and have the skylight to show on them just comment out lines 562 and 567 on BasePassPixelShader.usf
also I tested it on Forward Rendering and it works well
alright I’ve updated the original post with more details of the current state of things.
btw if anyone is using this system please post here (bonus cookies if showing screenshots) - in general it would be nice to gauge the benefit this is providing. in short, if I understand that no one is using this system I will stop maintaining it.