bevyengine / bevyengine/bevy

StandardMaterial Support for Texture2dArray (Texture Arrays)

Open
#20,134 2 comments 1 reaction 0 assignees View on GitHub
A-Rendering C-Feature S-Needs-Design X-Uncontroversial
Dominant language
Rust
Stars
48.2k
Forks
4.8k
Avg merge
3d 22h
Merged PRs (30d)
161

Description

## 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!

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.