I think your code is readable, I don't think it needs to be refactored more. Having to do so much more work, for something that is probably only an edge case that is unlikely to be hit on…
The original file works for me in 4.2 and I believe a reason for that might be that this was fixed: #122739
@Zeastin You can try using booleans and integers again, those should be more usable…
This fixes the second problem reported in #123634 (not the original issue). I am not sure whether this is the correct fix, it might be a performance regression, but I don't have good test scenes…
I am pretty sure that the curved variant is a different issue, and I have a proposed fix for it in #126157. I cannot reproduce the original problem, maybe something changed, fixing it by accident?
I updated the patch with the replacement. I also removed the clamping, but I am unsure whether we want to keep that anyways? I am leaning towards not having it if it is unnecessary, but should…
I had another look at the point where bsdf_D
is called in bsdf_microfacet_sample
: The cos_NH
argument is calculated as dot(N, H)
which I think should just be the same as local_H.z
with…
Even with the improved precision of D_beckmann the errors did not disappear completely. Adding the proposed clamping does indeed help, I updated the patch to add that with a comment.
Just did another quick test to confirm this actually helps: Setting BSDF_ROUGHNESS_SQ_THRESH to 1.1e-19 still produces good images, anything lower introduces artifacts. This makes sense, as we use…
As suggested by @weizhen in #125750.
I tested this on apple arm cpu+gpu with a couple of random scenes, playing with the roughness and ran the test suite, no obvious issues.