StandardMaterial Support for Texture2dArray (Texture Arrays)

[Vricken]

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

Creating games that rely on texture atlases—such as voxel engines, tile-based 3D maps, and sprite-packed materials—is difficult in Bevy without incurring texture bleeding artefacts.

Texture bleeding occurs when using linear filtering or mipmaps with a 2D texture atlas. When a tile’s UVs are close to its edge, texture sampling may pull in pixels from adjacent tiles. This is especially visible at oblique viewing angles or when using mip levels.

This results in:

• Blurry or incorrect pixels at tile edges

• Flickering or colour bleeding between tiles

• Difficult-to-control rendering quality, especially at distance

Workarounds like padding tiles or using nearest filtering exist, but are limited or introduce tradeoffs.

This bleeding issue has a well-established, GPU-level solution: using texture arrays (Texture2dArray), where each tile exists on a separate layer. The GPU guarantees that filtering and mipmapping do not sample across layers, completely eliminating inter-tile bleeding.

What solution would you like?

I propose that StandardMaterial be enhanced to optionally support Texture2dArray textures.

This could be done with minimal changes while keeping backwards compatibility. I'm new to bevy so I can't really add much detail on the implementation.

What alternative(s) have you considered?

Custom materials

It’s possible to write a new material type and re-implement Bevy’s PBR logic in WGSL using texture_2d_array, but this:

Duplicates a large amount of Bevy’s core shader code

Locks the user out of improvements to StandardMaterial

Increases maintenance burden significantly

Atlas padding

Padding each tile with duplicate pixels reduces bleeding from mipmaps, but:

Doesn’t solve filtering artefacts at oblique angles

Wastes texture memory

Still allows some bleeding in practice

Nearest filtering

Prevents bleeding completely, but:

Forces a pixelated appearance

Removes access to smooth filtering or mipmapping

Disabling mipmaps

Avoids bleeding but:

Severely impacts visual quality and performance at distance

Causes excessive texture aliasing

Additional context

While the main benefit of Texture2dArray support is the elimination of texture bleeding, it may also reduce the visibility of seams caused by MSAA in certain tile-based rendering setups. By isolating tiles on separate texture layers, UV discontinuities between adjacent faces are less likely to cause visible edge blending artefacts.

This feature would enable smoother, higher-fidelity rendering in:

• Voxel games (e.g., Minecraft-style)

• 3D tilemaps (strategy, tactics, RPGs)

• Grid-based worlds or large sprite sets

It would also help keep developers within Bevy’s standard material pipeline, instead of forcing divergence for a common use case.

Thank you for considering this request!

[alice-i-cecile]

I propose that StandardMaterial be enhanced to optionally support Texture2dArray textures.

@tychedelia or one of our other rendering experts can probably say more, but I'm reluctant to add more functionality to StandardMaterial in particular. This seems like a very reasonable feature for things like tilesets or sprite sheet animations too.

This feels like an optional feature for any material, not just StandardMaterial, but I don't know that bit of the code base well enough to say how excctly it should be implemented.

[IceSentry]

I'm not convinced this is the right direction for StandardMaterial. Like alice said, it's already way too big. Also, for a voxel game you'll likely want to do a lot more shader trickery to make it efficient so the StandardMaterial is not the best for that.

What I'd like to move towards is a more flexible way to build custom materials and give functions to people so they can easily compose the features they need without having to copy a ton of code. We are already moving slowly towards that to be clear, but just trying to show this is one of the reason why. The StandardMaterial is essentially intended for rendering, well, standard meshes generally imported from something like gLTF. It's not really supposed to be a one size fits all material.