Account for degenerate axes of OrientedBoundingBox in distanceSquaredTo

[j9liu]

Fixes #9658. Before normalizing the halfAxes, the function will check if their magnitude is nonzero. If not, it will generate new substitute axes based on which ones are degenerate, then proceed with the same algorithm. I added a bunch of specs to account for these changes.

I'm sure the code organization / style can be cleaned up a bit. @lilleyse - do you mind taking a look?

[cesium-concierge]

Thanks for the pull request @j9liu!

• ✔️ Signed CLA found.

Reviewers, don't forget to make sure that:

• Cesium Viewer works.
• Works in 2D/CV.
• Works (or fails gracefully) in IE11.

[lilleyse]

Overall the approach makes sense and it fits into the current algorithm cleanly, though it feels a little verbose and I wonder if specialized distance functions for each degenerate axes case would be less code and/or faster. The non-degenerate case ought to run fast still which is most important.

Since distanceSquaredTo is a hotspot in the code it would be worth benchmarking. The benchmark should create some randomly sized, non-degenerate OBBs, and call distanceSquaredTo multiple times for each. You can look at @sanjeetsuhag's sandcastles in #9599 for reference. Make sure to test with the built version of CesiumJS (npm run minifyRelease npm run combineRelease, npm run buildApps, then go to http://localhost:8080/Build/Apps/Sandcastle/index.html). Run the benchmark on this branch and master.

Other than that, very robust tests like usual!

[j9liu]

EDIT: truncated the numbers for easier reading.

@lilleyse - Here's the benchmark sandcastle (localhost) I used to get the following numbers:

Run #	master	obb-distancesquared	times faster than master
1	0.0042592	0.0033573	1.2686x
2	0.0041313	0.0034534	1.1963x
3	0.0041913	0.0034055	1.2307x
4	0.004239	0.0034258	1.2373x
5	0.0042231	0.0034183	1.2354x

It seems that right now, obb-distancesquared is slightly faster than master -- maybe this is because of the use of Cartesian3.normalize (and thus the duplicate call to Cartesian3.magnitude) in the original code.

[lilleyse]

I'm seeing similar results on Firefox Linux: 0.013468 (master) 0.012589 (obb-distancesquared) 👍

[lilleyse]

I confirmed this fixes the particle system crash in #9658 when TileBoundingRegion uses an obb distance check.

@kring @baothientran would you like to review as well? Assuming this makes its way back to cesium-native.

[lilleyse]

I'm going to merge - but any more feedback is welcome after.

Thanks @j9liu!