AnimationPointerUVs

[echadwick-artist]

This model tests UV transform animations with KHR_animation_pointer for position, scale, and rotation.

[javagl]

This looks fancy in Babylon.js. (Some look like they are not animated - probably not all properties are supported there yet?).

More out of curiosity: Is the labeling 'U Tiling / V Tiling' intentional, instead of 'U Scale / V Scale'?

[bghgary]

We are fixing the issues in Babylon.js. There are issues with the asset also. Discussions are happening here if you are curious.

Here is the latest.

[echadwick-artist]

The labels are for the UI labels in the 3ds Max source, to help the developers of the glTF exporter I am using.

When this asset is closer to completion, I will probably rename the labels to match glTF conventions.

Should I change the meshes into instances? In 3ds Max it’s possible to assign a separate material to each instance, but I’m not sure if this is possible in glTF?

[javagl]

Should I change the meshes into instances? In 3ds Max it’s possible to assign a separate material to each instance, but I’m not sure if this is possible in glTF?

The geometry data of the spheres is indeed duplicated. So one could probably squeeze out a few bytes with intancing or plainly sharing the indices/attributes accessors. But the spheres do not have sooo many triangles, so that's probably negligible compared to the textures. (These, in turn, seem to be mostly JPG. I think that a recommendation is to not use JPG for things like normal textures, because the compression may cause very visible artifacts there, but ... in this case, the image one of "real tiles", which are a tiny bit "noisy" anyhow - and PNG would probably be twice as large, so JPG seems like a reasonable choice here...)

[echadwick-artist]

I have a question about properties sharing UVs.

The baseColor texture and the alphaMode texture must use the same texcoord and the same uv transforms (KHR_texture_transform), because they are loaded using a single baseColorTexture Property per material (there can’t be two baseColorTextures in a single material).

Similarly, the metallic texture and the roughness texture must use the same texcoord and the same uv transforms, because they are loaded using a single metallicRoughnessTexture property per material (there can’t be two metallicRoughnessTextures in a single material).

However… occlusion uses a separate Property from metallicRoughness, and occlusion may use the same bitmap, or it may use a separate bitmap.

If the occlusionTexture uses the same index as the metallicRoughnessTexture, does this mean they must only use the same texcoord and the same uv transforms?

What about other textures with separate Properties but packed color channels? sheenColorTexture.rgb and sheenRoughnessTexture.a for example.

Would the general rule be that if two or more Properties share the same Index, then they must specify the same texcoord and transforms?

[lexaknyazev]

Would the general rule be that if two or more Properties share the same Index, then they must specify the same texcoord and transforms?

There's no rule here. Each texture slot may have its own UV set and transforms.

[echadwick-artist]

There's no rule here. Each texture slot may have its own UV set and transforms.

Thanks Alexey. What do you mean by texture slot? The texture Index? or the texture Property?

[donmccurdy]

I would think of it as a material having the following texture "slots" —

• baseColorTexture
• normalTexture
• metallicRoughnessTexture
• occlusionTexture
• sheenColorTexture
• sheenRoughnessTexture
• ...

These slots ("textureInfo" in spec language) might point to the same or different textures, identified by indices. Each slot may select its UV set and UV transforms independently of the others, even if two slots point to the same texture.

Because there is no glTF concept of an alphaTexture slot at all, it cannot be separated from baseColorTexture. Whereas sheenColorTexture and sheenRoughnessTexture are separate slots (even if they could optionally point to the same texture) and so their UVs and UV transforms may be separated.

Some engines may be less flexible in supporting all of these permutations, of course. :)