Как сделать объект неактивным unity

Обновлено: 08.07.2024

Ведущий UI/UX-художник Никита Кандыбин и технический UI-художник Ольга Кинчак из студии Banzai Games написали колонку, в которой поделились базовыми практиками по оптимизации Unity UI.

Практически во всех перечисленных ниже пунктах можно обойтись без кода, настраивая компоненты непосредственно в редакторе, а что-то даже предусматривая заранее на стадии проектирования макетов интерфейса.

Нативный Unity UI или, как, его ещё называют в народе, uGUI, представляет собой довольно гибкий и удобный инструмент для создания и редактирования игровых пользовательских интерфейсов. Однако недостаток знаний, осведомленности о специфике работы и неправильное использование возможностей игрового движка рано или поздно приводит к возникновению проблем. Будь то низкая частота кадров, высокая загрузка центрального процессора, перегрев устройства и прочие страшные слова для проекта, который хочет стать (или продолжать оставаться) успешным.

Для мобильных платформ с их ограничениями по железу вопросы производительности и оптимизации становятся камнем преткновения на пути к реализации всего желаемого. Тем не менее это вовсе не повод отказываться от Unity UI — система хороша, просто нужно научиться в ней готовить.

Каждый из перечисленных этапов связан с целым ворохом потенциальных проблем с оптимизацией, которые мы и постараемся осветить далее.

В процессе отрисовки макетов пользовательского интерфейса постепенно формируется UI Kit проекта — всё разнообразие графических элементов (кнопок, панелей, фоновых изображений, арта, декора, иконок и так далее), а также правил их компоновки. В дальнейшем все эти элементы будут порезаны на ассеты, залиты в движок и станут конструктором для финальной сборки интерфейса игры. Очень важно заранее продумывать, что и в каком виде попадет в Unity и насколько ресурсоёмким станет в итоге.

Использование в UI-дизайне таких популярных методов как slicing, tiling и окрашивание является одним из наиболее эффективных и распространенных способов экономии и многократного переиспользования ресурсов проекта.

В свою очередь, окрашивание является прекрасным их дополнением. Вместо сохранения линейки разноцветных копий вы можете подкрасить всего один графический объект, чтобы получить гораздо больше вариаций. Кроме того, данный метод даёт возможность программно управлять различными цветовыми схемами, без необходимости для дизайнера менять что-либо в исходных файлах.

Комбинируя приёмы и отрисованные вами ассеты, ничто не мешает создавать сложные интерфейсные конструкции из простых, украшая их универсальными декоративными элементами и тем самым максимально эффективно используя готовые ресурсы. Однако у такого подхода есть и свои нюансы.

И в данном случае нюансами является специфика пайплайна рендеринга интерфейса в Unity и понятие overdraw. Если очень коротко, то overdraw — термин, обозначающий ситуацию, при которой один и тот же пиксель перерисовывается несколько раз (то есть выполняется лишняя работа по его заполнению).

Дело в том, что все элементы интерфейса в сцене Unity отрисовывает в Transparent по очереди, от самого дальнего к самому близкому, смешивая их цвета при прозрачности — по-умолчанию считая их прозрачными, даже если они таковыми и не являются. А это означает, что рендериться будут абсолютно все активные графические объекты в иерархии, независимо от того, загораживаются ли они визуально другими или нет. При этом большое количество перекрывающихся элементов может привести к чрезвычайному высокому количеству перерисовок пикселей, цвета которых нужно смешать, снижению скорости их заполнения (fill rate) и, как следствие, возникновению проблем с производительностью.

В нижнем варианте реализации у кнопки FIGHT тень, подложка и рамка слиты в одну текстуру, в отличие от верхнего, где каждый из этих слоев — самостоятельный спрайт. Идентичный визуальный результат — разный Overdraw

Поэтому в процессе создания дизайна интерфейса важно понимать и помнить, что для решения проблем с overdraw пока что лучшим выходом является создание ассетов, которые объединяют в себе как можно больше декоративных элементов в одной текстуре. Важно уметь балансировать в своих визуальных решениях. Ведь недостатком таких объединенных текстур может стать полная инвариантность их применения и увеличение размера текстурных атласов проекта.

Всё это многообразие графических элементов, из которых состоит интерфейс игры, движку нужно каким-то образом собрать и передать графическому процессору. Чтобы отрисовать объект в сцене, вызывается метод отрисовки draw call и данные о нём передаются GPU. Чем больше отправляется таких вот вызовов за один кадр, тем больше времени занимает процесс рендеринга картинки, что ведёт к риску уменьшения частоты кадров (FPS).

