Triangle: Return null in getBarycoord() if the triangle is degenerated.

[gkjohnson]

Related issue: gkjohnson/three-bvh-csg#183

Description

Previously the getBarycoord function was providing a reasonable looking result where no reasonable value could be provided when a degenerate triangle was used. This makes tracking errors down extremely difficult. Now an error will be thrown if a degenerate triangle is used.

[github-actions]

📦 Bundle size

Full ESM build, minified and gzipped.

Filesize dev	Filesize PR	Diff
669.1 kB (166.1 kB)	669.1 kB (166.1 kB)	+12 B

🌳 Bundle size after tree-shaking

Minimal build including a renderer, camera, empty scene, and dependencies.

Filesize dev	Filesize PR	Diff
450.1 kB (109 kB)	450.1 kB (109 kB)	+12 B

[Mugen87]

It seems the unit tests require an update now.

Triangle.getBarycoord() is also used in context of ray casting and I fear a less graceful approach could produce issues. If you think throwing an error is better to return and undefined result, callers of Triangle.getBarycoord() in the repository should implement an error handler. That is Triangle.getInterpolation() and Triangle.containsPoint(). I think it would be not good to see unhandled exceptions when user perform ray casting. Even if triangles are degenerated.

[gkjohnson]

If you think throwing an error is better to return and undefined result, callers of Triangle.getBarycoord() in the repository should implement an error handler.

I just changed the function to return null. But the reality of it is that all of these functions are already returning unreasonable results if they're not checking for degenerate triangles (none of them are). If we think this is a possibility then this these functions should already be handling these cases.

Documenting the possibility and returning null will hopefully make this easier to detect / understand. The biggest issue is that the result looked reasonable.