Bug Refraction Box Model doesn't work

Hey, we are actually working towards improving that and your feedback actually confirms that the workflow is far from great.
In the meantime, here's what's I think is happening with box model in your scene.

By default, when there's no reflection probe, the refraction fallbacks to Sky with an infinite projection and that's what actually causing the box model to not be so shiny by default.
What you need to do in order to make the box refraction works as you expect to:

• Create a reflection probe in your hierarchy
• Create a proxy volume in your hierarchy with a shape different than infinite
• Feed the proxy to the proxy volume variable in your reflection probe.
• Bake your reflection probe.

Now the refraction is working properly and the thickness has actually an influence in the refraction.

You can also do without the proxy volume and tick the box called "Use influence volume as Proxy volume" on your reflection probe settings to simulate a proxy volume from the reflection probe shape.

Hope this helps.

 

Let me expand a little about refraction because It's a bit more complicated than "box model is broken".

Basically, our refraction models, for the most parts, technically works but how they work is not explained very well. This creates misunderstanding about what to expect when using those different models.
We are currently actively auditing what can be done to explain it better to be able to improve that transparent experience overall.

That being said, here's a quick recap on what to expect with Box refraction model:

By default, box refraction will modify the view vector to sample the color pyramid to create screen space refraction.
The refracted vector is paralel to the input view vector because box refraction model assumes that the output normal is basically -"input normal" (i.e both sides of the glass are also paralel).

HDRP will cast this refracted ray to a proxy volume to be able to find the hit point (basically where the refracted light will hit) in the environement.
Finally, if this "hit" is outside screen-space information, it will use the regular sample hierarchy (Reflection probe then sky) the fetch the color of the pixels.



Now how and where this proxy volume is defined is the tricky bit.
By default, if your object is not within the bounds of a reflection probe, the default proxy volume is "infinite" meaning you will get very little refraction. (i.e you will think the refraction isn't working).
Otherwise it will take the shape of influence volume setup in your reflection probe:

• Either infinite (default)
• Use influence volume as proxy volume (so box or sphere depending on what you have setup)
• Or use any proxy volume already defined (which is box / sphere or infinite anyway)

This proxy volume is almost always an approximation since it's very simple primitives.

Now, after this recent "fix", the new default for box refraction is not infinite anymore. The shape used for the default proxy volume is the bounding box of the object itself which is still not perfect but gives a result that is more expected by users out of the box.

Also, for what it's worth, thin refraction model, is just box model with fixed thickness of 0.005m (5mm)

So to answer the questions, This fix (about refraction) has not been backported because it relies on being able to retrieve the bounding box of an object which is only available on recent engine versions.

However, this fix (about your XR issue) has indeed been backported up to 10.x.x (and 12.x.x) and will be available when thoses packages are updated.

Hope this helps clears some of the confusions.

 

Yep, this is why we are trying to improve here.

Technically, the reflection probe is just here to provide a "shape". If your refracted ray still falls within the bounds of screen space refraction (the pixel that we need to fetch is not outside the screen), only the color pyramid will be sampled (i.e the background of the scene containing opaque objects).

The actual data of the reflection probe is used ONLY when the refraction is so high that the refracted view vector hit outside the screen (happens more with sphere refraction models because of its implementation).

 

Technically yes, it would be interesting, and it can make sense in some scenario, but in a common correct lighting scenario, you technically already have reflection probes setup so in a way, it's kind of an optimisation to use them not only for reflection but for refraction as well.
It's already painful to setup many reflection probes in larges scenes, imagine having to do twice the work..

By putting the the weight of the probe to 0.001, you are essentially still fully using the shape without using its data. So yeah it works and it's the downside of using the same object for reflection and refraction.

Also, keep in mind that eventhough for refraction the data of the reflection probe (wether it's baked, custom or realtime) won't necessarly be used, it needs to have some data, (even a black 1x1 texture in a custom imported as cube), otherwise HDRP will discard it, same if weight equals zero.