Рубрика развивается при поддержке

Оптимизация Unity UI без кода Материал редакции

Базовые приёмы для пользовательского интерфейса.

В закладки
Аудио

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

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

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

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

Особенности Canvas

Для начала разберёмся немного в том, каким образом организован Unity UI. Менеджментом всего, что связано с отрисовкой пользовательского интерфейса в Unity, занимается Canvas (далее просто «канвас»), являющийся родительским объектом для всех дочерних элементов интерфейса в иерархии сцены.

Любое изменение элементов в канвасе, будь то цвет, размер, позиция, материал, текст, активное состояние и так далее помечает эти объекты как «грязные» (dirty), заставляя канвас их перерисовывать. Данный процесс включает в себя анализ изменений, перестроение канваса и его дальнейшее кэширование до тех пор, пока хотя бы один из дочерних элементов не будет вновь помечен как «грязный».

Перестроение происходит в несколько этапов: расчёт положений объектов в лэйаутах, анализ оптимальных способов их отрисовки, применение масок и пересчёт графики «грязных» объектов. Канвас формирует команды для рендера, которые движок Unity отправляет на GPU и, в конечном счете, визуализирует.

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

UI Kit на все случаи жизни

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

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

Так, например, slicing и tiling позволяют хранить исходную графику в размере намного меньшем, чем могут оказаться созданные с её помощью элементы интерфейса. У объектов сохраняется постоянство формы и при грамотной реализации отсутствуют какие-либо видимые артефакты. Эти приемы особенно полезны при адаптивной вёрстке в «зоопарке» мобильных устройств, когда при изменении пропорций экрана интерфейс должен эстетично растягиваться или сужаться.

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

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

Overdraw

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

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

C помощью одноименного режима отображения «Overdraw» в редакторе Unity можно довольно удобно отслеживать такие вот узкие места и буквально видеть перерисовку в сцене. Пусть такая оптимизация на первый взгляд кажется довольно незначительной, но когда объектов на экране становится много (а в сложных интерфейсах их очень много) и все они начинают наслаиваться, даже такие мелочи могут дать существенный прирост к производительности.

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

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

Draw сalls и использование атласов

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

Один из наиболее эффективных способов снизить количество вызовов метода отрисовки заключается в использовании текстурных атласов — упаковки ваших текстур в единую, более крупную. Дело в том, что Unity старается автоматически объединять («батчить») графику в один draw call, отвечающую определённым критериям, тем самым ускоряя отрисовку кадра.

В нашем случае наиболее важным здесь является то, что «сбатчиться» смогут только те объекты, которые используют одинаковые материалы и общий компонент рендерера (Canvas Renderer — дефолтный рендерер для всей UI-графики). Таким образом, если элементы интерфейса в сцене используют стандартный UI-материал, то, объединив их графику в один общий текстурный атлас, мы сможем получить тот самый желанный один draw call на рендеринг всей группы.

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

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

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

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

Также при создании атласов очень важно руководствоваться не просто желанием удобно «складировать» ассеты, но делать это грамотно, эффективно, учитывая логику появления тех или иных элементов в интерфейсе вашей игры. Даже если на экране изображена всего одна малюсенькая иконочка размером в 16x16 пикселей, упакованная в атлас, в память устройства она потянет за собой всю его текстуру в 4К. Ещё на этапе дизайна возможно прикинуть, какие элементы станут уникальными и для каких экранов, а какие будут сквозным конструктором для интерфейса игры.

Использование масок

Маски — часто применяемый в дизайне пользовательских интерфейсов инструмент. Однако при его использовании очень важно учитывать влияние масок как на overdraw, так и на «батчинг».

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

Что же касается влияния на draw calls, то здесь наши компоненты разнятся. Обе маски прерывают «батчинг» между замаскированными объектами и их не замаскированными соседями, но по разным причинам. Mask использует stencil-буфер (буфер шаблона), создавая в рантайме другой материал для всех своих дочерних объектов. Из-за этого материала они не станут «батчиться» с другими элементами в сцене, но все еще смогут «сбатчиться» друг с другом и даже с другими такими же замаскированными объектами под другой Mask.

Rect Mask 2D материал не меняет, stencil не использует и дополнительный overdraw от графики маски не добавляет, что делает её в сравнении более производительной. Тем не менее использование данного компонента всё равно рвет «батчинг», причём, в отличие от Mask, элементы интерфейса под разными Rect Mask 2D друг с другом батчиться уже не будут.

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

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

​Все три варианта маскируют картинку, используя один общий исходный спрайт

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

Работа с текстом

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

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

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

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

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

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

Блюр

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

