Add support for KHR_texture_transform

[janhohenheim]

Adopted #8266, so copy-pasting the description from there:

Objective

Support the KHR_texture_transform extension for the glTF loader.

• Fixes glTF not being rendered correctly. UV texture issue?  #6335
• Fixes Support the KHR_texture_transform GLTF extension #11869
• Implements part of Robust GLTF Extension Support #11350
• Implements the GLTF part of Tiled/repeating textures #399

Solution

As is, this only supports a single transform. Looking at Godot's source, they support one transform with an optional second one for detail, AO, and emission. glTF specifies one per texture. The public domain materials I looked at seem to share the same transform. So maybe having just one is acceptable for now. I tried to include a warning if multiple different transforms exist for the same material.

Note the gltf crate doesn't expose the texture transform for the normal and occlusion textures, which it should, so I just ignored those for now. (note by @janhohenheim: this is still the case)

Via cargo run --release --example scene_viewer ~/src/clone/glTF-Sample-Models/2.0/TextureTransformTest/glTF/TextureTransformTest.gltf:

Changelog

• Support for the KHR_texture_transform extension added. Texture UVs that were scaled, rotated, or offset in a GLTF are now properly handled.
• Added a new method affine2_to_square to the WGSL API. An Affine2 can be efficiently packed for the GPU as a mat3x2. This new methods unpacks that into a mat3x3 that can be used to transform coordinates.
• For consistency with the new affine2_to_square, we renamed affine_to_square to affine3_to_square

Migration guide

Rename affine_to_square to affine3_to_square

[janhohenheim]

@mockersf you wrote the following on the original PR:

A Affine2 seems better (smaller and faster) for the transform than a Mat3?

Could you explain to me why? Unless I understood something wrong, we'll need the Mat3 on the WGSL side anyways, so we might as well have a matrix on the StandardMaterial as well in order to not have to convert them around on every frame.

[janhohenheim]

Note that the current code recalculates the uv in both pbr_prepass_functions.wgsl and pbr_types.wgsl. Could someone with more knowledge of the shaders tell me how you usually cache these sorts of values?

[janhohenheim]

Not sure what I'm supposed to do about the duplicated dependencies check, could someone help me out there as well? The feature I added shouldn't pull in any additional transient dependencies according to gltf and gltf-json's Cargo.toml

[Kanabenki]

Note that the current code recalculates the uv in both pbr_prepass_functions.wgsl and pbr_types.wgsl. Could someone with more knowledge of the shaders tell me how you usually cache these sorts of values?

Since these happen in separate passes and the result vary depending on the input vertex I don't think you can share the transformed uvs easily? Besides I don't think that's a major perf cost.

Not sure what I'm supposed to do about the duplicated dependencies check, could someone help me out there as well? The feature I added shouldn't pull in any additional transient dependencies according to gltf and gltf-json's Cargo.toml

I think the current CI failure for that isn't caused by your changes, it is present in other PRs and isn't a blocker for merging.

[janhohenheim]

Alright, thanks! Then this PR is ready for merging from my point of view :)

[Kanabenki]

A couple of suggestions 🙂

[janhohenheim]

Good improvement suggestions, thanks! I'll implement them later today :)

[janhohenheim]

@Kanabenki ready for a re-review and I've got a question for you in one of the comments.

[janhohenheim]

@Kanabenki I think I addressed all your comments now :) Thanks for the review!

[superdump]

@janhohenheim - the renaming of affine_to_square and the changes to StandardMaterial(Uniform) are breaking changes so should be documented in the PR description as we use tooling to extract those parts to make the migration guides so please add that information (and any I missed :)) to the description.

[github-actions]

It looks like your PR is a breaking change, but you didn't provide a migration guide.

Could you add some context on what users should update when this change get released in a new version of Bevy?
It will be used to help writing the migration guide for the version. Putting it after a ## Migration Guide will help it get automatically picked up by our tooling.

[mockersf]

this PR broke WebGL2 rendering: #12081

[janhohenheim]

@mockersf ah heck! I'll look into it later today. Sorry for not testing that!

[alice-i-cecile]

Thank you to everyone involved with the authoring or reviewing of this PR! This work is relatively important and needs release notes! Head over to bevyengine/bevy-website#1287 if you'd like to help out.