Flip textures and UVs

[david-lively]

Description

This PR modifies the texture and model import process to comply with Unity's U-right, V-up convention.
The glTF 2.0 spec mandates that textures are anchored at UV (0,0) and the upper-left corner of the texture, with UVs increasing to the right and down. (See https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html#images .)
Unity, however, assumes that UV (0,0) corresponds to the bottom-left corner of the image. Previously, the system did not flip either the textures OR the UVs, so it mostly worked, but has caused issues with tangent generation.

In the UV overlay debug images below, the six columns on the left were loaded by Cesium, while the six on the right were loaded by Unity glTFast. These were generated using the same glTF model:

This requires changes to cesium-native in CesiumGS/cesium-native#1259 .

Before this change:

After this change:

With textures flipped:

Author checklist

• I have submitted a Contributor License Agreement (only needed once).
• I have done a full self-review of my code.
• I have updated CHANGES.md with a short summary of my change (for user-facing changes).
• I have added or updated unit tests to ensure consistent code coverage as necessary.
• I have updated the documentation as necessary.

Testing plan

Load a tileset. Use Unity's Render Debugger to visualize the Texcoord0 vertex attribute. Observe that UV coordinates increase in the right- and up-direction, and that textures are correctly flipped to match.

[j9liu]

Thanks @david-lively! I'm still building this locally to test it out, but figured I'd post my comments now.

[j9liu]

Thanks for the changes @david-lively ! Just a few small things that I won't trouble you with; I'll batch into a commit so CI can start running.

[kring]

This branch breaks KHR_texture_transform. Here's what TextureTransformMultiTest looks like in v1.18.1:

Here's what it looks like in this branch:

Presumably the problem is that the texture translation is going in the wrong direction now that the texture coordinates have been inverted.

While this is probably easy to fix, we need to think about what else might break with the texture coordinate inversion. Anything with feature ID textures perhaps?

Or, is it worth avoiding the issue by not inverting texure coordinates on load, but only inverting them when handing them off to mikktspace? Or, alternatively, computing tangents entirely with glTF conventions, and then transforming them for Unity?

I can kind of argue either way. Creating models with texture and texture coordinates that violate the usual bottom-left-origin Unity convention is not great. But we can think of that as glTF textures arriving flipped and the texture coordinates are designed to assume that. It's perhaps a little weird but not wrong. By sticking with glTF conventions throughout, we perhaps make it easier / less error prone to support all the glTF things because everything uses the glTF conventions, except for a transformation to the Unity coordinate system at the end.

[kring]

KTX compressed textures aren't working right either. Unfortunately it's really subtle in these images, which come from the glTF-KTX-BasisU version of AnisotropyBarnLamp:

v1.18.1:

This branch:

It makes sense this wouldn't work, though. Flipping rows of compressed images isn't going to work correctly.

Unlike the problem above, it's not immediately obvious to me how to fix this one without reverting this PR.

[kring]

Metadata textures seem to be working well in this branch. 👍