Sandbox: GLB Export destroys KHR_texture_transform?

Bugs
1

Not sure if this is a new bug, or if it’s always been there?

  1. Unzip the attachment.
  2. Drag-and-drop all into the BabylonJS Sandbox.
  3. Inspector > Tools > Export to GLB.
  4. Drag-and-drop the GLB into the Sandbox.

Result: texture transforms have been flattened into the textures, reducing resolution significantly.

Expected: KHR_texture_transform should be preserved, along with the original U Scale and V Scale values.

Exported GLB:

image
image1283×813 365 KB

Original glTF:

image
image1283×813 548 KB

damask_multicolor_chair_gltf.zip (3.1 MB)

As always, thank you for all your hard work on this awesome tool.

2

It was already there unfortunately. This is the way we deal with KHR_Transform

I will add an issue to fix that

1 Like
3

Hi I am using this BABYLON.GLTF2Export.GLTFAsync(scene, “object”).then((gltf) => {
gltf.downloadFiles();
});
for my base I have set texture offset and scale.
output in .gltf is showing like these
“baseColorTexture”: {
“index”: 0,
“texCoord”: 0
}

how to enable KHR_texture_transform

4

Adding @Drigax to double check

1 Like
5

@Atul_Sharma Does your asset have a texture transform already applied?

I used the chair asset uploaded by @echadwick-artist as a test, everything looks fine as far as round-tripping goes.

I can see that some of the asset’s texture maps have offset and scale applied:

image
image1367×916 509 KB

Exported from the sandbox, I can see that the texture transform values were preserved:

image
image1458×1208 95.4 KB

Can you create a PG that reproduces what you’re seeing?

6

Hi @Drigax thanks for your efforts.

No texture transform is not already applied.

When I use my objects in latest sandbox version 4.2.0 beta it still not add texture transform.
It exports texture with offset and scale

https://www.babylonjs-playground.com/#2FDQT5#191
Check this out .
I am setting material baseTexture offset and scale and exporting scene to Gltf.
And in gltf its not adding khr texture transform extension.

Annotation 2020-03-05 121317
Annotation 2020-03-05 121317500×829 10.5 KB

7

Thanks for the example. This is definitely strange. I can see the resulting texture has been changed after export:

image
image2234×1431 440 KB

Tracing through the export, Our implementation of the exporter for KHR_Texture_Transform is very suspect:

@kcoley appears to have authored this extension, but this implementation seems antithetical to the intent of the extension. I’m not sure why the original chair model appears preserved, however.

8

I decided to remove the baking from the texture export process entirely, I’m not sure why we would want to bake out a texture with the normal TRS transformations applied.

So far, this appears to work as expected:

image
image2236×1436 525 KB

I’ll put out a PR containing the change soon.

9

Let s add @bghgary who might be aware of this ?

10

Thanks for the ping @sebavan!

The reason why TRS transformations are sometimes applied is because KHR_texture_transform only support rotation at [0, 0]. See https://github.com/KhronosGroup/glTF/tree/master/extensions/2.0/Khronos/KHR_texture_transform#gltf-schema-updates

Rotate the UVs by this many radians counter-clockwise around the origin

If the rotation point is not at the origin [0, 0], I don’t think there is a way to preserve the original intent in a glTF and thus we bake the transform into the texture. We should use the same resolution though and it shouldn’t loose much precision.

The code is checking this: https://github.com/BabylonJS/Babylon.js/blob/master//serializers/src/glTF/2.0/Extensions/KHR_texture_transform.ts#L122-L133

Perhaps the code is not doing the check properly or not baking the transforms properly.

1 Like
11

Ah, the original complaint was that we were removing the Texture transform extension, if that’s the case then this isn’t a bug. The textures appear to be baked properly. @Atul_Sharma, since you’re offsetting the texture, we cannot export this texture using KHR_texture_transform as @bghgary explained.

12

Well, hold on. The PG from @Atul_Sharma doesn’t do any rotations. If you set uRotationOffset and vRotationOffset to 0, then it won’t bake the transforms. This is because uRotationOffset and vRotationOffset default to 0.5, 0.5 in Babylon.js.

https://www.babylonjs-playground.com/#2FDQT5#192

But since we are not doing any rotations at all, the uRotationOffset and vRotationOffset shouldn’t even matter. The code should be updated to check if there is even a rotation.

4 Likes
13

Ah, good catch! I think we can just simplify this bake code to only check for

   babylonTexture.wAng !== 0 
&& (babylonTexture.uRotationCenter !== 0 || babylonTexture.vRotationCenter !== 0))
14

I’m not sure. If someone uses uAng or vAng, I think that will affect the texture matrix also. Probably should check both of these.

1 Like
15

thanks @bghgary @Drigax It does the work for me now. I have some more doubts I will add them later.

2 Likes