Однако и тут есть свои моменты. Как уже упоминалось ранее, объекты в кадре отрисовываются от самых дальних к самым близким, то есть от верхних к нижним в иерархии сцены. Если Rect Transform одного графического объекта хоть немного пересечётся с другим, оба будут считаться накладывающимися друг на друга. При этом если в сцене между объектами, которые могли бы влезть в один draw call, ненароком вклинится объект с другим материалом, то он прервёт объединение.

Так, например, текст является одной из основных причин дополнительных вызовов отрисовки, так как имеет отличный от любой другой графики материал и всегда будет беспощадно прерывать батчинг. Более того, размеры текстовых мешей и контейнеров зачастую занимают намного большую площадь, чем само начертание символов, что очень легко упустить из виду. Поэтому крайне важно следить за порядком отрисовки разношерстных объектов, их наслоением и иерархией внутри элементов в сцене.

Отрисовка кадра. Объекты на экране появляются последовательно по иерархии, но неравномерно в связи с использованием разных материалов и прерыванием батчинга

К преимуществам в использовании текстурных атласов можно отнести и то, что они позволят движку сжимать ассеты произвольных размеров, тем самым уменьшая их общий вес при хранении в памяти. Дело в том, что большинство алгоритмов сжатия требуют, чтобы размер текстур был кратен степени двойки (например, 128x128, 256x256, 512x512 и так далее). Атласы, являющиеся по-умолчанию таковыми, берут все вопросы по сжатию на себя, исключая необходимость подгонять всю исходную графику вашего интерфейса под вышеуказанный критерий.

Unity предлагает нам два по-разному работающих компонента из коробки на выбор: Mask и Rect Mask 2D. При использовании любого из них графика, вылезающая за пределы маски, всё равно будет влиять на общий fill rate, хоть она и не отображается на экране. Поэтому старайтесь избегать ситуаций, в которых для достижения желаемого результата маской будет вырезан лишь небольшой участок крупного графического объекта. Возможно, в каких-то местах лучше не скупиться на ассеты и сохранить этот кусочек в виде отдельной картинки.

Ещё одним ограничением нативных масок является их неумение работать с плавным изменением альфа-канала. К сожалению, на данный момент ни один из вышеуказанных компонентов не позволяет добиться эффекта софт-маски (soft mask), поддерживающей градиенты и полупрозрачности. За желаемым результатом придётся обратиться к сторонним решениям или попробовать реализовать их самим.

В Asset Store можно найти плагины, добавляющие функции софт-маски в редактор. Имея под рукой такой инструмент, ему сразу же находится повсеместное применение в дизайне — скроллы, анимации, визуальные эффекты, декор и так далее.

Однако не стоит сильно обольщаться. Использование софт масок - хоть и приятная глазу, но довольно тяжелая фича, особенно для мобильных устройств. Так, например, открытие большого списка UI-элементов под такой маской на весь экран с красивыми мягкими краями как минимум гарантированно вызовет неприятный фриз игры. В подобной ситуации решением для нашей команды оказалось минимизировать использование софт-масок (там, где это нужно), искать обходные пути в виде перекрывающих градиентов (там, где это возможно) или разнести добавление элементов в список на несколько кадров, чтобы размазать просадку производительности от инициализации софт-маски.

Под каждый текстовый символ нативный UI Text создает отдельный квад (quad), а значит вполне закономерно, что чем больше в интерфейсе текста — тем больше геометрии в сцене. При этом при внесении любых изменений в текстовые значения, повторном включении его компонентов или родительского объекта вся эта геометрия будет перестраиваться.

По умолчанию все шрифты, которые добавляются в Unity, отмечаются как динамические. При всём удобстве их использование имеет свою цену. Атлас динамического шрифта генерируется в рантайме и заполняется только используемыми на данный момент в текстовых компонентах сцены символами. Для каждого шрифта создается свой атлас, учитывающий все встречающиеся в сцене размеры текстовых символов. Каждое появление нового символа в интерфейсе инициирует обновление и перестройку атласа шрифта, что порой может негативно сказаться на производительности.

Более того, если в текущем атласе уже нет свободного места для новых текстовых глифов, Unity пересобирает его заново, удаляя не использующиеся в данный момент символы. А если и это не помогает, то увеличивает его размер.

