if texture derivatives are colinear, then orthogonalize them

[cmstein]

If we perform a texture lookup where dsdx,dsdy..dtdy=0, then the options.sblur parameter won't get applied.

This is because adjust_width_blur will produce colinear derivative components (dsdx=dtdx=dsdy=dtdy) which then produces numerical problems with the ellipse axes and effectively results in point-lookups.

This fix just "orthogonalizes" the texture derivatives and the blur seems to get applied correctly.

[jeremyselan]

Is a floating-point compare with 0.0 appropriate here? It's not fragile?

I dont fully understand the context this is executing in, but anytime equality checks in floating point code are a bit scary. Could you clarify why this is preferable to testing with an epsilon? (such as fabsf(...) < std::numeric_limits::min())

[cmstein]

Actually, this is not a very good fix; it really only applies if the incoming derivs are zero. Perhaps I should test for that explicitly?

[lgritz]

Er... concern #1 is what Jeremy said -- what happens when they are nearly colinear, but not completely. Will we still end up with in correct blur? Concern #2 is what else is affected by unilaterally negating dtdy. Concern #3 is I wonder if something is going wrong upstream to give weird derivs in the first place. Do you understand the situation that led to colinear derivatives and think they are sensible (or at least unavoidable) in this situation?

It seems to me that a lot of the code here assumes that the two derivatives will be more or less orthogonal, and that there are probably a number of ways in which we are incorrect when they are significantly non-orthogonal. I suspect there's a more correct transformation of the derivatives when adding blur, that gives us the right new ellipse. Or maybe this is just the wrong place or strategy for accounting for the blur. I'm not sure.

I'm not sure how badly we care about doing it "right" for the usually-improbable non-orthogonal case. I know there's a show that needs the fix. But primarily I want to be sure we aren't breaking anything new in the process. I suppose it can't be too bad -- this only kicks in when the derivs are fairly nonsensical.

Comments, Chris?

[lgritz]

OH. Duh, yes, I see the problem now, which is that if the derivs are exactly zero, blur will be as well.

[fpsunflower]

Agreed, I think the real fix should be in the math below. Scaling blur by the normalized derivs doesn't make sense.