Moving Least Squares produces NaN outputs

[translunar]

In certain race conditions, MLS with the SAMPLE_LOCAL_PLANE mode is producing output that consists either entirely or partially of NaNs in the xyz coordinates. I don't believe this is supposed to happen. In this case, the input for MLS includes no NaNs.

It's difficult to write a reproducible test case for this bug, but I've committed code which shows that the computeMLSPointNormal function is the culprit here:

translunar@a477b7a

(Note: this does indeed abort for me when the race condition occurs.)

I'm going to attempt to find the problem, but wanted to mention I was working on it first.

[translunar]

Okay, I believe the problem is that the points in question all lie on a line. This happens when the MLS search radius is too small. In the case of the RenderViewsTesselatedSphere app, it can also happen when the near and far plane are too far apart and the z-buffer has insufficient precision. That means that in certain scenes points which recede toward the perspective point are "quantized" by the z-buffer and detail gets lost. The result: some planes get deformed, or plane information gets lost entirely.

I think there should still be some kind of check for NaN points in SAMPLE_LOCAL_PLANE for MLS, but I don't know the best way to implement it.

Instead, I will likely propose a change to the RenderViewsTesselatedSphere app which attempts to address the clipping plane problem — if I can find a solution. Working on that now.

[SergioRAgostinho]

To whoever fixes this, please integrate this test #788 in your fix and make sure it passes.

[stale]

Marking this as stale due to 30 days of inactivity. It will be closed in 7 days if no further activity occurs.

[stale]

Marking this as stale due to 30 days of inactivity. It will be closed in 7 days if no further activity occurs.

[kunaltyagi]

Needs #1407 or similar PR