If I try to calculate an intersection of two rectangles with GlobeRectangle::computeIntersection, and one of those rectangles crosses the antimeridian and the other rectangle just touches the antimeridian, it will fail to find an intersection - even though they should obviously be overlapping.
You can see a demonstration of this in CesiumJS, because the intersection code is the same. Even though the two rectangles are clearly overlapping in the image, the intersection calculation returns undefined. If you change the west coordinate of rectangle b to some other value (even one very close to -Math.PI, like -3.1415926535), suddenly it can correctly find the intersection.
It looks like normally what happens is that the intersection function adds 2pi to b.west because a crosses the antimeridian, and then later on negativePiToPi turns it back around. So -3.14 becomes 3.14 becomes -3.14 again and all works out. But with -Math.PI it becomes Math.PI from the addition of 2pi, which negativePiToPi takes to mean nothing needs to be done and returns the value as is. Changing the check from angle <= Math::OnePi to angle < Math::OnePi in negativePiToPi fixes the issue, though I'm not convinced this is the actual solution (especially because CesiumJS has been running with this exact code for 15 years).
If I try to calculate an intersection of two rectangles with GlobeRectangle::computeIntersection, and one of those rectangles crosses the antimeridian and the other rectangle just touches the antimeridian, it will fail to find an intersection - even though they should obviously be overlapping.
You can see a demonstration of this in CesiumJS, because the intersection code is the same. Even though the two rectangles are clearly overlapping in the image, the intersection calculation returns undefined. If you change the west coordinate of rectangle b to some other value (even one very close to -Math.PI, like -3.1415926535), suddenly it can correctly find the intersection.
It looks like normally what happens is that the intersection function adds 2pi to b.west because a crosses the antimeridian, and then later on
negativePiToPiturns it back around. So -3.14 becomes 3.14 becomes -3.14 again and all works out. But with -Math.PI it becomes Math.PI from the addition of 2pi, whichnegativePiToPitakes to mean nothing needs to be done and returns the value as is. Changing the check fromangle <= Math::OnePitoangle < Math::OnePiinnegativePiToPifixes the issue, though I'm not convinced this is the actual solution (especially because CesiumJS has been running with this exact code for 15 years).