Texture atlas preprocessing & the art production pipeline.

[brandon-reinhart]

In order to make Bevy a tier 1 engine for 2D games, a better texture atlas art production pipeline is needed.

Requirements:

• It should be possible to drop texture atlas source art into a directory and have the asset preprocessor rebuild the atlas.
• In this sense, the individual source art is uncooked and the atlas is a cooked (shippable) asset.
• More texture atlas services should be exposed through this preprocessing (and the underlying API).
• Preprocessing should be resilient to bad data, communicating the nature of the error without panics. Cooking content should be a viable runtime development activity by non-programmers on the team.

Additional Features:

• The atlas preprocessor should be configurable.
• Option: Trim whitespace. To pack efficiently, the asset preprocessor should be able to trim whitespace and record in metadata the amount trimmed so that the original UVs can be reconstructed.
• Option: Rotate images. To pack efficiently, the asset preprocessor should be able to rotate images 90deg and record in the metadata the rotation bit so that the original UVs can be reconstructed.
• Option: Paginated atlases. It should be possible to specify the max texture size of an atlas and, if the source art exceeds this arrangement, produce additional atlas pages. Meta data would track this and use the appropriate texture binding at render time.
• Option: Resampling rules. It may be useful to be able to specify resampling rules for input images before they are written to the atlas.

Many of these are features of the Esoteric atlas packer, which is very good.

[brandon-reinhart]

Attacking this work probably breaks down into these steps.

1. Research what needs to be done for "N-to-one" asset processing in assetv2. This means that a single output file is produced as a result of any file in a tracked directory changing (modify/add/delete). This may require a PR to file down any rough edges.

2. Get preprocessing and loading working with basic bevy texture atlases using existing features and minimal or no metadata. So we can modify / add / delete and get a functional bevy texture atlas on the other end.

3. Add the advanced configuration features once the simple model is in place and working. (probably a PR per feature)

[msvbg]

Related PR/issue: https://github.com/bevyengine/bevy/pull/11873 / https://github.com/bevyengine/bevy/issues/11634

[clarfonthey]

Found my way at this issue and wanted to just comment on a few low-hanging fruit I noticed.

First, TextureAtlasLayout includes a map from the atlas back to the original images, but this feels like a mistake. By itself, TextureAtlasLayout is a very simple structure that could be made de/serializable, but having asset IDs embedded directly inside it complicates things. IMHO, this should be instead delegated to another type, TextureAtlasSources, which is generated when an atlas is generated, but isn't needed if the atlas is loaded directly.

Second, while the TextureAtlasBuilder is nice, it feels like the majority of the settings for packing a texture atlas should be located in a struct which can also be de/serialized, so it can be used for the input to an asset processor.

Third, there could probably easily be a dedicated asset processor for texture atlases (there aren't any at the moment, but this could be the first!) based upon the above two types.

Finally, it's very weird that the type TextureAtlas doesn't refer to the entire atlas, but a texture on the atlas. It would make sense to have a TextureAtlas type storing the actual atlas asset (including the image), and an AtlasTexture to store the reference to the specific asset and an index.

Would be more than happy to implement a couple of these, after I look more into the code. Just figured I'd star the discussion before I do, since I think it's worth making sure I didn't misread anything.

[msvbg]

@clarfonthey I have largely worked around Bevy’s texture atlases to get something usable for my game. My current workflow is custom but pretty good! I agree with your raised issues, and there are even more problems. It might even warrant its own working group.