Если в игре не используется огромное количество символов, а их набор заранее предопределён, то вместо динамических шрифтов намного лучше использовать статические. В настройках шрифта в редакторе можно заранее сгенерировать атлас, который будет содержать только необходимые проекту символы и не будет изменяться динамически, минуя все упомянутые в предыдущем абзаце издержки.

Отдельного упоминания заслуживает функция Best Fit, позволяющая автоматически изменять размер шрифта, если текст не помещается в свой Rect Transform. Сами сотрудники Unity в официальных туториалах вспоминают её с ужасом и не рекомендуют использовать — настолько всё плохо, не оптимизировано и быстро перегружает шрифтовый атлас. Старайтесь заранее предусматривать максимально возможные размеры текстовых контейнеров и следить за тем, чтобы всё везде помещалось, оставляя запас на все происки локализации.

Альтернативой UI Text может быть сторонний TextMesh Pro, который использует только статичные шрифты, да и его Best Fit работает гораздо лучше и экономнее. Однако минусом работы с данным компонентом может быть то, что под каждую локализацию и текстовый стиль придется создавать свой отдельный набор ассетов шрифтов. Тут уж каждый решает сам, что ему ближе и как удобней.

Размытие картинки (блюр) уже много лет как любят и используют в своей работе дизайнеры пользовательских интерфейсов, но в Unity UI его готовой оптимизированной реализации попросту нет.

Layout-группы (Layout Groups) — крайне удобный инструмент в Unity UI, помогающий автоматически располагать произвольное количество элементов с заданой ориентацией, выравниванием и отступами. Однако использовать его нужно с осторожностью.

Сортировка, поиск групп и расчёт положений элементов при перерисовке атласа — довольно затратное дело, особенно если в сцене есть layout-группы, и тем более если они оказываются вложены друг в друга. Старайтесь всюду, где это возможно, обходится грамотным использованием анкоров и пивотов трансформа UI-элементов, предпочитая их layout-группам.

Если оставлять включенной галку только тем объектам, которым это действительно логически необходимо (например, кнопкам), можно значительно сократить список для обхода и сортировки, тем самым ускорив полезную работу движка.

И layout-группы, и Graphic Raycaster в процессе работы непрерывно путешествуют по дереву иерархии сцены, от находящихся глубоко дочерних элементов к самому корню, в процессе поиска различных компонентов.

Суть оптимизации данного процесса заключается в том, чтобы стараться этот путь сокращать — держать иерархию максимально плоской, избегая вложений, когда без них можно обойтись. Создавать объекты-папки для менеджмента других элементов интерфейса возможно и более удобно для восприятия, но злоупотреблять ими всё-таки не стоит, чтобы не усложнять структуру иерархии.

В самом начале статьи мы уже выяснили, что канвас стремится перестраиваться на любой чих от своих дочерних объектов. Чтобы в этом процессе не участвовали вообще все элементы интерфейса, некоторые из них можно вынести в суб-канвас (sub-canvas). Такой канвас будет перестраиваться самостоятельно, независимо от других, тем самым никак их не загрязняя. Лучший способ использовать это состоит в том, чтобы отсортировать элементы пользовательского интерфейса на статические и динамические. Например, если у вас есть окно инвентаря со скроллом предметов, вынесенное в отдельный канвас, скролл будет перестраиваться самостоятельно, не тревожа лишний раз статичные элементы фона.

В наших проектах в отдельный канвас выносятся только элементы для фонового изображения, которое является общим для большинства экранов в интерфейсе игры и чаще всего статично.

И вот мы все это учли, провели работу над ошибками и получили более-менее оптимизированный статичный интерфейс. Пришло время добавить ему движения, но и тут можно с легкостью наломать дров.

— узнаём о единице измерения расстояний в Unity – 1 unit (юнит), который обычно сопоставляют с 1 метром в реальной действительности.

— обратили внимание на координатную сетку, которой размечена сцена в редакторе Unity

— научились лучше ориентироваться в расстояниях на редактируемой сцене

— добавляем к пустому объекту (Empty Object) на сцене компоненты Mesh Renderer и Mesh Filter, которые отвечают за отображение (отрисовку, Renderer) объекта на сцене в заданной форме (Filter). Делаем это двумя способами: а) нажимая на кнопку Add Component окна Inspector и б) используя пункт меню Component из главного меню. Второй способ иногда удобнее, т.к. там компоненты более аккуратно сгруппированы. Первый способ позволяет быстрее добавлять компоненты, используя их поиск по названиям. Но в этом случае надо знать название требуемого компонента хотя бы примерно.

