Представляем третью статью нашей серии о работе с 3D-моделями в Unity. Предыдущие статьи: «Особенности работы с Mesh в Unity» И «Unity: процедурное редактирование сетки» .
В мире компьютерной графики существует множество форматов представления 3D-моделей.
Некоторые из них позиционируются как универсальные, другие — как оптимизированные под конкретные задачи или платформы.
В любой сфере мечтают работать с универсальным форматом, но реальность говорит нам «нет».
Более того, из-за такого зоопарка получается порочный круг: разработчики «универсальных» инструментов придумывают свои внутренние форматы для обобщения предыдущих, увеличивая популяцию и производя инструменты преобразования форматов.
Это создает проблему потери или повреждения данных во время преобразования.
Проблема стара как мир (конечно, мир ИТ), и она не избежала импорта моделей в Единство .
В этой статье мы поговорим о некоторых трудностях, с которыми вы сталкиваетесь при работе с моделями в Единство (функциональные особенности МодельИмпортер , различия в представлениях 3D-объектов и т. д.), а также какие инструменты мы создали для преодоления этих трудностей.
Возможности ModelImporter
Напомним, что для API видеокартах минимальный и единственный трехмерный примитив — треугольник, а геометрия в ФБХ , например, можно представить в виде четырехугольников.Современные 3D-пакеты для создания моделей, как правило, допускают различные уровни абстракции, но даже там результат визуализируется с помощью треугольников.
В то же время многие инструменты предназначены для работы именно с четырехугольниками, что побуждает 3D-художников использовать этот примитив в качестве основного.
В таких случаях ТЗ часто требует триангуляции модели перед ее реализацией.
Если триангуляция не выполнена, соответствующий модуль Единство в стандартном режиме он выполняет это автоматически при добавлении файла.
Это вызывает ошибки, поскольку алгоритмы триангуляции в разных пакетах реализованы по-разному.
При выборе диагонали для деления четырехугольника возникает неоднозначность, отсюда и большая часть проблем, которые можно разделить на две группы.
Первое связано с правильным отображением формы модели.
Таким образом, форма неплоского четырехугольника напрямую зависит от выбора диагонали.
Сюзанна провела триангуляцию Блендер (Метод четверки: Красота) и в Единство (автоматически при импорте)
Кроме того, алгоритм запекания карты нормалей использует данные секционирования, из-за чего различия в триангуляции могут давать артефакты в виде крестика на подсветке.
Самокат здорового человека и самокат курильщика
Проблемы второй группы возникают при наложении текстур.
Например, у нас есть четырехугольник с углом, достаточно тупым, чтобы вызвать ошибку.
При предварительном просмотре в 3D-пакете он разделен одной из диагоналей на два вполне складных треугольника.
Исходный полигон 
Многоугольник триангулирован в Блендер
Однако после импорта в проект обнаруживается, что этот четырехугольник разделен еще одной диагональю и что один из треугольников либо полностью вырожден, либо близок к нему.
Многоугольник в Единство с треугольником, близким к вырожденному (прямоугольный треугольник практически неотличим от отрезка)
Проблемы с вырождением полигонов вызваны ошибками в вычислениях с плавающей запятой, а также особенностями интерполяции пикселей при рендеринге.
Что, черт возьми, происходит с этими треугольниками: они дергаются, меняя цвет каждый кадр.
Чрезвычайно маленькая площадь поперечного сечения создает трудности при обработке света, из-за чего части динамических объектов могут мерцать.
Да и в недетерминированности выпечки световые карты тоже ничего хорошего.
Я 3D-пакет, вот как я это вижу.
При 3D-моделировании часто существует разница между фактическим количеством вершин и количеством вершин в 3D-пакете.
Суть проблемы заключается в информации, которую необходимо обработать видеокарте.
Структура данных для вершины предопределена и включает в себя положение, нормаль, касательную, координаты текстурной карты для каждого канала и цвет. То есть вы не можете поместить две нормали в одну вершину.
Для некоторых художников не всегда очевидно, что вершина определяется не только своим положением.
Моделисты очень хорошо знают концепции.
Жесткие/мягкие края И УФ-швы , но не все понимают, как они реализованы в программном обеспечении.
Еще больше сбивают с толку 3D-пакеты, которые по умолчанию показывают количество вершин как количество уникальных позиций.
Да, обычный примитив Куб Представим его геометрически 8 вершинами.
Однако, чтобы правильно передать отражение света от каждой грани и правильно применить текстуру, в каждом углу куба нужно по 3 вершины с одинаковым положением, но разными нормалями и текстурными координатами, так как в каждом углу сходятся 3 ребра.
Этому моменту мы посвятили небольшой раздел.
Там же вы можете увидеть примеры.
Метрики куба Блендер 
Метрики куба Единство
Хватит это терпеть!
Столкнувшись с этими и подобными проблемами, мы решили создать инструмент для анализа и проверки моделей при импорте в проект. Единство .Другими словами, собственный валидатор, отвечающий на запрос «Ешь!» ответит: «Не буду! Переделай», иначе он будет выплевывать наборы предупреждений и значений различных параметров, оповещая, что что-то ему не по вкусу.
Для анализа и проверки мы разработали следующий функционал: подсчет количества уникальных позиций вершин, цветных вершин, Жесткие края , УФ-швы ; расчет Ограничительная рамка, ориентированная по оси (AABB) и его центр; определение вывода значений координат УФ - развертка в диапазоне 0,0–1,0; обнаружение наложений при наложении текстур; проверка сканирования текстуры, чтобы убедиться, что указанное смещение пикселей достаточно для указанного разрешения текстуры.
Что это нам дает? Подсчет количества уникальных позиций вершин, жестких краев, УФ-швов.
И окрашенные вершины — необходимы для проверки соответствия модели, задуманной художником, той, которая была импортирована в Единство .
Этот функционал также позволяет следить за соблюдением требований оптимизации модели (например, чтобы количество вершин не превышало определенного значения).
Из-за той же особенности 3D-пакетов, которые на самом деле показывают количество уникальных позиций, бывают случаи, когда метрика количества вершин в редакторе моделей удовлетворяет этому ограничению, но после добавления файла в проект может оказаться, что это это не так.
Расчет AABB и ее центра — позволяет определить смещение модели относительно начала собственной системы координат. Это необходимо для предсказуемого расположения ресурсов, которые инициализируются в сцене во время работы приложения.
Так, ААББ здание должно иметь minY = 0, а какая-нибудь люстра, прикрепленная к потолку, должна иметь maxY = 0. 
Координаты UV-вершины вне диапазона 0,0–1,0. - в большинстве случаев (например, если текстура должна быть наложена на модель) предусмотрена.
Часто этот подход используется для представления сцены со множеством малодетализированных мелких объектов (растительности) и/или расположенных на расстоянии, а также тесселяции крупных однородных объектов (зданий).
В случае тайлинга значения координат конкретного УФ -каналы просто отсекают всю часть на уровне шейдера, если Режим переноса текстуры установлены на Повторить .
Теперь представьте, что вы обложили текстуру атласом (и накрыли ее одеялом :3).
Шейдер получит уже преобразованные координаты, соответствующие атласу (х*масштаб+смещение).
В этот раз, скорее всего, целой детали не будет и отрезать будет нечего, а модель залезет на чужую текстуру (одеяло получилось маленькое).
Эту проблему можно решить двумя способами.
Первый предполагает, что вы заранее отрезаете всю деталь по координатам сканирования.
В этом случае существует вероятность перекрытия полигонов, о чем мы поговорим ниже.
Второй основан на том факте, что тайлинг текстур по своей сути является методом оптимизации.
Никто не мешает вам увеличить размер и отмерить нужную деталь для всей модели.
Однако таким образом полезное пространство атласа будет использовано неэффективно.
Наложения текстур - тоже чаще всего не случайны: они нужны для эффективного использования текстурных участков.
Бывает, новичок совершает ошибку, старший товарищ видит это, говорит крепкое слово, а новичок больше этого не делает. Но бывает, что перекрытие настолько маленькое и расположено в таком неожиданном месте, что его может не заметить даже старший товарищ.
В опытной команде ошибки, не обнаруженные при базовом сканировании, попадают в проект чуть чаще, чем никогда.
Другое дело, когда меняются условия использования готового контента.
Пример.
Мы работали с набором моделей динамических объектов в игре.
Поскольку задачи печь для них свет не было, УФ - при сканировании допускаются перекрытия.
Базовый пример УФ -сканы с наложениями (показаны красным)
Однако потом мы решили не использовать эти модели как динамические, а разместить их как статичное украшение уровня.
Для оптимизации, как известно, освещение статичных объектов сцены запекается в специальный атлас.
Отдельный УФ2 -канал для световые карты у этих моделей не было, да и качество автоматического генератора было Единство нам это не понравилось, поэтому мы решили максимально использовать базовую текстуру для выпечки.
Вот тут и возникли явные проблемы с корректностью освещения.
Очевидно, что лучи, попадающие статуе в глаз, не должны создавать блики на пятой точке на затылке.
Неправильно запеченное освещение модели (слева) и исправленное (справа) Единство при формировании световые карты прежде всего пытается использовать УФ2 -канал.
Если он пуст, то используется основной УФ , если этот пуст, то извините, для вас есть исключение.
Запекайте модели в световая карта без предварительной подготовки УФ2 В Единство возможно двумя способами.
Как первый Единство предлагает автоматическую генерацию УФ2 в зависимости от геометрии модели.
Это быстрее, чем делать это вручную, и инструмент можно настроить с помощью нескольких параметров.
Но даже несмотря на это, для высокодетализированных объектов итоговое применение света и тени зачастую оказывается неудовлетворительным из-за швов и засветов в неподходящих местах, а упаковка частей такого скана не самая эффективная.
Второй способ – использовать базовый УФ -развертка для выпечки.
Очень привлекательный вариант, так как при работе с одним сканом текстур меньше шансов допустить ошибку, чем при работе с двумя.
По этой причине мы стараемся минимизировать количество моделей, в базовой комплектации.
УФ в которых есть совпадения.
Созданный инструментарий помогает нам это сделать.
Проверка сканирования текстуры, чтобы убедиться, что указанное смещение пикселей достаточно при заданном разрешении текстуры.
- более точная проверка УФ , на основе растеризации.
Более подробно этот метод будет рассмотрен в следующей статье серии.
Подведем итог.
Конечно, отследить все нюансы практически невозможно: иногда приходится мириться с несовершенством результата, чтобы выполнить задачу в срок.
Однако выявление даже некоторых из этих недостатков позволяет ускорить разработку проекта и повысить его качество.
Теги: #Разработка игр #unity #моделирование #Работа с 3D-графикой #3d графика #Mesh #рендеринг #unity3d #3d графика #3d графика #uv #uv #uv #blenderexport #lightmaping
-
Мобильный Для Интернета
19 Oct, 24 -
Туринская Шкала Опасности Астероидов
19 Oct, 24 -
10 Причин Для Ipo
19 Oct, 24 -
Армения Снова Онлайн
19 Oct, 24 -
Глина → Кирпич → Печь Для Обжига
19 Oct, 24
