Understanding and using the Unity UI system

With Unity 4.6 released, the new UI system has finally met with you. This article will not show you how to use UI controls such as buttons, scrollbars, which can refer to Unity Manual, and the focus of this article is how to understand the design of the UI system to better use, customize, and extend in practice.

EventSystem

If you use the UI system, the EventSystem object is created automatically. This object is responsible for listening for user input. By default, keyboard and mouse input is available on your computer, and touch input is available on your mobile device. But if you're developing for a device like surface, you can also enable both types of input. When you need to block user input, turn this object off. UnityEngine.EventSystems.EventSystem.current saves the currently active EventSystem object.

Canvas

A Canvas is the root of all other UI objects. There is no limit to the number and hierarchy of canvases in a scene. The child canvas uses the same rendering mode as the parent canvas. A CANVAS has three rendering modes:

Screen Space-overlay: The UI element is displayed on top of any camera screen in 2D relative to the onscreen space. This is a very standard UI style. Typical example: A large number of window, text and button strategy games.

Screen Space-camera: The UI element is displayed by the specified camera, relative to the display space, and the camera's parameters affect the displayed result. You can think of Canvas as a sub-object of the camera. Typical example: A 3D HUD on a shooting game screen.

World Space: UI elements have the same global position and occlusion as objects in other scenes, relative to the world. Often used to make a very innovative UI design. Examples: in-game phone screens, game guides that bind to scenes, and more.

Canvasscaler

This component is responsible for screen adaptation. The UI system uses Recttransform to calculate the location and size of the UI, but that is not enough. How can I make the UI of a design fit different resolutions, aspect ratios, and DPI? This component gives the following 3 adaptation methods, noting that any adaptation method does not change the aspect ratio and relative positioning of the UI.

Constant Pixel Size: Maintains the zoom by adjusting the size of the Canvas pixel. It means that instead of adjusting the zoom factor of the canvas based on the screen resolution, adjusting the canvas's pixel size is always consistent with the screen. You can adjust the zoom factor of the Canvas manually or by code. This is the default adaptation scheme for the UI system. The same UI display differs in both resolutions, although the positioning and size of the UI elements are not changed on different screens (the two white elements in the figure are positioned in the upper-left and lower-right corners of the screen, respectively), but the smaller screen UI elements occupy most of the screen space and appear more crowded. This is the disadvantage of this approach, the small screen is too crowded, the large screen is too empty, not considering the screen resolution and DPI. But the benefit of this pattern is that UI elements can maintain the design-time details (because there is no scaling). This pattern may apply to: you want the UI to be displayed in a certain range at its original size, which allows the UI to display as clearly as possible, while allowing the larger screen player to have a wider view, but on a screen that is too small or too large, you can adjust the zoom factor by the program so that the small screen is fully occupied by the UI, The UI is not found on the big screen.

Scale with screen Size: Scales According to the resolution of the screens. This is probably the most convenient way to fit most games. In this mode, you need to specify a design resolution and then specify the algorithm for scaling. Regardless of the scaling algorithm, if the actual aspect ratio is the same as the design aspect ratio, the UI will be scaled. In fact, the Canvas just keeps its size and the design resolution consistent. If the actual aspect ratio is different from the design aspect ratio, then the scaling algorithm will affect the display results. There are three scaling algorithms: scaling, shrinking, and matching wide heights. The logic of the extension algorithm is to enlarge the short side of the canvas (on the aspect ratio) so that the canvas aspect ratio is consistent with the screen. As shown below, the design resolution aspect ratio is 1:1 (red wireframe) and the actual screen is wider so the width of the Canvas is increased to match the screen. Such an algorithm will always cause the UI to be more "open" on screens with different aspect ratios. The logic of the shrink algorithm is to shrink the long side of the canvas (on the aspect ratio) so that the canvas aspect ratio is consistent with the screen. As shown in the figure below, the design resolution aspect ratio is 1:1 (red wireframe) and the actual screen is narrower so the height of the Canvas is reduced to match the screen. Such an algorithm will always cause the UI to be "compact" on screens with different aspect ratios. The algorithm logic for matching the width to height is that the canvas width and height are adjusted to match the screen according to the specified weights. On the right, the design resolution is the red wireframe, the weights of the width and height are equal (0.5), and the Canvas width and height on the actual screen are adjusted to match the screen. Such an algorithm differs depending on the width-to-height ratio on different screens according to the different UI layouts "fidelity" of the width and height weights.

Constant Physical Size: maintains the scale unchanged by adjusting the Canvas physical size. Instead of resizing the canvas's DPI according to the physical size of the screen, adjusting the canvas's physical size is always consistent with the screen. This argument may be more difficult to understand than Constant Pixel size, in fact they are essentially the same, except that Constant Pixel size is maintained by logical pixel resizing, while Constant physical Si The ze maintains scaling through physical sizing. Using this mode, you must specify a factor to convert the physical size of a pixel (fill in 96 to facilitate development on windows). The runtime calculates the final Canvas pixel size and scale by the DPI reported by the specific device. This model is designed to accommodate some ultra-high DPI display devices (such as the current Mac up to 5K display), but it seems to me to be more confusing to developers, and the actual use value is not high. Because developers are more concerned with designing resolutions, they need to draw clear-sized pictures! Unless future developers and players use ultra-high-dpi displays, they will start ignoring pixel dimensions and focus only on physical dimensions.

Not to be continued.

If you think my article is valuable, I would not mind if I put a "recommendation" or a "concern" ... "White Cat, Blog home: http://www.cnblogs.com/whitecat/"

Understanding and using the Unity UI system