Asset-Driven Nine Patch #13134
Labels
A-Assets
Load files from disk to use for things like images, models, and sounds
A-UI
Graphical user interfaces, styles, layouts, and widgets
C-Usability
A simple quality-of-life change that makes Bevy easier to use
What problem does this solve or what need does it fill?
Currently, Bevy's nine-patch image support is done using a component, where you specify the values for top/bottom/left/right margins. This is very convenient for hardcoding the values, but it makes it difficult to have artists specify and tweak them along with the image assets.
I'd like to make a comparison with Bevy's implementation of Texture Atlases. The texture atlas layout is stored in an asset. It is possible to generate those layouts programmatically (such as if you want to hardcode things), but them being assets gives additional flexibility. Out of the box, Bevy does not provide some sort of special file format for describing a texture atlas, but there are crates, such as
bevy_asset_loader
, which do provide a way to have the data be specified in asset files. That allows texture atlas parameters to be edited without recompiling the game.Currently, if I want to be able to edit my nine-patch images and change the margins, I have no way to do it without recompiling the game.
Sure, eventually some day bevy is going to have a nice scene format and we are all going to be authoring our entire UIs in scene files, so the values are going to be right there alongside Style and everything else ...
But I still feel like a component on the UI node is not the right place to put this data. The nine-patch margins are tied to the specific image, much like texture atlas layouts are. They are not so much a property of the UI layout/hierarchy where they are used, as much as they are a property of the image itself. When an artist creates the image, the values only make sense for that image specifically.
What solution would you like?
Move the image scaling stuff like nine-patch into an asset type, similar to TextureAtlasLayout, instead of just a component on the UI node entity.
What alternative(s) have you considered?
Implementing it myself:
The text was updated successfully, but these errors were encountered: