Avoid singularity during sky filtering#114279
Conversation
|
Tested locally, it fixes the singularity but also introduces seams on the higher roughness levels: There are also some very slight 'splotchy' artifacts on the rough levels, though that could be a different issue. When viewed in Renderdoc, the seam is X-shaped: |
|
Very interesting, I'm not seeing those artifacts locally. I will have to test on a different device. That "X" artifact is right along certain fold lines in the octahedral map. So it looks like there is an edge case that isn't being handled properly |
|
The algorithm tends to 'snap' the tangent/bitangent at certain normals: |
|
That's right. The algorithm follows a different codepath for the +Z/-Z hemispheres. However, the paper claims that the result should be continuous. So I need to figure out why it isn't |
|
@BlueCube3310 I'll push a fix momentarily that gets rid of the discontinuity and removes the stretching at the poles. The correct solution turned out to be very simple. But this won't be enough to close #113676 since the appearance is still different |
… calculating the orthonormal basis
clayjohn
force-pushed
the
sky-singularity
branch
from
7e7a1e4 to
6e6d59b
Compare
BlueCube3310
left a comment
BlueCube3310
left a comment
There was a problem hiding this comment.
LGTM, while some distortion is visible on the lower hemisphere, it's nowhere near as obvious as it used to be.
Some 'splotching' is still visible on the rough materials, though it can be improved later on as it's not really noticeable.
|
Thanks! |
|
@BlueCube3310 Thank you for checking!
I think the way to fix this is to use an approach more similar to what we do in the compatibility renderer which is to precompute samples ahead of time and vary the sample count based on roughness level (as described here: https://placeholderart.wordpress.com/2015/07/28/implementation-notes-runtime-environment-map-filtering-for-image-based-lighting/). The trick is that the first few levels only need a few samples while the rough levels need a lot more. Right now we use a fixed amount that is overkill for the first couple of levels and not enough for the last couple. If we distribute the samples more towards the rougher levels, we will get improved quality at basically no cost. In the compatibility renderer, we do that on the CPU and pass in the samples through a uniform. But Seb Lagarde (from Frostbite) left an interesting comment on the post I linked above saying that they precompute the samples in the compute shader using group shared memory. Which is probably what we would want to do too. Is this something you would like to experiment with yourself? |
I would like to, but I will most likely not have the time for it during the next month or so. |
Fair enough! |
Avoid singularity during sky filtering
3 participants
Fixes part of: #113676
This switches the singularity to be on the y axis instead of the z.
Previously the singularity wasn't a big deal since only one or fewer pixels would have a z value of exactly 0 since the poles were in the center of the cubemap faces where there is the least distortion. But since octahedral mapping warps space different the z-axis poles are directly on seams, which lead to a huge increase in the amount of distortion
This PR switches to using the y-axis because it isn't on a seam and has a low amount of distortion. This removes the obvious stretching artifacts as well as the little circle.
However, it does not fully close the PR since there are other quality differences resulting from using octahedral coordinates. Importantly, I notice a difference in the contrast for fully rough materials. (Actually, that may not be a regression. The difference may actually be more correct see #108273)