Make tiling a texture easier

[Augigogigi]

Objective

This PR attempts to implement a simpler way to tile textures.

Solution

I set the default image sampler to always use wgpu::AddressMode::Repeat so all that is needed to tile textures is to change the mesh UVs, which I added a function to make easier to do. There is also a TextureTilingSettings struct that stores the intended tiling mode for calculating the new UVs. I also edited the texture example to show texture tiling.

UPDATE: I removed the TextureTilingSettings struct (use a TextureTilingMode tuple instead) as I optimized out its usage, and in doing so that also fixed the need to have .init_resource::<TextureTilingSettings>(), which removes the only breaking change I know of.

UPDATE: There are 2 helper functions (in the texture example) that allow you to easily modify mesh UVs to get tiling. You must also modify the ImagePlugin like so:

.add_plugins(
  DefaultPlugins
    .set(ImagePlugin {
      default_sampler: SamplerDescriptor {
        address_mode_u: AddressMode::Repeat,
        address_mode_v: AddressMode::Repeat,
        address_mode_w: AddressMode::Repeat,
        ..default()
      },
    }),
)

---

Migration Guide

None :)
UPDATE: If for some reason you have a texture doing this in your project (the mesh UVs are larger than the texture), it will now tile. Changing this back involves changing ImageSampler's address_mode_u, address_mode_v, and address_mode_w settings back to AddressMode::ClampToEdge
UPDATE: No breaking changes! The 2 helper functions live in the texture example now.

[Augigogigi]

Before this is merged can someone remove the need for .init_resource::<TextureTilingSettings>()? When that is gone there are no breaking changes.

[Augigogigi]

Before this is merged can someone remove the need for .init_resource::<TextureTilingSettings>()? When that is gone there are no breaking changes.

fixed.

[Augigogigi]

There still might be a possible issue with having everything be wgpu::AddressMode::Repeat but I haven't encountered one.

[Augigogigi]

As far as I can see, this is only tiling the base color texture (not roughness or anything else.) I will look into why. nevermind, this was an error with my textures.

[github-actions]

Welcome, new contributor!

Please make sure you're read our [contributing guide](CONTRIBUTING.md) and we look forward to reviewing your Pull request shortly ✨

[github-actions]

Welcome, new contributor!

Please make sure you're read our [contributing guide](CONTRIBUTING.md) and we look forward to reviewing your Pull request shortly ✨

[github-actions]

Welcome, new contributor!

Please make sure you're read our [contributing guide](CONTRIBUTING.md) and we look forward to reviewing your Pull request shortly ✨

[github-actions]

Welcome, new contributor!

Please make sure you're read our [contributing guide](CONTRIBUTING.md) and we look forward to reviewing your Pull request shortly ✨

[github-actions]

Welcome, new contributor!

Please make sure you're read our [contributing guide](CONTRIBUTING.md) and we look forward to reviewing your Pull request shortly ✨

[Augigogigi]

no longer a breaking change.

[Augigogigi]

unless this is gonna be merged soon it should have C-Examples too.

[robtfm]

honestly i think the world uvs function is more confusing now, it is called "plane_uvs" but we use it with Quads not Planes, and it is not generic for any planar mesh, it will fail if the normals point down or left or backwards.

the built in primitive Quads always have x/y-plane positions so using 0 and 1 works. built in primitive Planes always have x/z positions so using 0 and 2 will work. other types of mesh will need custom logic specific to the vertex positions of the mesh.

can we please go back to the simple function for quads with a comment about using positions 0 and 2 for planes?

[Augigogigi]

can we please go back to the simple function for quads with a comment about using positions 0 and 2 for planes?

done