Draping across antimeridian

[javagl]

Description

As described in #12769 , draping imagery on 3D Tiles does currently not work for tiles that cross the antimeridian. There are several factors that contribute to this vague concept of "not working". Some of them have been mentioned in #12769 (comment) .

This DRAFT PR contains a few commits that address these points, but there are many follow-up changes that are not integrated here yet.

• The computation of the bounding rectangle of the tile has to take into account that the tile might cross the antimeridian. For the cartographic version of the bounding rectangle, this is handled with 78d2440
  • The BoundingRectangle.fromRectangle function does not work for this case. So as a follow-up-fix, there is a new function to compute the bounding rectangle from a rectangle, added in 22cadc1
  • When computing the cartographic positions (later, when computing texture coordinates), the "wrapping" that may have occurred earlier has to be taken into account. As a follow-up fix, the cartographic positions are wrapped into the range that actually is described with that new bounding rectangle, via e4958a0
• The range of imagery tiles that are covered by the geometry (the "imagery range") has to anticipate the wrapping at the antimeridian. When minX = 999, maxX = 1 for this range, then this will be turned into minX = 999, maxX = 1001 and the receiver has to wrap this, to receive the actual imagery tile coordinates 999, 0, 1. This is done in 267fe47
• Texture coordinates have to be computed for the geometry, based in the imagery tiles. The information here is summarized in ImageryCoverage objects. But the rectangles that are involved here are converted into their "native" representation. And the Rectangle.computeWidth function is broken for this case. An attempt to provide a function to compute the necessary texture coordinates is drafted in ee5dcdd . This operates on "non-native" rectangles (i.e. on real Rectangle objects that actually do follow the constraints that are described in the Rectangle class). This part even involves a few unit tests, because ... why not? Whether or not the computation of the texture coordinates can or should happen based on the "non-native" rectangles, or whether it must happen based on the "native" rectangles is not yet clear to me. Given that all this aims at relative coordinates, I think that it should be possible to implement that based on "any" rectangle. But maybe there are some sorts of distortions from the projection that wouldn't be taken into account based on "real" rectangles...? In any case, certain inlined clipping, clamping, and conversion steps that have been taken from the terrain imagery implementation will have to be reviewed for this.

The current state contains several logs and places that are marked with comments saying that they may require further review or follow-up fixes.

Issue number and link

Addresses #12769

Testing plan

None yet

Author checklist

• I have submitted a Contributor License Agreement
• I have added my name to CONTRIBUTORS.md
• I have updated CHANGES.md with a short summary of my change
• I have added or updated unit tests to ensure consistent code coverage
• I have updated the inline documentation, and included code examples where relevant
• I have performed a self-review of my code

[github-actions]

Thank you for the pull request, @javagl!

✅ We can confirm we have a CLA on file for you.