[ 번역 ] Fandamentals of Unity UI

원문 : Funadamentals of Unity UI

주의 : 번역이 개판이므로 이상하면 원문을 참조하십시오.

주의 : 허락받고 번역한 것이 아니므로 언제든 내려갈 수 있습니다.

---

Fundametals of Unity UI

확인 완료한 버전: 5.3 - 난이도: 고급

유니티 UI 시스템을 구성하는 여러 부분을 이해하는 것은 중요합니다. 그 시스템을 구성하는 여러 개의 기본 클래스들과 컴포넌트들이 있습니다. 이 챕터는 먼저 이 기사의 시리즈 전반에서 사용될 몇 개의 개념들을 정의하고, 유니티 UI 의 몇 가지 핵심 시스템의 저수준 동작에 대해 논의할 것입니다.

Teminology

Canvas 네이티브 코드 유니티 컴포넌트인데, 이는 게임의 월드 공간의 상위에 그려질 레이어화된 지오메트리( geometry )를 제공하기 위해 유니티 렌더링 시스템에 의해 사용됩니다.

Canvas 들은 자신의 내부 지오메트리를 배칭( batching )할 책임이 있으며, 적절한 렌더링 커맨드들을 생성하고 이것들을 유니티 그래픽스 시스템에 전달합니다. 이것은 전부 네이티브 C++ 코드에서 수행되며, 이는 rebatch 라든가 batch build 라고 불립니다. 캔버스가 리배칭을 요구하는 지오메트리로 구성되어 있다고 표시되면, 그 캔버스는 갱신되었다( dirty )고 판단됩니다.

지오메트리는 Canvas Renderer 컴포넌트에 의해 Canvas 에 제공됩니다.

Sub-canvas 는 그냥 Canvas 컴포넌트인데, 이는 다른 Canvas  컴포넌트에 내포됩니다. Sub-canvas 들은 그들의 부모의 다른 자식들과는 독립적입니다: 한 자식이 갱신되었다고 해서 부모로 하여금 그것의 지오메트리를 리빌드하도록 강제하지는 않을 것이라는 것입니다.

Graphic 클래스는 유니티 UI C# 라이브러리에 의해 제공되는 기반 클래스입니다. 이것은 Canvas 시스템 상에서 그려질 수 있는 지오메트리를 제공하는 모든 유니티 UI C# 클래스들의 기반 클래스입니다. 대부분의 내장 유니티 UI Graphics 들은 MaskableGrphic 서브 클래스를 통해서 구현됩니다. 이는 IMaskable 인터페이스를 통해 그것들이 마스킹될 수 있도록 해 줍니다. Drawable 의 주요 서브클래스들은 Image 와 Text 입니다. 그것들은 자신의 이름과 동일한 컴포넌트들을 제공합니다.

Layout 컴포넌트는 RectTransform 의 위치와 크기를 제어하며, 일반적으로 자신의 칸텐츠에 대한 상대적인 크기와 위치를 요구하는 복잡한 레이아웃을 생성하기 위해서 사용됩니다. Layout 컴포넌트는 RectTransform 에 의존하며, 이는 그것들에 연관된 RectTransform 의 속성에 영향을 미칩니다. 그것들은 Graphic 클래스에 대해서 종속적이지 않으며, 유니티 UI 의 Graphic 컴포넌트들과는 독립적으로 사용될 수 있습니다.

Graphic 컴포넌트와 Layout 컴포넌트는 모두 CanvasUpdateRegistry 클래스에 의존하는데, 이는 유니티 에디터 인터페이스에는 노출되지 않습니다. 이 클래스는 갱신되어야만 하는 Layout 컴포넌트와 Graphic 컴포넌트의 집합을 추적하는 클래스이며, 그것과 연관된 Canvas 가 willRenderCanvases 이벤트를 호출할 때 필요에 의해 트리거들이 갱신됩니다.

Layout 컴포넌트와 Graphic 컴포넌트에 대한 갱신을 rebuild 라 부릅니다. 이 리빌드 절차에 대해서는 이 문서의 나중에 더 세부적으로 다루도록 하겠습니다.

Rendering Details

유저 인터페이스를 유니티 UI 로 만들 때, Canvas 에 의해 그려지는 모든 지오메트리들은 Transparent 큐에 그려질 것이라는 점을 기억하십시오. 즉, 유니티 UI 에 의해서 생성된 지오메트리는 항상 알파블렌딩을 사용해 뒤에서 앞 순서로 그려질 것입니다. 성능 관점에서 기억해야 할 중요한 것은, 폴리곤으로부터 래스터화된 각 픽셀은 마치 그것이 다른 불투명한 폴리곤에 의해 의해 완전히 가려져 있는 것처럼 샘플링될 것이라는 것입니다. 모바일 장치에서는, 고수준의 overdraw 는 GPU 의  fill-rate 수용량( capacity )를 급격하게 초과할 수 있습니다.

The Batch Building Process (Canvases)