Большое количество реалтайм блюра, позволяющего оставаться картинке динамичной, в Unity — гарантированный способ убить производительность в мобильной игре. Гораздо легче переносится его статичная версия — создаётся скриншот экрана, размывается в необходимое количество проходов и используется в дальнейшем как текстура. Существует множество сторонних ассетов, позволяющих реализовать оба подхода. Однако если использование реалтайм блюра для интерфейса всё-таки оправдано и критично, постарайтесь тщательно следить хотя бы за тем, чтобы материалы блюра «батчились» вместе, если на экране есть несколько участков с размытием.

Layout-группы

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

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

Raycast Target

Галка «Raycast Target» на графических компонентах UI-элементов означает, что последние могут отлавливать клики от пользовательской мыши или тапы на сенсорных экранах. Свежесозданному объекту с компонентами Image или Text редактор ставит эту галку по-умолчанию. Для того, чтобы определить, какой объект поймал «тычок» от пользователя, graphic raycaster, обрабатывающий события ввода в Unity UI, проходится по всему списку элементов в иерархии, помеченных как raycast target, и сортирует их очередность, рассчитывая пересечения и перекрытия одних объектов другими.

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

Иерархия: чем проще — тем проще

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

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

Разделение канвасов

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

Казалось бы, вот оно — решение всех проблемы с ненужными перестроениями. Но у всего есть свои «но». Контролировать большое количество канвасов может стать банально неудобно. Также очень важно помнить, что элементы, принадлежащие разным канвасам, гарантированно не будут батчиться друг с другом. Поэтому, принимая структурные решения, разделением элементов интерфейса на разные канвасы лучше пользоваться осторожно и обязательно проверять в профилировщике (Profiler), действительно ли такой подход может дать заметный прирост к производительности.

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

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

Particle System

Тот, кто когда-нибудь пытался добавить в интерфейс системы частиц (Particle System), прекрасно знает, что это как смешивать жидкости разной плотности — одна обязательно будет отображаться над другой, как ты не крутись.

Стандартные частицы в Unity не учитывают сортировку объектов в канвасе и не умеют работать с масками. Поэтому на помощь опять приходят сторонние компоненты из Asset Store, которые решают вышеперечисленные вопросы, но при этом зачастую увеличивают ресурсную стоимость системы частиц. Следовательно, требования по производительности к частицам в пользовательском интерфейсе куда-более строгие, чем, скажем, на локациях или для персонажей. Кроме того, большое количество крупных наслаивающихся друг на друга частиц может значительно повысить overdraw.

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

Анимация

Рассмотрим частую ситуацию. Необходимо заанимировать кнопку и все её стейты — Unity любезно предлагает нам Animation Controller (далее просто «аниматор») с базовым суповым набором анимаций для разных состояний, которые останется только отредактировать, да еще и без необходимости запуска рантайма для проверки результата. Удобно? Очень удобно. И снова коварная дефолтная ловушка. Ведь каждый кадр аниматор будет перерисовывать этот объект, помечая как грязный, даже если на экране в данный момент вообще не проигрывается никакая анимация.

Потому для случаев, когда анимируемые элементы интерфейса визуально большую часть времени остаются статичны, нативный аниматор лучше не использовать. Заменой ему в данном вопросе может послужить система tween-анимаций. Например, использование распространяемого бесплатно плагина DOTween. Однако за увеличение производительности придется заплатить необходимостью писать анимации в виде скриптов уже без удобного наглядного таймлайна, как у аниматора из коробки Unity.

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

Пока не разошлись

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

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

Не нужно сразу ужиматься и делать высоко оптимизированный серый квадрат на сером фоне, отказывая игре во «вкусном» интерфейсе. Тем не менее, каждый раз копая глубже, у вас появляется возможность избежать всё большего количества проблем ещё на старте. Ситуации варьируются от проекта к проекту, от цели к цели, но общие принципы всегда остаются прежними.

Ребята в Unity, конечно, тоже не сидят сложа руки. Официальные гайды на Unity Learn пополняются хорошими статьями про оптимизацию UI, а новые версии движка потихоньку, но исправляют проблемы старых. Судя по последним анонсам, Unity уже готовят абсолютно новый унифицированный инструмент для редактирования пользовательских интерфейсов - на первый взгляд, очень уж напоминающий CSS для web-разработки. В новой системе обещают полностью переработать отрисовку интерфейса и значительно улучшить производительность. Что ж, посмотрим, что в итоге получится. А пока работаем с тем, что имеем.

Почитать, посмотреть и послушать

Вы думаете я тут значит паши а вы там клубничку приедите с молочком поедите?
{ "author_name": "Андрей Верещагин", "author_type": "editor", "tags": ["\u043e\u043f\u044b\u0442","\u0438\u043d\u0442\u0435\u0440\u0444\u0435\u0439\u0441","unity"], "comments": 64, "likes": 178, "favorites": 575, "is_advertisement": false, "subsite_label": "gamedev", "id": 84298, "is_wide": true, "is_ugc": false, "date": "Thu, 28 Nov 2019 11:09:30 +0300", "is_special": false }
Разработка игр для PC, консолей
и мобильных платформ
Я готов!
0
64 комментария
Популярные
По порядку
Написать комментарий...
14

