Bevy Tilemap Renderer
Motivation
Bevy currently lacks first-party support for tilemap rendering, leaving developers to rely on third-party crates or implement their own systems. This fragmentation leads to inconsistent APIs and duplicate effort. First-party tilemap rendering will enable developers to build tile-based games and 3rd party integrations more easily and efficiently.
Goals
- Support a wide variety of use cases
- Rectangular, isometric, hexagonal tile shapes
- Finite and infinite tilemaps
- Atlas, array texture, and file-per-tile assets for tilesets
- Clean separation of tilemap rendering and higher-level APIs
- Focus on performance
- Enable existing tilemap crates to swap out their own rendering implementations
- Build on top of Bevy's high-level rendering as much as possible (Mesh2d/Material2d)
Features
Asset to Tileset Pipeline
- Provide a first-party asset type for tilesets
- Load tileset images as array texture (1 layer per tile variant)
- Define metadata for tile dimensions and layout
- Support slicing packed texture atlases into the array texture
- Support combining separate tile images into the array texture
Fast Chunk-Based Rendering
- Divide the map into fixed-size chunks (e.g. 32x32 tiles)
- A chunk is a Mesh2d with a custom chunk shader
- The shader is responsible for rendering tiles based on tile data and cached mesh data
Tile Data
- Tileset texture index (tile variant)
- Color
- Visible
- Flip X/Y/Diagonal
- Rotate?
Tile Storage
- Tile data stored in a single source of truth
- Support both sparse and dense storage?
- Modifying tile storage should only update relevant chunks
Infinite/finite Map
- Allow dynamic growth in all directions (IVec2 tile positions, not UVec2)
- Support lazy loading of chunks?
- Allow setting map bounds to constrain and enable whole-map transform anchoring
Proposed API
Out of Scope
- Higher-level ECS API (Entity-per-tile, Tile/Tilemap relation, traversal, etc.)
- Advanced features like animated tiles, auto-tiling,