Distorted textures for draped imagery near antimeridian

[javagl]

The first bullet point of the list of follow-ups for draping imagery on 3D Tiles is that wrong texture coordinates are computed at the antimeridian. This is particularly noticable for global tilesets, like Google Photorealistic 3D Tiles in this example:

https://sandcastle.cesium.com/index.html#c=bVTbattAEP2VRU8OhFXaUFJcJ21wigk42OC0eRGYlTSWhuxF7I6kqKX/3l1JbpTGftsz58zlzMiZ0Y5Yg9CCZddMQ8uW4LBW/GePzZIo699Lo0mgBptE5+x3ohkjVCA9MmcHIR2cB0xoVILQ6CnoMtDwYHLYYvYMdhpKhYO16MC+DxVgMq/x2NjQvdGrAdta06APPXYV8NVms1p/HyTSpJN2/px9SfQwGu974O65uyVlXFWC9a/StH5msjV4YqKz3gtCCQ7IB0QrkI7VMwuCYGVMIWFbGjL+LdERZpd3j4Nk1tsSx2yjZceoBDbQ2di2ZZnQLAVWO8hZaCHwjSf/cKiLJ6RyEKz+jR56OzlJZVEhYQOOizyfjU2fTeZolduaqpb9Ot6u9gnSB1GFrndgG8zgXokCbHf0dRiktnLOkqgkqtw8jgtMHQdhqcwFCa6FE7wwTdwqcjFUrrj8/OkqTsFRD/GswK/+VkImGTYccq22T/vXpvZ3oB1St/94cXExUh11EgI1h4OoJY1wmO9BkMWXHdD9XZ+rt8rP4ZZGVT5hKmG/hgbk1ShS4gVVrXpszq567GCsP9CgxzBzXOliZPsF5+gjE5+WPTR79aBt21MWJNHZcUmD9zj4OVz2ZAmhzvGaJxR+sEYdzb91nc5mb7YXEo8b5tPUw+5PFwua6Dxa9IbehMLh9w1VZSyF3c44jwlU5eng4rT23x/xzLkgDNRFPJUucmwY5tcn/g5YJoVzPnKopdzhL0iim0Xs+e+k0ojcH/qmAetPItDKDzfrAeScL2L/PK0kY2Qq7H+Z/wI

Some reasons that contribute to this have already been identified (and some are already fixed in a local branch). But solving this issue generically involves digging through code parts that had to be... "extracted"... from the legacy terrain imagery draping, without completely reverse engineering these parts. Whether or not these parts have to be removed, replaced, or modified is not yet clear. Further details may be added here later.

[jjhembd]

Interesting... My first guess was that there were individual tiles actually crossing the antimeridian. But I can't confirm this--unless perhaps the overlaps / skirts of each tile are extending across.

Here's a screenshot from @javagl 's Sandcastle with bounding volumes overlaid, zoomed on Taveuni Island in Fiji:

The angular orange artifacts are from the draped imagery. The dark shadow in the underlying satellite image is from Google, and is also visible on Google Earth.

Whatever is happening with this particular tileset, I suppose we will also need to consider the general case of individual 3D tiles straddling the antimeridian, and perhaps also the imagery provider straddling it in a different way.

[javagl]

There are a few aspects that are relatively easy to identify as reasons that are contributing to this. A rough summary (maybe I'll go into details later where necessary):

• The vertex positions of the mesh primitive are converted into cartographic positions. From these positions, it computes a bounding rectangle. This is done in computeCartographicBoundingRectangle. This function is not considering the antimeridian. But this was easy to fix (a similar functionality already exists in Rectangle.fromCartographicArray).
• From that cartographic bounding rectangle, it computes an "imagery range" in computeImageryRange. This "imagery range" is just an (integer) coordinate rectangle storing which of the imagery tiles are overlapped by this rectangle. This contains parts that have been ... "derived" ... from the terrain draping, and extracted into functions (like _clampRectangle). That "veryClose" part seems to be unnecessary, based on quick local console.log tests. In any case: This function has to take into account the case where the cartographic bounding rectangle now may cross the antimeridian. This is also a trivial wrapping. When range has minX = 999 and maxX = 1 for 1000 tiles in x-direction, it now has minX = 999, maxX=1001, and on the consuming side, the x-coordinates have to be %1000ed.
• For each imagery tile of this "imagery range", it computes an "imagery coverage", that essentially summarizes how that imagery tile is "mapped" on the geometry. This is done in computeImageryCoverages, and this is where it becomes messy. Some of that code is ... "derived"... from createTileImagerySkeletons. Things like that computeClippedImageryRectangle function have been extracted in an attempt to break all this into smaller pieces, but what exactly that code part is doing is not always clear. The conversions to the "native" rectangles that are happening there all over the place seem to be unnecessary in some cases, but it's hard to be sure about that. And one could think that it's possible to convert a rectangle into its "native" representation with imageryTilingScheme.rectangleToNativeRectangle, and afterwards compute the width of that rectangle, but ... nope - at least not when anything crosses the antimeridian. Some of that looks like it should be easy to fix. And I do have a state that works for test cases of a single (geometry) tile that crosses the antimeridian. But for global terrain, the texture coordinates are still messed up (even more than before that fix), and finding out where exactly something goes wrong is difficult, given that there is zero chance of dedicatedly testing any of this, except for loading a sandcastle and checking whether it "looks right".

[javagl]

Stumbling over comments like #2195 (comment) in an issue that has been open for 10 years is disheartening. (Note the mention of _createTileImagerySkeletons there). It's by no means clear what even can be assumed to work properly here.

[javagl]

I think that this may somehow be related, so I'll just drop this as an internal pointer here: #12087 (comment)