Bug Refraction weirdness

Thanks for the detailled videos regarding the issues .

Can you provide a simple repro for this one? I'm not entirely sure what I'm looking at.

For the second part, HDRP has no idea of the geometry depth (thus why you have to provide a thickness map or a fixed thickness), so it makes sense that the blur strength doesn't change depending on depth.
For that you would have to make custom refraction using shader graph or custom passes.

Finally, the lower the smoothness, the higher the mip of the color pyramid is used (to fake that blur). So the further you are from the transparent, the less pixels you have defining your transparents, making it a bit blurrier the further away you are from the transparent object.

This one is known and tracked on our side, here's a tracker link if you want to follow the process.

 

Bug report is fine, as long as you send me the case number here when you do it ! Thanks

I see what you mean, if it's really important to you, you can implement it in shader graph. Basically, lowering the mip the further you go from the object to not make it blurrier the further you go.

 

I've had a look and indeed there's no obvious reason why the refraction doesn't fallback to the probe cubemap where the screen space refraction fails.. :|
your report has been converted into a bug and we'll look into it.

Thanks for reporting
Cheers.

 

So, technically, the issue arise when the result of the refracted ray end up behind the occluder (in your case, the big cube).
In those cases, there's two solutions:

1. We fallback on something else (we can't use the information from the color buffer because something is blocking the view) like reflection probe or sky.
2. We don't refract and use the pixel from the color buffer as is.

So, as you might have guessed, this is the solution #2 that has been preferred and this is what's happening.
We could technically use reflection probe data, but there is a good chance that this information will be as bad as the solution #2 so a choice had to be made.
Also, the main issue (having the border between the refracted ray and the fallback) will still remain in either solutions.

 

Yes, exactly, both solutions have pros and cons, we just picked the one that made the most sense to us.

For now, the fallbacks are indeed hardcoded (Screen space information, Reflection probe.. etc)
While it could be possible in the future to let users chose the fallbacks they want, it can also introduce some other issues so it's not a priority for now :|