— создаём 3D-объект Sphere (сфера) и убеждаемся в том, что у неё такой же набор основных компонентов, как и у пустого объекта, из которого ранее делали объект-капсулу, вручную добавляя к нему необходимые компоненты.

— узнаём, как выключить на сцене освещение, которое включено по умолчанию на каждой сцене

— учимся отключать компоненты объекта

— учимся удалять компоненты объекта с помощью пункта Remove Component контекстного меню компонента в окне Inspector (вызывается либо кликом мыши на многоточии или шестеренке в правом верхнем углу заголовка компонента, либо кликом правой кнопки мыши по заголовку компонента).

— рассматриваем в качестве примера объекты Main Camera и Directional Light, которые создаются редактором автоматически при создании новой сцены. Изучаем наборы их компонентов и выделяем те, которые содержат ключевые свойства этих объектов. Это компонент Camera и компонент Light, соответственно.

Цикл уроков создан при поддержке компании Melsoft games.

Я создаю 3D-игру в лабиринте 1-го лица в Unity. Цель игры - добраться до другой стороны лабиринта до времени. Чтобы сделать игру забавной, на каждом раунде игрок начинает карту лабиринта случайным образом генерирует стены, поэтому каждый лабиринт уникален, поэтому игрок не может запомнить путь. Я решил, что мне нужно сделать сетку таких стен.

(Представьте, что линии - это стены, каждый сегмент - отдельный объект стены)

Когда игрок начинает, каждый сегмент стены будет иметь шанс исчезнуть, так что представьте, что эта сетка превратится в нечто подобное.

Привет! У меня нашлась свободная минутка, так что я подумал, что пришло время поделиться своим опытом построения интерфейсов в Unity. Поэтому, кому интересна эта тема — прошу под кат.

Сразу хочу предупредить, что все, описанное в этой статье — это мой собственный опыт, поэтому, если вам известны более оптимальные способы решения упомянутых задач, то я буду рад, если вы поделитесь им в комментариях.

Содержание

Игровые интерфейсы

В общем, UI в играх является полностью функциональным элементом, который только опосредованно влияет на геймплей. Его главная задача — донести до игрока необходимую информацию. В принципе, можно взять тот же Arial и отобразить им количество здоровья, патронов и счет (если речь идет о шутере). Да, это повлияет на эстетическую составляющую, а у особенно впечатлительных игроков может пойти кровь из глаз, но со своей задачей разработчик в таком случае справился: донес информацию до игрока.

Но это радикальные методы. Понятно, что самый лучший интерфейс — это тот, который игрок не замечает вплоть до момента, когда он ему понадобиться. И количество патронов на самом оружии, и уровень жизни, который отображается прямо на протагонисте (привет, Dead Space!) — все это на совести геймдизайнера. Мы же, как разработчики, должны воплощать эти прихоти в жизнь. Какие же возможности для создания интерфейсов есть в Unity?

Что такое Canvas?

Canvas для Unity UI — это область, внутри которой размещаются все элементы пользовательского интерфейса. То есть, когда мы создаем новый игровой объект, то Сanvas для него создается автоматически.

Начиная с версии 4.6, для работы с элементами пользовательского интерфейса используется новая версия Unity UI. Как и во время работы с обычными объектами, элементы HUD организовывают в иерархии, корневым элементом которых является объект с компонентом Canvas. При этом порядок в иерархии определяет порядок рендера: объекты, которые находятся в самом низу, отрисовываются последними и, соответственно, располагаются поверх остальных объектов.

Не имеет значения, какой тип приложения вы разрабатываете — как 3d, так и 2d игры используют одну и ту же логику работы с UI. То же самое касается платформы. Не имеет значение, это Web с HTML5 или игра для Android — достаточно будет описать одно полотно Canvas.

Варианты отображения Canvas

За то, где именно будет отображаться Unity UI Canvas (в пространстве экрана или игрового мира) отвечает параметр Render Mode, у которого есть три режима:

Размещение элементов в Canvas

Для удобства проектирования каждый элемент UI отображается в виде прямоугольника. Для манипуляций с ними используется два главных компонента, Rect Tool и Rect Transform. Последний — это новый компонент, у которого кроме уже указанных полей есть особенное поле Anchors (Якоря).

