Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support the KHR_texture_transform GLTF extension #11869

Closed
janhohenheim opened this issue Feb 15, 2024 · 3 comments · Fixed by #11904
Closed

Support the KHR_texture_transform GLTF extension #11869

janhohenheim opened this issue Feb 15, 2024 · 3 comments · Fixed by #11904
Labels
A-Rendering Drawing game state to the screen C-Feature A new feature, making something new possible

Comments

@janhohenheim
Copy link
Member

janhohenheim commented Feb 15, 2024

What problem does this solve or what need does it fill?

In Blender, the default way of making sure a texture tiles n times is to add a UV Map and a Mapping node, like this;
image
The above example tiles the texture exactly 5 times.

This transforms the UV. The Blender GLTF exporter supports this by writing it to the KHR_texture_transform extension. So, setting the nodes up as follows, we get a nicely tiled GLTF:
image
I have a simple greyboxing grid texture applied to a cube in this case. Viewing it through a GLTF viewer, I get this:
image
As you can see, the text in the grid is repeated 5 times per face. Opening this up in Bevy however... (ignore the poor lighting)
image
Oh no! Bevy does not support GLTF extensions yet, so it just stretches the texture instead of tiling it!

What solution would you like?

Ideally, Bevy should apply the transforms to the UV automatically when encountering this extension. As the Khronos group link specifies, most implementations ignore the rotation value, so I think it's fine if we do too. Most important are the offset for texture atlases and scale for tiling.

What alternative(s) have you considered?

Leave it to the user. #11138 allows us to read the extension manually, so a user could write a custom shader or a shader extension for this.

Additional context

@janhohenheim janhohenheim added C-Feature A new feature, making something new possible S-Needs-Triage This issue needs to be labelled labels Feb 15, 2024
@janhohenheim
Copy link
Member Author

janhohenheim commented Feb 15, 2024

I'd be ready to implement this myself if anyone gave me some pointers on how/where to change the UVs :)
Edit: looks like there is already a PR for this: #8266. Is there anything I can do to help it go along?

@alice-i-cecile alice-i-cecile added A-Rendering Drawing game state to the screen and removed S-Needs-Triage This issue needs to be labelled labels Feb 16, 2024
@alice-i-cecile
Copy link
Member

It looks like the PR has been abandoned by the author: adopt it by forking the work and submitting a new PR, then ping the original reviewers for a re-review :)

@janhohenheim
Copy link
Member Author

janhohenheim commented Feb 16, 2024

@alice-i-cecile, alright, I'll try to get it done later, hopefully quick enough for 0.13 💪

github-merge-queue bot pushed a commit that referenced this issue Feb 21, 2024
Adopted #8266, so copy-pasting the description from there:

# Objective

Support the KHR_texture_transform extension for the glTF loader.

- Fixes #6335
- Fixes #11869 
- Implements part of #11350
- Implements the GLTF part of #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`:


![texture_transform](https://user-images.githubusercontent.com/283864/228938298-aa2ef524-555b-411d-9637-fd0dac226fb0.png)

## Changelog

Support for the
[KHR_texture_transform](https://github.com/KhronosGroup/glTF/tree/main/extensions/2.0/Khronos/KHR_texture_transform)
extension added. Texture UVs that were scaled, rotated, or offset in a
GLTF are now properly handled.

---------

Co-authored-by: Al McElrath <[email protected]>
Co-authored-by: Kanabenki <[email protected]>
msvbg pushed a commit to msvbg/bevy that referenced this issue Feb 26, 2024
Adopted bevyengine#8266, so copy-pasting the description from there:

# Objective

Support the KHR_texture_transform extension for the glTF loader.

- Fixes bevyengine#6335
- Fixes bevyengine#11869 
- Implements part of bevyengine#11350
- Implements the GLTF part of bevyengine#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`:


![texture_transform](https://user-images.githubusercontent.com/283864/228938298-aa2ef524-555b-411d-9637-fd0dac226fb0.png)

## Changelog

Support for the
[KHR_texture_transform](https://github.com/KhronosGroup/glTF/tree/main/extensions/2.0/Khronos/KHR_texture_transform)
extension added. Texture UVs that were scaled, rotated, or offset in a
GLTF are now properly handled.

---------

Co-authored-by: Al McElrath <[email protected]>
Co-authored-by: Kanabenki <[email protected]>
msvbg pushed a commit to msvbg/bevy that referenced this issue Feb 26, 2024
Adopted bevyengine#8266, so copy-pasting the description from there:

# Objective

Support the KHR_texture_transform extension for the glTF loader.

- Fixes bevyengine#6335
- Fixes bevyengine#11869 
- Implements part of bevyengine#11350
- Implements the GLTF part of bevyengine#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`:


![texture_transform](https://user-images.githubusercontent.com/283864/228938298-aa2ef524-555b-411d-9637-fd0dac226fb0.png)

## Changelog

Support for the
[KHR_texture_transform](https://github.com/KhronosGroup/glTF/tree/main/extensions/2.0/Khronos/KHR_texture_transform)
extension added. Texture UVs that were scaled, rotated, or offset in a
GLTF are now properly handled.

---------

Co-authored-by: Al McElrath <[email protected]>
Co-authored-by: Kanabenki <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Rendering Drawing game state to the screen C-Feature A new feature, making something new possible
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants