unity как обратиться к тексту через скрипт

Четыре способа работы с текстом UI в Unity

В процессе преобразования старого кода Unity на основе 2D Toolkit в чистый код Unity я столкнулся с проблемой: в Unity есть замечательная поддержка стандартных форматов шрифтов, но этого всё равно недостаточно, чтобы сравниться поддержкой создания шрифтов из листов спрайтов в tk2d.

Пример спрайтового шрифта

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

Поэтому я приступил к каталогизации различных опций, которые предоставляет Unity при работе с текстом UI (в том числе недавно приобретённого Unity и встроенного в версию 2018.1 TextMesh Pro). Хотя мои знания типографики довольно узки (а тема эта, похоже, очень сложна), статья позволит вам понять, какие возможности существуют и как их можно использовать.

Стандартный Unity Font Asset

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

Применение: только для компонентов UI Text

Возможности масштабирования: текст можно свободно масштабировать в компоненте UI Text. Масштабирование самого шрифта увеличивает размер генерируемой из шрифта текстуры, что делает результат более чётким.

Плюсы/минусы: Прост в использовании, но поддерживаются только импортируемые шрифты.

Unity Custom Font

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

Источник: Custom Fonts создаются из материала (Material) (который ссылается на Texture) и таблиц символов.

Таблицы символов кажутся мне немного сложными (но думаю, что это проще, чем разбираться с UV-координатами). Кроме того, похоже. не существует GUI-инструмента для их генерации из самого листа спрайтов. У каждого символа есть следующие свойства:

Можно задать масштаб game object, содержащего компонент Text. Однако при этом изменяются границы элемента, поэтому это довольно неудобно, если вы хотите выровнять разные элементы.

Применение: только для компонентов UI Text

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

TextMesh Pro Font Asset

В отличие от Unity, в TextMesh Pro есть единый формат для текстовых файлов и спрайтовых шрифтов, и его поведение для обоих типов шрифтов примерно одинаково.

Недостаток шрифтов TextMesh Pro заключается в том, что их можно использовать только с компонентами TextMesh Pro UI. Если вы считаете, что есть причина для использования TextMesh Pro, то лучше принять это решение на ранних этапах проекта и постоянно придерживаться его на протяжении всего проекта. Переделка готового проекта, написанного со стандартными компонентами UI Text, окажется мучительной задачей.

Источник: шрифтовые ресурсы TextMesh Pro создаются из материала (Material) и таблиц символов, почти как Custom Fonts Unity.

Таблицы символов указываются только в пиксельных координатах, а не в UV, поэтому они проще и точнее, чем произвольные шрифты Unity. Кроме того, существует инструмент Font Asset Creator, создающий шрифтовой ресурс TextMesh Pro из файла шрифта. Однако для спрайтовых шрифтов процесс всё равно довольно медленный.

Опции масштабирования: масштабировать шрифт TextMesh Pro можно в компоненте TextMesh Pro UI, меняя размер шрифта и без необходимости изменения масштаба game object. По этой причине, если мне нужно использовать спрайтовый шрифт, то я предпочитаю TextMesh Pro нативному Unity Text.

Применение: TextMesh Pro — только компоненты Text UI

Плюсы/минусы: более гибкий, чем шрифтовые ресурсы или спрайтовые шрифты Unity, но требует собственного компонента TextMesh Pro UI Text. Отсутствует инструмент для создания таблиц символов из листов спрайтов, их приходится делать вручную.

TextMesh Pro Sprite Asset

Спрайтовые ресурсы TextMesh Pro немного не к месту в этом списке — на самом деле они не являются шрифтовыми ресурсами в том же смысле, что и остальные три типа. Скорее это дополнительная функция, предоставляемая пользователю компонентами TextMesh Pro – Text.

Спрайтовые ресурсы решают проблему смешения стандартного текста с внутриигровыми символами или значками (в качестве примера можно привести символы предметов, используемые внутри инвентаря Final Fantasy).

Применение: компоненты TextMesh Pro – Text UI. Для каждого компонента можно назначить один шрифтовой ресурс TMP и один спрайтовый ресурс TMP.