- "сторонний TextMesh Pro" уже давно является частью Unity и встроен в него. Крайне рекомендую использовать TMP вместо кошмарного и кривого базового UnityEngine.UI.Text
- для частиц в UI можно использовать этот плагин: https://github.com/mob-sakai/ParticleEffectForUGUI
- квадратные текстуры типа 128x128, 256x256, 512x512 требует только pvr. Для etc можно делать прямоугольные, не забывая всё же про степень двойки, типа 2048x512
- ну и прекрасный набор различных расширений для UI можно найти тут: https://bitbucket.org/UnityUIExtensions/unity-ui-extensions/src/master/

Ответить
5

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

Вот тут не совсем доходчиво описана проблема. Нюанс в том, что Animator помечает UI объект как изменённый даже когда никакой анимации на объекте на самом деле не происходит

Ответить
4

Эм ...

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

Ответить
2

Тьфу, несколько раз перечитал, предыдущее предложение пока вникал, а это пропустил /=

Ответить
2

Бывает )

Ответить
5

Для тех, кто хочет сейчас углубиться в изучение работы системы unity UI, сейчас, вероятно, более актуальным будет изучение UIElements. Конечно в старых проектах uGUI остаётся, но они сейчас очень активно продвигают новую ui систему как более удобную и оптимизированную

Ответить
1

в вашем ответе ссылка, которая никуда не ведёт, а точнее ведёт в никуда (404)

Ответить
2

А в этом изюминка Юнити: вегда актуально изучать инструментарий, по которому нет никакой документации. :)
https://docs.unity3d.com/Manual/UIToolkits.html

Ответить
0

В данном случае это изюминка dtf :)

Ответить
0

Это вы ещё со Spark AR не работали от Facebook; Вот где действительно нефига документации нет.

Ответить
0

Это парсер сайта добавил ссылку, её там и не должно было быть
Проверочка
Unity unity
Точно, так и есть
UPD: а после редактирования ссылка пропала. @Сломалось 

Ответить
0

На самом интересном месте- и без ссылки(

Ответить
0

А, что? не было никакой ссылки)

по uielements самая полная инфа сейчас на записях докладов с последнего unite, если что

Ответить
0

Как бы юнити по старой доброй традиции не забили болт на новую технологию. А их подобие CSS и XML выглядит очень вкусным и интересным решением :)

Ответить
4

Как можно быть UX-художником? 

Я могу понять может что подразумевают под UI-художником. У нас это банально называется «иллюстратор-артист». Который как раз занимается колхозом и более глубоким уровнем стилизации дизайна. Ну, т.е. добавляет более сложную графику, иллюстрации, стили и «брендирует». 

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

А как можно быть художником по UX - я вообще не понимаю. 

Я не докапываюсь, прост спрашиваю. Может я чего не понимаю. 

Ответить
2

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

Ответить
1

Вот кстате вы мне немного разъяснили, спасибо. Наверно реально легче таким образом обращаться к людям. Пусть и немного оксюморон, но все же записывающий, что от тебя нужен и дизайн, и арт.

Ну, хоть все-равно считаю словосочетание некорректным, но теперь понимаю, зачем некоторые так называют профу. Спасибо ;)

Ответить
0

UX как минимум рисуют прототипы и могут в анимации, помимо основной деятельности. Обычно их называют UI/UX специалистами, а не художниками.

Ответить
0

Там рисунок такой... Шейпы прямоугольные расставлять. Это же не изобразительное искусство, а схематично.

Обычно их называют UI/UX специалистами, а не художниками.

Йеп, именно.

Ответить
1

Спасибо за статью!

Вопрос: как понять, что пора вплотную заняться оптимизацией интерфейса? На какие параметры ориентироваться при профайлинге?

Ответить
6

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

Ответить
0

Да, но как нащупать грань между "да вроде еще норм" и "неприлично долго"?

После какого количества дроу коллов на экран  (или какой загрузки CPU интерфейсными элементами, или на какие параметры еще ориентируешься) лично ты понимаешь, что вот тут лимит превышен и с этим надо что-то делать?

Ответить
2

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

Ответить
3

Открываем вкладку Stats параметр SetPass calls если коротко он обозначает что 2д графика ебёт игру, чем выше параметр тем экстримальней секс.