배치 빌딩 절차는 Canvas 가 그것의 UI 요소들을 표현하는 메시들을 결합하고 유니티의 그래픽스 파이프라인에 보내기 위한 렌더링 커맨드들을 생성하는 절차입니다. 이 절차의 결과는 Canvas 가 갱신( dirty )되었다고 표시될 때까지 캐싱되고 재사용됩니다. 이러한 갱신은 그것을 구성하는 메시들 중의 하나가 변경될 때마다 발생합니다.

Canvas 에 의해 사용되는 메시는 Canvas 에 붙어 있는 Canvas Renderer 컴포넌트로부터 획득됩니다. 하지만 Sub-canvas 에 포함된 Canvas Renderer 에서 획득하지는 않습니다.

배치를 계산하는 것은 메시를 깊이값에 의해 정렬하고 겹치는지 혹은 머티리얼을 공유하는지 등을 검사하는 작업들을 요구합니다. 이 연산은 멀티-스레드에서 수행되기 때문에 그것의 성능은 일반적으로 CPU 아키텍쳐가 달라질 때마다 달라지며, 특히 모바일 ( 일반적으로 몇 안 되는 CPU 코어를 가진 ) SoC 와 현대 데스크탑의 ( 보통 4 개 이상의 코어를 가지고 있는 ) CPU 사이에서 큰 차이가 납니다.

The Rebuild Process ( Graphics )

리빌드 절차는 유니티 UI 의C# Graphic 컴포넌트의 레이아웃과 메시가 재계산되는 곳입니다. 이는 CanvasUpdateRegistry 클래스에 의해 수행됩니다. 이것은 C# 클래스이며, 그것의 소스는 Unity's Bitbucket 에서 찾아볼 수 있음을 기억하십시오.

CanvasUpdateRegistry 내에서, 흥미로운 메서드는 PerformUpdate 입니다. 이 메서드는 Canvas 컴포넌트가 WillRenderCanvases 이벤트를 호출할 때마다 호출됩니다. 이 이벤트는 프레임당 한 번 불립니다.

PerformUpdate 는 세 단계의 절차로 실행됩니다:

• 레이아웃을 리빌드하기 위해서 갱신된 Layout 컴포넌트들이 요청됩니다. 이는 ICanvasElement.Rebuild 메서드를 통해 수행됩니다.
• 컬링과 클리핑을 수행하기 위해서 등록된 모든 ( Mask 같은 ) Clipping 컴포넌트들이 요청됩니다. 이는 ClippingRegistry.Cull 을 통해 수행됩니다.
• 그래피컬 요소들을 리빌드하기 위해서 갱신된 Graphic 컴포넌트들이 요청됩니다.

Layout 과 Graphic 을 리빌드하기 위해, 이 절차는 여러 개의 부분으로 나뉩니다. Layout 리빌드는 세 가지 부분으로 실행됩니다( PreLayout, Layout, PostLayout ). 그리고 Graphic 리빌드는 두 가지 부분으로 실행됩니다( PreRender, LatePreRender ).

Layout rebuilds

하나 이상의 Layout 컴포넌트에 포함된 컴포넌트의 적절한 위치를 계산하기 위해서는, 그것들의 적절한 계층적 순서를 적용할 필요가 있습니다. 게임 오브젝트 계층에서 루트와 가까운 Layout 들은 잠재적으로 그것들에 내포되어 있는 다른 Layout 들의 위치와 크기를 수정할 수 있습니다. 그러므로 가장 먼저 계산되어야만 합니다.

이를 위해, 유니티 UI 는 계층 내에서의 깊이를 중심으로 갱신된 Layout 컴포넌트들을 정렬합니다. 계층 구조에서 높은 곳에 있는 아이템( 예를 들어 부모 Transform 이 거의 없는 아이템 )들은 리스트의 앞쪽으로 이동됩니다.

그리고 나서 레이아웃을 리빌드하기 위해서 Layout 컴포넌트들의 정렬된 리스트가 요청됩니다: 여기에서 Layout 컴포넌트에 의해서 제어되는 UI 요소들의 위치와 크기가 실제로 수정됩니다. 개별 요소들의 위치가 Layout 의 영향을 받는 방식에 대한 더 세부적인 내용을 원한다면, 유니티 매뉴얼의 UI Auto Layout 섹션을 참고하십시오.

Graphics rebuilds

Graphic 컴포넌트들이 리빌드될 때, 유니티 UI 는 ICanvasElement 인터페이스의 Rebuild 메서드에 대한 제어를 넘깁니다. Graphic 은 이를 구현하며, 리빌드 절차의 PreRender 스테이지 동안 두 개의 리빌드 단계를 실행합니다.

• 만약 버텍스 데이터가 갱신되었다고 표시되었다면( 예를 들어, 컴포넌트의 RectTransform 의 크기가 변했다면 ), 메시가 리빌드됩니다.
• 만약 머티리얼 데이터가 갱신되었다고 표시되었다면( 예를 들어, 컴포넌트의 머티리얼이나 텍스쳐가 변경되었다면 ), 동봉된 Canvas Renderer 의 머티리얼이 갱신됩니다.

Graphic 리빌드는 특정 순서로 처리되지는 않습니다. 그리고 어떠한 정렬 연산도 요구하지 않습니다.