Для ссылки на значок спрайта в тексте используется тэг (где # — индекс спрайта начиная с 0).

Источник: TextMesh Pro Sprite Assets создаются из материала (Material) и таблиц символов. Концептуально они близки к шрифтовым ресурсам TextMesh Pro. Инструмент Sprite Importer немного лучше, чем Font Asset Creator, потому что он может использовать файлы FNT для генерации таблиц символов листов спрайтов. (См. примечания о файлах FNT в следующем разделе.)

Плюсы/минусы: отсутствуют, потому что этот способ на самом деле является побочным преимуществом использования TextMesh Pro. Если вы по какой-то причине хотите использовать этот функционал в проекте. то лучше всего как можно раньше начать применение TextMesh Pro.

Генерация произвольных шрифтов и шрифтовых ресурсов TextMesh Pro из файлов FNT

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

Основным недостатком создания спрайтовых шрифтов (с помощью средств Unity или шрифтовых ресурсов TextMesh Pro) является то, что отсутствует GUI-инструмент для определения символов из листа спрайтов. По сути, вам приходится вбивать вручную кучу цифр, тестировать шрифт, потом снова повторять, а это очень монотонный процесс.

Но есть и хорошие новости — существует более-менее стандартный текстовый формат для такой информации, который используется во многих GUI-инструментах для создания спрайтовых шрифтов. (Даже я сам написал упрощённую утилиту с частичной поддержкой спецификации FNT.)

Плохая новость заключается в том, что Custom Fonts Unity и шрифтовые ресурсы TextMesh Pro по умолчанию не поддерживают его.

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

Я написал очень простой конвертер FNT-to-TextMesh Pro Font Asset. Можете использовать его в качестве примера. Если вы сможете написать конвертер, который будет достаточно хорош для ваших целей, то он позволит перенести задачу создания спрайтового шрифта в более эффективный инструмент, что сэкономит время.

Источник

Методы организации взаимодействия между скриптами в Unity3D

Вступление

Подход 1. Назначение через редактор Unity3D

Пусть у нас в проекте есть два скрипта. Первый скрип отвечает за начисление очков в игре, а второй за пользовательский интерфейс, который, отображает количество набранных очков на экране игры.
Назовем оба скрипта менеджерами: ScoresManager и HUDManager.
Каким же образом менеджеру, отвечающему за меню экрана можно получить текущее количество очков от менеджера, отвечающего за начисление очков?
Предполагается, что в иерархии объектов(Hierarchy) сцены существуют два объекта, на один из которых назначен скрипт ScoresManager, а на другой скрипт HUDManager.
Один из подходов, содержит следующий принцип:
В скрипте UIManager определяем переменную типа ScoresManager:

Но переменную ScoresManager необходимо еще инициализировать экземпляром класса. Для этого выберем в иерархии объектов объект, на который назначен скрипт HUDManager и в настройках объекта увидим переменную ScoresManager со значением None.

Далее, из окна иерархии перетаскиваем объект, содержащий скрипт ScoresManager в область, где написано None и назначаем его объявленной переменной:

После чего, у нас появляется возможность из кода HUDManager обращаться к скрипту ScoresManager, таким образом:

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

Подход 2. «Синглтоны»

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

Примеры

Как правило, в единственном экземпляре существуют скрипты, отвечающие за общую логику пользовательского интерфейса, за проигрывание музыки, за отслеживание условий завершения уровня, за управление системой заданий, за отображение спецэффектов и так далее.
В то же время, скрипты игровых объектов существуют в большом количестве экземпляров: каждая птичка из «Angry Birds» управляется экземпляром скрипта птички со своим уникальным состоянием; для любого юнита в стратегии создается экземпляр скрипта юнита, содержащий его текущее количество жизней, позицию на поле и личную цель; поведение пяти разных иконок обеспечивается различными экземплярами одних и тех же скриптов, отвечающих за это поведение.
В примере из предыдущего шага скрипты HUDManager и ScoresManager всегда существуют в единственном экземпляре. Для их взаимодействия друг с другом применим паттерн «синглтон» (Singleton, он же одиночка).
В классе ScoresManager опишем статическое свойство типа ScoresManager, в котором будет храниться единственный экземпляр менеджера очков:

Осталось инициализировать свойство Instance экземпляром класса, который создает среда Unity3D. Так как ScoresManager наследник MonoBehaviour, то он участвует в жизненном цикле всех активных скриптов в сцене и во время инициализации скрипта у него вызывается метод Awake. В этот метод мы и поместить код инициализации свойства Instance:

После чего, использовать ScoresManager из других скриптов можно следующим образом:

Теперь нет необходимости в HUDManager описывать поле типа ScoresManager и назначать его в редакторе Unity3D, любой «скрипт-менеджер» может предоставлять доступ к себе через статическое свойство Instance, которое будет инициализировать в функции Awake.

Плюсы

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

Минусы

— подход обеспечивает доступ только к «скриптам-менеджерам», существующим в единственном экземпляре.
— сильная связанность.
На последнем «минусе» остановимся подробнее.
Пусть мы разрабатываем игру, в которой есть персонажи (unit) и эти персонажи могут погибать (die).
Где-то находится участок кода, который проверяет не погиб ли наш персонаж:

Получается, что персонаж после совей смерти должен разослать всем компонентам, которые в ней заинтересованы этот печальный факт, он должен знать о существовании этих компонентов и должен знать, что они им интересуются. Не слишком ли много знаний, для маленького юнита?
Так как игра, по логике, очень связанная структура, то и события происходящие в других компонентах интересуют третьи, юнит тут ничем не особенный.
Примеры таких событий (далеко не все):
— Условие прохождение уровня зависит от количества набранных очков, набрали 1000 очков – прошли уровень (LevelConditionManager связан с ScoresManager).
— Когда набираем 500 очков, достигаем важную стадию прохождения уровня, нужно проиграть веселую мелодию и визуальный эффект (ScoresManager связан с EffectsManager и SoundsManager).
— Когда персонаж восстанавливает здоровье, нужно проиграть эффект лечения над картинкой персонажа в панели персонажа (UnitsPanel связан с EffectsManager).
— и так далее.
В результате таких связей мы приходим к картине похожей на следующую, где все про всех все знают:

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

Подход 3. Мировой эфир (Event Aggregator)

Введем специальный компонент «EventAggregator», основная функция которого хранить список событий, происходящих в игре.
Событие в игре — это функционал, предоставляющий любому другому компоненту возможность как подписаться на себя, так и опубликовать факт совершения этого события. Реализация функционала события может быть любой на вкус разработчика, можно использовать стандартные решения языка или написать свою реализацию.
Пример простой реализации события из прошлого примера (о смерти юнита):

Добавляем это событие в «EventAggregator»:

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

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

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

Замечание

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

Плюсы

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

Минусы

— нужно постоянно описывать новые события и добавлять их в мир.
— нарушение функциональной атомарности.

Последний минус рассмотрим более детально

Представим, что у нас есть объект «ObjectA», в котором вызывается метод «MethodA». Метод «MethodA», состоит из трех шагов и вызывает внутри себя три других метода, которые выполняют эти шаги последовательно («MethodA1», «MethodA2» и «MethodA3»). Во втором методе «MethodA2» происходит публикация какого-то события. И тут происходит следующее: все кто подписан на это событие начнут его обрабатывать, выполняя какую-то свою логику. В этой логике тоже может произойти публикация других событий, обработка которых также может привести к публикации новых событий и так далее. Дерево публикаций и реакции в отдельных случаях может очень сильно разрастись. Такие длинные цепочки крайне тяжело отлаживать.
Но самая страшная проблема, которая тут может произойти, это когда одна из веток цепочки приводит обратно в «ObjectA» и начинает обрабатывать событие путем вызова какого-то другого метода «MethodB». Получается, что метод «MethodA» у нас еще не выполнил все шаги, так как был прерван на втором шаге, и содержит сейчас в себе не валидное состояние (в шаге 1 и 2 мы изменили состояние объекта, но последнее изменение из шага 3 еще не сделали) и при этом начинается выполняться «MethodB» в этом же объекте, имея это не валидное состояние. Такие ситуации порождают ошибки, очень сложно отлавливаются, приводят к тому, что надо контролировать порядок вызова методов и публикации событий, когда по логике этого делать нет необходимости и вводят дополнительную сложность, которую хотелось бы избежать.

Решение

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

Источник

Текст в Unity Text in Unity

Текст является одним из наиболее важных компонентов в holographic приложениях. Text is one of the most important components in holographic apps. Для отображения текста в Unity можно использовать три типа текстовых компонентов: текст пользовательского интерфейса, сетка трехмерных текстов и сетка текста Pro. To display text in Unity, there are three types of text components you can use—UI Text, 3D Text Mesh, and Text Mesh Pro. По умолчанию текст пользовательского интерфейса и сетка трехмерного текста отображаются нечеткими и слишком велики. By default, UI Text and 3D Text Mesh appear blurry and are too large. Изменение нескольких переменных приводит к увеличению текста высокого качества с управляемым размером в HoloLens. Changing a few variables results in sharper, higher-quality text with a manageable size in HoloLens. Вы можете улучшить качество рендеринга, применяя коэффициент масштабирования для получения правильных измерений при использовании компонентов текста пользовательского интерфейса и сетки трехмерного текста. You can achieve better rendering quality by applying a scaling factor to get proper dimensions when using the UI Text and 3D Text Mesh components.

Размытый текст по умолчанию в Unity Blurry default text in Unity

Работа с трехмерным текстом Unity (сетка текста) и текстом пользовательского интерфейса Working with Unity’s 3D Text (Text Mesh) and UI Text

Unity предполагает, что все новые элементы, добавленные в сцену, имеют одну единицу Unity в размере или 100% преобразования. Unity assumes all new elements added to a scene are one Unity Unit in size, or 100% transform scale. Одна единица Unity преобразуется в около 1 счетчика на HoloLens. One Unity unit translates to about 1 meter on HoloLens. Для шрифтов ограничивающий прямоугольник для 3D-Текстмеш по умолчанию имеет размер около 1 индикатора высоты. For fonts, the bounding box for a 3D TextMesh comes in by default at about 1 meter in height.

Объемный текст Unity по умолчанию (сетка текста) занимает одну единицу Unity, которая является 1 счетчиком. Default Unity 3D Text (Text Mesh) occupies one Unity Unit, which is 1 meter

Большинство визуальных конструкторов используют точки для определения размеров шрифтов в реальном мире. Most visual designers use points to define font sizes in the real world. Имеется около 2835 (2, 834.645666399962) точек в единицах измерения. There are about 2835 (2,834.645666399962) points in 1 meter. На основе преобразования системы точек в 1 измеритель и размер шрифта сетки по умолчанию Unity, равный 13, простые математические функции 13 делятся на 2835 равными 0,0046 (0.004586111116), что обеспечивает хороший Стандартный масштаб для начала работы (некоторые могут быть округлены до 0,005). Based on the point system conversion to 1 meter and Unity’s default Text Mesh font size of 13, the simple math of 13 divided by 2835 equals 0.0046 (0.004586111116 to be exact) which provides a good standard scale to start with (some may wish to round to 0.005). Масштабирование текстового объекта или контейнера до этих значений не только приводит к 1:1 преобразованию размеров шрифта в программе-конструкторе, но также предоставляет стандарт, позволяющий поддерживать согласованность в процессе работы. Scaling the text object or container to these values will not only allow for the 1:1 conversion of font sizes in a design program, but also provides a standard so you can maintain consistency throughout your experience.

Масштабирование значений для трехмерного текста Unity и текста пользовательского интерфейса Scaling values for the Unity 3D Text and UI Text

Трехмерная сетка Unity с оптимизированными значениями Unity 3D Text Mesh with optimized values

При добавлении элемента текста на основе пользовательского интерфейса или холста в сцену по-прежнему увеличивается размер четности. When adding a UI or canvas-based text element to a scene, the size disparity is greater still. Разница в двух размерах составляет примерно 1000%, что приведет к увеличению коэффициента масштабирования для текстовых компонентов на основе пользовательского интерфейса в 0,00046 (0.0004586111116) или 0,0005 для округленного значения. The differences in the two sizes are about 1000%, which would bring the scale factor for UI-based text components to 0.00046 (0.0004586111116 to be exact) or 0.0005 for the rounded value.

Текст пользовательского интерфейса Unity с оптимизированными значениями Unity UI Text with optimized values

Значение по умолчанию любого шрифта может зависеть от размера текстуры этого шрифта или от того, как шрифт был импортирован в Unity. The default value of any font may be affected by the texture size of that font or how the font was imported into Unity. Эти тесты были выполнены на основе шрифта Arial по умолчанию в Unity, а также одного другого импортированного шрифта. These tests were performed based on the default Arial font in Unity, as well as one other imported font.

Работа с сеткой текста Pro Working with Text Mesh Pro

Масштабирование значений для трехмерного текста и пользовательского интерфейса Unity Scaling values for the Unity 3D Text and UI

Рекомендуемый размер текста Recommended text size

Как можно догадаться, размеры типов, используемые на ПК или планшетном устройстве (обычно от 12 – отступ), выглядят небольшими на расстоянии 2 метра. As you can expect, type sizes that we use on a PC or a tablet device (typically between 12–32pt) look small at a distance of 2 meters. Это зависит от характеристик каждого шрифта, но в общем случае рекомендуемый минимальный угол просмотра и высота шрифта для читаемости находятся вокруг 0,35 °-0,4 °/12.21-13.97 мм на основе наших исследований исследования пользователей. It depends on the characteristics of each font, but in general the recommended minimum viewing angle and the font height for legibility are around 0.35°-0.4°/12.21-13.97 mm based on our user research studies. Это примерно 35-40 пт с коэффициентом масштабирования, представленным выше. It’s about 35-40 pt with the scaling factor introduced above.

Для близкого взаимодействия в 0,45 м (45 cm) минимальный угол просмотра и высоту шрифта — 0,4 °-0,5 °/3,14 – 3,9 мм. For the near interaction at 0.45 m (45 cm), the minimum legible font’s viewing angle and the height are 0.4°-0.5° / 3.14–3.9mm. Это примерно 9-12 пт с коэффициентом масштабирования, представленным выше. It’s about 9-12 pt with the scaling factor introduced above.

в пределах диапазона практически и дальнего взаимодействия Content at near and far interaction range

Минимальный размер неудобочитаемого шрифта The minimum legible font size

Удобно, чтобы размер шрифта разборчиво The comfortably legible font size

Segoe UI (шрифт по умолчанию для Windows) хорошо работает в большинстве случаев. Segoe UI (the default font for Windows) works well in most cases. Однако старайтесь не использовать светло-или светлое семейство шрифтов в небольшом размере, так как тонкие вертикальные штрихи будут вибрировало, и это приведет к ухудшению читаемости. However, avoid using light or semi light font families in small size since thin vertical strokes will vibrate and it will degrade the legibility. Современные шрифты с достаточной толщиной обводки хорошо работают. Modern fonts with enough stroke thickness work well. Например, Helvetica и Arial выглядят прекрасные и являются выразительными в HoloLens с обычными или полужирными плотностьми. For example, Helvetica and Arial look gorgeous and are legible in HoloLens with regular or bold weights.

просмотра расстояния, угла и высоты текста Viewing distance, angle, and text height

Текст с набором средств Mixed Reality версии 2 Text with Mixed Reality Toolkit v2

Качество отрисовки текста с правильным измерением Sharp text rendering quality with proper dimension

На основе этих коэффициентов масштабирования мы создали текст Prefabs с текстом пользовательского интерфейса и сеткой трехмерного текста. Based on these scaling factors, we have created text prefabs with UI Text and 3D Text Mesh. Разработчики могут использовать эти Prefabs, чтобы получить четкий текст и согласовать размер шрифта. Developers can use these prefabs to get sharp text and consistent font size.

Качество отрисовки текста с правильным измерением Sharp text rendering quality with proper dimension

Шейдер с поддержкой перекрытия Shader with occlusion support

Материал по шрифтам Unity по умолчанию не поддерживает перекрытия. Unity’s default font material doesn’t support occlusion. По этой причине текст позади объектов по умолчанию будет отображаться. Because of this, you’ll see the text behind the objects by default. Мы включили простой шейдер, который поддерживает перекрытия. We’ve included a simple shader that supports the occlusion. На рисунке ниже показан текст со стандартным материалом шрифта (слева) и текстом с правильным перекрытия (справа). The image below shows the text with default font material (left) and the text with proper occlusion (right).

Шейдер с поддержкой перекрытия Shader with occlusion support

Следующий этап разработки Next Development Checkpoint

Если вы пойдете из пути разработки Unity, мы собрались, что вы в состоянии изучить стандартные блоки МРТК Core. If you’re following the Unity development journey we’ve laid out, you’re in the midst of exploring the MRTK core building blocks. Отсюда вы можете перейти к следующему стандартному блоку: From here, you can continue to the next building block:

Или перейдите к возможностям и API платформы смешанной реальности: Or jump to Mixed Reality platform capabilities and APIs:

Вы можете в любой момент вернуться к этапам разработки для Unity. You can always go back to the Unity development checkpoints at any time.

Источник