К 2д графике относятся как текстуры на 3д объектах так и 2д в юи, поэтому удаляем со сцены всё 3д оставляя только юи и смотрим параметр, если он всё еще зашкаливает значит пора в оптимизацию, для 2д игры на мобилку должно быть около 20-30(для 2д игры целиком). В целом чем меньше, тем лучше.

Ответить
1

Про анимации, например кнопок и вообще любых штук, где анимации разовые/периодические. Что можете сказать про применение старого компонента Animation, который триггерить уже из кода?
То есть у нас останется удобство создания анимации в редакторе, но процесс жизни анимации мы контролируем из кода. Например можно в анимации повесить и триггеры завершения, после которых из кода тупо вырубим весь компонент до лучших времен, что по идее убирает лишние пометки загрязнения.

Ответить
1

Можно кодом сделать и анимацию в таком случае например через карутину смену кадров. Всё зависит от нужды и обстоятельств.

Ответить
0

Сейчас пришла в голову мысль, что можно также попробовать контролить Speed у стейта и при выставлении в 0 это, возможно, не будет вызывать перерисовку. Надо будет потестить

Ответить
1

все равно будет перерисовывать, даже со speed 0, даже без клипа в стейте

Ответить
0

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

Ответить
0

Разве изменение цвета (по сути - изменение вертексных цветов меша элемента интерфейса) пачкает весь канвас?

Ответить
3

Да, в исходниках видно

public virtual Color color { get { return m_Color; } set { if (SetPropertyUtility.SetColor(ref m_Color, value)) SetVerticesDirty(); } }

Ответить
0

Теперь уже и не вспомню, где я узнал что якобы не пачкает. Может я перепутал с тем, что смена вертексного цвета не ломает батчинг?

Ответить
3

Да, батчинг оно не ломает.

Ответить
0

С булки привет!)

Ответить
0

Привет!

Ответить

Комментарий удален

1

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

Ответить
1

норм статья

Ответить
1

хорошая статья, доходчиво и по делу )

Ответить
1

Основы, но всё равно спасибо за статью

Ответить
1

На счет анимации UI, которую приходится делать кодом - это ужасно. 
Ввиду этого делал плагин TSS с анимацией (не только UI, еще можно анимировать материалы, сплайны и т.д.) все настраивается в редакторе и есть простой GUI менеджмент. 
https://github.com/ObelardO/TSS

Ответить
0

А они разве старый ui не деприкейтнули после 2019.1 и UIElements?

Ответить
1

Нет, UIElements должен быть в 2019.3 и то, только для редактора вроде. Для рантайма будет позже.

Ответить
1

Для редактора - уже
Для рантайма - в 2019.3

Ответить
1

UIElements еще требует доработки, чтобы стать полной альтернативой uGUI. Ну и пообещали старую систему все же продолжать поддерживать.

Ответить

Столичный шар

WojciechSib
1

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

Ответить
0

Именно так. Учитывая, что UIElements еще довольно сырая, а срываться перепиливать весь интерфейс на новый лад позволить могут себе далеко не все (особенно, крупные проекты) ...

Ответить
0

Вот кстати вопрос.

Ответить
0

2020 что то серьёзное собираются сделать с UIElements.

Ответить
0

Они, это кто, Unity или Банзай ? 
Если юнити, то uGUI не куда не денется

Ответить
0

Какая игра использована в материале? Похоже на shadow fight 3

Ответить
1

Очевидно она и есть

Ответить
1

Почти ) Это будущий спин-офф SF3 ... Shadow Fight Arena

Ответить
0

Она и есть, собственно Сатья от разработчиков. 

Ответить
2

Сатья Наделла

Ответить
0

Т9. Шо. 

Ответить
0

Часто про Майков пишите?

Ответить
0

Часто про Индию пишу. 

Ответить

Комментарий удален

Комментарий удален

Комментарий удален

0

Что будет дешевле по производительности, использовать uGui или сделать еще одну, ортографическую камеру, выделить отдельный слой и рисовать там частицы, 3д объекты и все что душе угодно?

Ответить
0

Вообще 2D в целом дешевле 3D объектов

Ответить
0

Часто проще написать свой код, нежели разбирать и переписывать чужой

Ответить
0

Боже, автор статьи, почему вы так офигенны? Спасибо большое и чмок в попку за дополнительну инфу в конце статьи.

Ответить
–1

Интересно, почему они вместо выдумывания своего велосипеда не могли просто купить NGUI? 

Ответить
0

А они это и сделали :)))

Ответить

Прямой эфир

{ "jsPath": "/static/build/dtf.ru/specials/DeliveryCheats/js/all.min.js?v=05.02.2020", "cssPath": "/static/build/dtf.ru/specials/DeliveryCheats/styles/all.min.css?v=05.02.2020", "fontsPath": "https://fonts.googleapis.com/css?family=Roboto+Mono:400,700,700i&subset=cyrillic" }