Якоря определяют привязку элементов к размерам родительского элемента. У компонента есть 4 якоря, каждый из которых отвечает за одну из вершин элемента. Позиция и размеры элемента высчитываются на основе расстояния между вершиной и якорем, и позицией самого якоря. Позиция якоря, в свою очередь, определяется в процентном отношении от размеров родительского элемента. Таким образом, если все четыре элемента находятся в одном и том же месте, размер элемента будет постоянным. Если в одной точке находятся якоря одной плоскости (верхний и нижний или левый и правый), то элемент не будет растягиваться относительно этой оси. Если же якоря не находятся в одной точке, то позиция каждого якоря будет рассчитана в процентах и к полученной величине будет добавлено расстояние к вершине (она не изменяется).

Звучит сложно, не так ли? Но если провести 10 минут в редакторе, то все сразу станет на свои места.

Следует также сказать, что кроме якорей у Rect Transform есть также параметры Min, Preferred и Flexible Width и Height, которые можно переопределить с помощью компонента Layout Element, но обычно я его не использую.

Кстати, новая версия Unity UI Canvas позволяет использовать несколько приятных особенностей. Одна из них — это возможность полностью отключить весь UI для упрощения работы с самой сценой. За это отвечает пункт Layer в меню редактора.

Сперва кажется, что функционала, который предоставляет вышеупомянутый компонент Rect Transform, должно хватать для всех возможных задач. Однако недавно, создавая кастомный селектор для Facebook, я столкнулся с необходимостью группировать элементы определенным образом.

При разработке под мобильные устройства (если вы разрабатываете не только под iOS) девелопер сталкивается с проблемой сегментированности, когда его игры могут запускать как на телефоне с 2-дюймовым экраном, так и на устройстве с диагональю 9 дюймов. И это я еще молчу про планшеты. Что делать в такой ситуации? У нас есть несколько вариантов.

Разработка под экраны любых размеров

Почему бы не использовать Anchors?

Первое, что приходит в голову — использовать якоря. Да, если у вас простые экраны без большого количества дочерних элементов, анимаций и остальных фич для пользователей, то почему бы и нет? Но, если вы используете такой тип верстки, следует помнить, что происходит изменение размера, а не визуальное растягивание (скейл) элементов. Поэтому в текстовых компонентах параметр Best fit становится активным, а во всех элементах появляется необходимость контролировать соотношение сторон и привязку к определенным частям экрана или другим элементам. Лично я так и начинал верстать — и решение нашлось (хотя оно и не очень элегантно, но зато работает).

В пакете UI есть компонент Aspect Ratio Fitter. Он работает достаточно просто: в зависимости от типа и изменений в размерах родительского элемента, данный компонент меняет размеры собственного Game Object, сохраняя соотношения сторон.

Преимущества использования Canvas Scaler

Сейчас я использую Canvas Scaler, ведь в таком случае компонент добавляется автоматически во время создания Canvas. Преимущество по сравнению с предыдущим подходом состоит в том, что все дочерние элементы растягиваются, а не просто изменяют свой размер, а значит, сохранится размер шрифта во всех текстах, а элементы со смещением в несколько юнитов будут выглядеть одинаково на всех экранах.

У Canvas Scaler есть три режима работы:

Constant Pixel Size — Game Object сохраняет свой размер в пикселях, игнорируя размеры экрана.
Constant Physical Size — Game Object сохраняет свои физические размеры, игнорируя размеры экрана и его разрешение.
Scale With Screen Size — Game Object растягивается вместе с экраном.

Последний элемент — мой любимый, поскольку позволяет не обращать много внимания на фрагментацию экранов, выбрав свое целевое разрешение, после чего Canvas оптимальным способом изменит собственные размеры. Поэтому предлагаю рассмотреть его подробнее.

Как я уже упоминал, у этого режима есть свое целевое разрешение, в соответствии с которым Screen Match Mode будет изменять текущее полотно Canvas. Сам Match mode может принадлежать к одному из следующих типов:

Match Width Or Height — растягивает область Canvas в зависимости от соотношения ширины и/или высоты к реальным на устройстве.
Expand — растягивает область Canvas таким образом, чтобы помещалась большая сторона (размер Canvas никогда не будет меньше указанного).
Shrink — растягивает область Canvas таким образом, чтобы помещалась меньшая сторона (размер Canvas никогда не будет больше указанного).

