UI section of document has a lot of thorough informations, but its page organization is a little bit hard to see a big picture. I mean, each page has useful details and understandable infos for the features of engine, but understanding the relations of each systems is complex because of the listings and the tree structures of the pages.
For example,
- UI Canvas is the top level Actor, and UI Controls are Actors needed to be inside UI Canvas.
- Text Render and Sprite Render are independant Actors for dedicated specific purpose, which that UI Canvas is not required.
- Transform is a property mechanism for the UI Control Actors.
- Brush is an object used as property mechanism for the drawing delegation of the UI Controls.
- Image control is a UI control, which is specialized to draw just a brush.
- Sprite Brush is a dedicated Brush for Sprite, which that Sprite Atlas and Sprite object required.
As you can see, relation of each idea of things are not just parallel nor just hierarchical. What makes even difficult is that the tree structure or sequential listing in the document is not representing the hierarchy nor the lateral relations exactly. Especially, ‘Brush’ concept is not just represented in engine Actors list, but used in so many features to customize or implementing the details of UI controls, and related in many concepts like Image, Sprite, Buttons etc while not explicitly managed as an Actor or an Asset. ‘Brushes’ page is at the same level as ‘UI Canvas’ and ‘UI Control’ page while ‘Transform’ page is under the ‘UI Control’ page, and ‘Controls’ page is at the same level as ‘Sprite Render’ page, parallel to ‘UI Canvas’ and ‘UI Control’ page.
Especially ‘Sprite’ is a mix of multiple ideas and things combined, and its description is fragmented in so many parts in document, which is not thorough enough for making a working sample.
- Sprite Atlas is an asset for storing the total set of sprites packed into a texture.
- Sprite is an identifier for a single sprite inside a Sprite Atlas.
- SpriteBrush is an Brush object which can be created in editor or code, having sprite-specific functions.
- SpriteHandle is a handle, in detail, handle can be achived by the ‘sprite’ property of a SpriteBrush object.
- sprite image can be ‘assigned’, with a SpriteHandle which contains the Sprite index for the Atlas, by setting the SpriteBrush made from SpriteHandle which defines the actual Actor(UI Control like Image or SpriteRenderer)'s drawing action.
In this level I can’t even sure I am describing the relations not missing terribly…
Each items (Brushes page, Sprite Renderer page, Image Control page etc) are explained in document well and understandable, but as a whole it is enigmatic to connect the puzzle of ideas of implementing the ‘working mechanism of sprite atlas flipbook animation’.
You see, you may think you can make a 9-sliced button design after reading the Controls-Button page and Brushes-9 Slicing brush page, but you cannot find or attach the 9-sliced brush in the property page after adding the Button control, because it is related to Image or Sprite Render control!
I understand that it may be too big to add a full tutorial of all UI things, but hoping at least that the pages for UIs currently describing the concepts of each UI mechanisms may be reorganized in document hierarchy in the future, to help connecting the dots.