add tex trafo test

[andreasplesch]

for KHR tex. transform extension:

https://github.com/KhronosGroup/glTF/blob/master/extensions/2.0/Khronos/KHR_texture_transform/README.md

just translation
just scale
just rotation
all three, with non-trivial values

[andreasplesch]

https://github.com/KhronosGroup/glTF-Sample-Models/blob/master/2.0/TextureTransformTest/glTF/TextureTransformTest.gltf

covers most situations. Only anisotropic scale is missing.

With isotropic scale the trafo multiplication order of rotation and scale does not matter:

t x r x s = t x s x r

Maybe it is most practical to make the scale anisotropic in the existing example.

[bghgary]

Yes to both. It's good to have samples that test everything together, but it's also useful to separate them individually. Anyone want to contribute a PR to either? I created the Khronos sample by hand, so we can simply update it.

[andreasplesch]

The test with a 2.0, 1.5 scale:

https://github.com/andreasplesch/gltf-test/blob/textrafo/tutorialModels/TextureTransformTest/glTF/TextureTransformTest.gltf

in Three

https://raw.githack.com/andreasplesch/gltf-test/b4f1e00a7d7963df35569ab2326e7d25e231ebdf/examples/threejs/index.html?category=tutorialModels&model=TextureTransformTest&scale=1&type=glTF

in Babylon

https://raw.githack.com/andreasplesch/gltf-test/b4f1e00a7d7963df35569ab2326e7d25e231ebdf/examples/babylonjs/index.html?category=tutorialModels&model=TextureTransformTest&scale=1&type=glTF

[andreasplesch]

I should mention that I put the green check mark in the position where the arrow in Threejs is pointing without confirming or intending to imply that this is the correct position. Note that the arrow in Babylonjs is a little more stretched in U and V which may be actually correct.

[bghgary]

Can you submit a PR to the sample models repo?

[andreasplesch]

I think it would be prudent to first to try to determine which renderer is correct, Three, Babylon, or something else. Perhaps a 90 degree rotation would make any disagreement more obvious.

In my mind, literally since on phone, the uv coordinates should come out then as

start uv

0,0. 1,0

0,1. 1,1

scale 2, 1.5; rotation 90

scale first

0,0. 2,0

0,1.5 2,1.5

then rotation

0,0. 0,2

-1.5,0. -1.5,2

So we should also add a final translation of 1.5,0 to see the complete arrow.
That should look like an arrow pointing down to lower left, and squeezed more horizontally than vertically.

If the order of s and r is swapped we get

r first

0,0. 0,1

-1,0 -1,1

then s

0,0. 0,1.5

-2.5,0. -2.5,1.5

Now the arrow is squeezed more vertically than horizontally. Also, with the same translation, there will be negative u which may be cut off. I think this would be incorrect.

Ok, I convinced myself to try that.

Any pushback or critical review most welcome since this is just theoretical.

[bghgary]

Assuming the math is right, that sounds like a good plan.

We are discussing this in the wrong repo, so I would prefer to move this to the sample models repo.

[andreasplesch]

Well, I was looking for somebody to check the math, of course. Will continue in the sample models repo.

[bghgary]

Gotcha. Once you have the issue ready, I'll find some time to review the math.

[bghgary]

I checked the math and the numbers look right to me.

[andreasplesch]

177 (in the Sample Models repo) got complicated fast. I think this has to wait.

KhronosGroup/glTF-Sample-Models#177

[bghgary]

I'm not sure what you are referencing. #177 has nothing to do with this?

[andreasplesch]

sorry, I did not consider the autolinking. fixed above.

There is a deeper spec. issue.

[andreasplesch]

But the only option is to apply the spec. as written. This means shearing of images, it seems.

Reading through the discussions, I think the rotation is applied counterclockwise. So the math changes to:

scale 2, 1.5; rotation 90 (really -90)

scale first (unchanged)

0.0,0.0---2.0,0.0
|               |
0.0,1.5---2.0,1.5

then rotation

0.0,0.0 --- 0.0,-2.0
|                  |
1.5,0.0 --- 1.5,-2.0

This explains why a final offset of 0,1 worked in the example.

So Babylon is conforming and Three is not but Three does what may be the least surprising to authors.