И хотя у каждого из режимов есть свои преимущества, но все же моим фаворитом остается Match Width Or Height. У этого режима есть еще одна полезная особенность — для него можно указать, какая из осей будет целевой, и с какой осью будет осуществляться сравнение (вся область Canvas будет увеличиваться в зависимости от ширины, высоты или обоих этих показателей).

Для этого используется параметр Match, в котором через переменную float [0;1] задается соотношение влияния сторон. Таким образом, 0 — изменения будут подгоняться по ширине, а 1 — по высоте. Если целевое соотношение сторон находится в горизонтальной ориентации, то когда Match = 0, мы получаем эффект Expand, а когда Match = 1 — Shrink (в вертикальной ориентации все будет наоборот, 0 будет давать Shrink, 1 — Expand).

Последний параметр Canvas Scaler — это Reference Pixels per Unit, который определяет, сколько пикселей будет в одном юните UI-элемента. Его значение по умолчанию равно 100 метрам. Он работает с Image-компонента, поэтому если у вас каждый метр — это 100 пикселей изображения и вы используете физику Unity, то вам подойдет это значение.

Создание кастомного селектора

Как видим, некоторые компоненты мы уже рассмотрели. Поэтому давайте по очереди знакомиться с теми, про которые мы еще ничего не знаем.

Canvas Group

Этот компонент легко и просто настраивать, но, тем не менее, он очень действенный. Позволяет оперировать свойствами всех дочерних элементов объекта. Полезен, когда требуется сделать определенную панель неактивной или запретить реагировать на взаимодействие с пользователем (через Raycast).

Для лучшего понимания достаточно будет создать 2 одинаковые панели с несколькими кнопками и чекбоксами, одна из которых будет содержать этот компонент, и просто поменять значения параметров.

И наконец-то самое интересное.

HorizontalLayoutGroup и VerticalLayoutGroup

Два компонента размещают все дочерние компоненты горизонтально или вертикально друг за другом. Можно задать как отступы внутри корневого элемента, так и между дочерними элементами (padding и spacing). Кроме того, объекты можно отцентрировать относительно краев родительского элемента.

Учитывая то, что элементы будут находиться только в одной плоскости (горизонтальной или вертикальной), последний параметр, который состоит из двух чек-боксов, позволят растянуть все дочерние элементы до размеров родительского по высоте или ширине.

GridLayoutGroup

Если вам нужно создать таблицу из однотипных элементов, то это просто дар богов! Как и у предыдущих элементов, у него есть поля padding и spacing, но при этом дальше нам требуется задать размеры дочернего элемента, в соответствие с которыми будут приводиться все объекты, добавленные к родительскому.

Дальше следует задать StartCorner, который будет определять позицию первого элемента, и StartAxis, который будет указывать на ось заполнения (по строкам или столбцам). Так, если выбрано Vertical, то элементы будут заполнять текущий столбец до тех пор, пока не достигнут границ родительского элемента, а затем перейдут на новый. С Horizontal все происходит наоборот — заполнение будет происходить по строкам. Задав, как и откуда добавлять элементы, логично будет указать их выравнивание.

Последний параметр — это Constraint, который определяет, будет ли у данной разметки определенное количество столбцов или строк или же этот показатель будет высчитываться, исходя и размеров родительского элемента. Стоит помнить, что в отличие от остальных компонентов разметки, GroupLayout переопределяет размеры дочерних элементов на Cell Size (его не интересуют показатели Min, Preferred и Flexible sizes).

Кроме того, существует возможность комбинировать GridLayoutGroup с ContantSizeFitter, однако у меня такой необходимости не было. Судя по официальной документации, с этим не должно возникать проблем.

Вот как выглядел конечный результат в моем случае:

Каждый элемент добавлялся динамически, инициализируясь из префаба элемента. Как видим, изменить размеры или позицию элемента мы не можем, поскольку эти значения определяются в GridLayoutGroup.

Кстати, элемент был сверстан отдельно от панели, которая должна была удерживать этот объект и дальше. Все, что от меня требовалось — скопировать размеры элемента в CellSize компонента GroupLayout. А вот хардово забить размеры элемента я смог с помощью CanvasScaler, которому задал тип растягивания Match Width Or Height.

Вот и все, что касается возможностей нового UI. Эта статья — попытка систематизировать для себя полученный опыт, но если она пригодится и вам, то я буду искренне рад.

So Long, and Thanks for All the Fish.

Нужен MVP, разработка под iOS, Android или прототип приложения? Ознакомьтесь с нашим портфолио и сделайте заказ уже сегодня!

Читайте также: