3D форматы
Импортирование мешей в Unity может быть выполнено с помощью двух основных типов файлов:
- Экспортированные 3D форматы файлов, такие как .FBX или .OBJ
- Собственные файлы 3D приложений, например такие как .Max и .Blend файлы из 3D Studio Max и Blender.
Любой из этих типов позволит вам добавлять свои меши в Unity, но есть соображения относительно того типа, который вы выберите:
Экспортированные 3D файлы
Unity может читать .FBX, .dae (Collada), .3DS, .dxf и .obj файлы, obj или Collada экспортеры могут быть найдены для многих приложений, точно также как FBX экспортеры могут быть найдены здесь
Преимущества:
- Экспортируйте только необходимые данные
- Проверяемые данные (перед импортированием в Unity, переимпортируйте в 3D пакет)
- Как правило файлы меньшего размера
- Поддерживает модульный подход — к примеру разными компонентами для интерактивности и типов коллизий
- Поддерживает другие 3D пакеты, чьи форматы не поддерживаются у нас напрямую
Недостатки:
- Может замедлять процесс прототипирования и итераций
- Легче потерять след между исходной (рабочий файл) и игровой версией данных (к примеру экспортированный FBX файл)
Собственные файлы 3D приложений
Unity также может импортировать, путём конвертации, файлы: Max, Maya, Blender, Cinema4D, Modo, Lightwave и Cheetah3D , например, .MAX, .MB, .MA и др.
Импорт 3D-моделей в Unity и подводные камни
В мире компьютерной графики существует множество форматов представления 3D-моделей. Некоторые из них позиционируются как универсальные, другие — как оптимизированные под конкретные задачи или платформы. В любой сфере мечтают работать с универсальным форматом, но реальность говорит нам «нет». Более того, из-за такого зоопарка получается порочный круг: разработчики «универсальных» инструментов придумывают свои внутренние форматы для обобщения предыдущих, увеличивая популяцию и плодя средства преобразования форматов. Так появляется проблема потери или искажения данных при конвертации. Проблема стара как мир (мир IT, конечно), и она не обошла стороной импорт моделей в Unity.
В этой статье мы расскажем о некоторых трудностях, с которыми приходится сталкиваться при работе с моделями в Unity (особенности функционирования ModelImporter, разница представлений 3D-объектов и др.), а также о том, какие инструменты мы создали, чтобы эти трудности преодолеть.
Особенности работы ModelImporter
Напомним, что для API видеокарт минимальный и единственный трехмерный примитив — это треугольник, в то время как геометрия в FBX, например, может быть представлена в виде четырехугольников. Современные 3D-пакеты для создания моделей, как правило, допускают различные уровни абстракции, но и там рендер результата происходит посредством треугольников.
При этом многие инструменты заточены на работу именно с четырехугольниками, что подталкивает 3D-художников использовать этот примитив как основной. В таких случаях в ТЗ часто требуется триангулировать модель перед внедрением. Если триангуляцию не сделали, соответствующий модуль Unity в стандартном режиме выполняет ее автоматически при добавлении файла. Из-за этого появляются ошибки, поскольку алгоритмы триангуляции в разных пакетах реализованы по-разному. При выборе диагонали для разбиения четырехугольника возникает неоднозначность, отсюда большинство проблем, которые можно разделить на две группы.
Первая связана с корректностью отображения формы модели. Так, форма непланарного четырехугольника напрямую зависит от выбора диагонали.
Сюзанна, триангулированная в Blender (Quad Method: Beauty) и в Unity (автоматически при импорте)
Кроме того, алгоритм запекания карты нормалей использует данные о разбиении, из-за чего разница в триангуляции может порождать артефакты в виде креста на блике.
Самокат здорового человека и самокат курильщика
Проблемы второй группы встречаются в текстурной развертке. Например, у нас есть четырехугольник с достаточно тупым для возникновения ошибки углом. При предварительном просмотре в 3D-пакете он разбивается одной из диагоналей на два вполне себе складных треугольника.
Исходный полигон
Полигон, триангулированный в Blender
Однако после импорта в проект обнаруживается, что этот четырехугольник разбит другой диагональю и что один из треугольников либо вообще вырожден, либо близок к тому.
Полигон в Unity с треугольником, близким к вырожденному (правый треугольник практически неотличим от отрезка)
Причиной проблем, связанных с вырожденностью полигонов, являются погрешности в вычислениях с плавающей запятой, а также особенности пиксельной интерполяции при рендеринге. С такими треугольниками происходит черт-те что: они дергаются, каждый кадр меняют цвет. Крайне малая величина поперечного сечения создает сложности при обработке света, из-за чего части динамических объектов могут мерцать. Да и в недетерминированности запекания карты освещения тоже нет ничего хорошего.
Я 3D-пакет, я так вижу
В 3D-моделировании часто возникает разница между фактическим количеством вершин и их количеством в 3D-пакете. Суть проблемы заключается в информации, которая требуется для обработки видеокартой. Структура данных для вершины предопределена и включает в себя позицию, нормаль, касательную, координаты текстурной развертки на каждый канал и цвет. То есть в одну вершину две нормали не запихнуть.
Для некоторых художников же не всегда очевидно, что вершина определяется не только своей позицией. Моделлеры прекрасно знают понятия Hard/Soft Edges и UV Seams, но не все осознают, каким образом они реализованы программно. Дополнительно сбивают с толку 3D-пакеты, которые в стандартном режиме показывают количество вершин как количество уникальных позиций.
Так, обычный примитив Cube геометрически представим 8 вершинами. Однако чтобы корректно передать отражение света от каждой грани и правильно наложить текстуру, в каждом углу куба необходимо по 3 вершины с одинаковой позицией, но разными нормалями и текстурными координатами, поскольку в каждом из углов сходится по 3 ребра. Этому моменту посвятили небольшой блок документации. Там же можно посмотреть примеры.
Метрики куба в Blender
Метрики куба в Unity
Хватит это терпеть!
Столкнувшись с этими и подобными проблемами, мы решили создать инструмент анализа и валидации моделей при импорте в проект Unity. Иначе говоря, кастомный валидатор, который на запрос «Ешь!» ответит: «Не буду! Переделывай», — или выплюнет наборы предупреждений и значений различных параметров, оповещая о том, что ему что-то невкусно.
Для анализа и проверки мы разработали следующий функционал:
- подсчет количества уникальных позиций вершин, раскрашенных вершин, Hard Edges, UV Seams;
- расчет Axis-Aligned Bounding Box (AABB) и его центра;
- определение выхода значений координат UV-развертки за диапазон 0.0–1.0;
- определение наложений в текстурной развертке;
- проверка текстурной развертки на достаточность заданного пиксельного отступа при заданном разрешении текстуры.
Подсчеты количества уникальных позиций вершин, Hard Edges, UV Seams и раскрашенных вершин — необходимы для проверки соответствия задуманной художником модели той, что была импортирована в Unity. Этот функционал также позволяет следить за соблюдением требований к оптимизации модели (например, чтобы количество вершин не превышало определенное значение). Из-за все той же особенности 3D-пакетов, которые показывают по факту количество уникальных позиций, бывают случаи, когда метрика числа вершин в редакторе моделей удовлетворяет этому ограничению, однако после внесения файла в проект может оказаться, что это не так.
Вычисление AABB и его центра — позволяет определить смещение модели относительно начала ее собственной системы координат. Это необходимо для предсказуемого позиционирования ассетов, которые инициализируются в сцене уже во время работы приложения. Так, AABB здания по-хорошему должен иметь minY = 0, а какой-нибудь люстры, которая крепится к потолку — maxY = 0.
Выход координат вершин UV-развертки за диапазон 0.0–1.0 — в большинстве случаев (например, если текстура должна тайлиться на модели) предусмотрен. Часто такой подход используется для представления в сцене множества низкодетализированных мелких объектов (растительности) и/или находящихся вдалеке, а также замощения больших однородных объектов (зданий). В случае тайлинга значениям координат конкретного UV-канала просто обрезают целую часть на уровне шейдера, если Wrap Mode текстуры установлен в Repeat.
Представьте теперь, что вы уложили текстуру в атлас (и накрыли одеялком :3). В шейдер будут приходить уже преобразованные координаты, соответствующие атласу (x * масштаб + смещение). Никакой целой части на этот раз вероятнее всего уже не будет и обрезать будет нечего, а модель залезет на чужую текстуру (одеялко оказалось маленьким). Эта проблема решается двумя способами.
Первый предполагает, что вы заранее обрежете целую часть у координат развертки. В этом случае появляется вероятность взаимоналожения полигонов, о чем мы поговорим ниже.
Второй основывается на том, что тайлинг текстур по своей сути — это метод оптимизации. Вам же никто не запрещает увеличить размер и просэмплировать нужный кусок на всю модель. Однако таким образом полезное пространство атласа будет использовано неэффективно.
Наложения в текстурной развертке — тоже чаще всего не случайны: они нужны, чтобы эффективно использовать площади текстуры. Бывает, что ошибку совершает новичок, старший товарищ это видит, произносит крепкое словцо и новичок больше так не делает. Но бывает, что наложение настолько мелкое и находится в настолько неожиданном месте, что и старший товарищ может его не заметить.
В опытном коллективе незамеченные на базовой развертке ошибки попадают в проект чуть чаще, чем никогда. Другое дело, когда меняются условия использования уже готового контента.
Пример. Мы работали с набором моделей для динамических объектов в игре. Поскольку не было задачи запечь для них свет, в UV-развертке допускались наложения.
Пример базовой UV-развертки с наложениями (показаны красным)
Однако затем мы решили не использовать эти модели как динамические, а расставлять их в качестве статичного декора на уровне. Для оптимизации, как известно, освещение статических объектов в сцене запекают в специальный атлас. Отдельного UV2-канала для карты освещения у этих моделей не было, а качество работы автоматического генератора в Unity нас не устраивало, поэтому мы решили как можно чаще использовать базовую текстурную развертку для запекания.
Здесь и возникли явные проблемы с корректностью освещения. Очевидно, что лучи, попадающие какой-нибудь статуе в глаз, не должны создавать блики на пятой точке на затылке.
Некорректно запеченное освещение модели (слева) и исправленное (справа)
Unity при формировании карты освещения в первую очередь пытается использовать UV2-канал. Если он пустой, то используется основной UV, если и этот пуст, то извините, нате вам исключение. Запечь модели в карту освещения без предварительно подготовленного UV2 в Unity можно двумя способами.
В качестве первого Unity предлагает автоматическую генерацию UV2 на основе геометрии модели. Это быстрее, чем делать вручную, к тому же данный инструмент можно настраивать с помощью нескольких параметров. Но даже несмотря на это, итоговое наложение светотени часто неудовлетворительно для высокодетализированных объектов из-за швов и затеканий в неположенных местах, к тому же упаковка частей такой развертки не самая эффективная.
Второй способ — использовать базовую UV-развертку для запекания. Очень даже привлекательный вариант, поскольку при работе с одной текстурной разверткой меньше вероятность совершить ошибку, чем при работе с двумя. По этой причине мы стараемся минимизировать количество моделей, в базовой UV которых присутствуют наложения. Созданный инструментарий помогает нам это осуществлять.
Проверка текстурной развертки на достаточность заданного пиксельного отступа при заданном разрешении текстуры — более точная валидация UV, основанная на растеризации. Подробнее об этом методе будет рассказано в следующей статье серии.
Подведем итог. Конечно, практически невозможно отследить все нюансы: иногда приходится мириться с несовершенством результата, чтобы выполнить задачу в срок. Однако выявление даже части таких недочетов позволяет ускорить разработку проекта и повысить его качество.
Форматы файлов моделей
Unity поддерживает ряд стандартных и проприетарных форматов файлов моделей.
Внутри Unity использует формат файла .fbx в качестве цепочки импорта. По возможности рекомендуется использовать формат файлов .fbx, и вам не следует использовать проприетарные форматы файлов моделей в производстве.
Поддерживаемые форматы файлов моделей
Стандартные форматы файлов
Unity может читать следующие стандартные форматы 3D-файлов:
Эти форматы файлов широко поддерживаются. Они также часто меньше, чем проприетарный эквивалент, что уменьшает размер вашего проекта и ускоряет итерацию.
Вы также можете повторно импортировать экспортированные файлы .fbx или .obj в выбранное вами программное обеспечение для 3D-моделирования, чтобы убедиться, что вся информация экспортирована правильно.
Запатентованные форматы файлов
Вы не должны использовать эти форматы файлов в рабочей среде; вместо этого по возможности экспортируйте в формат .fbx. Однако иногда вам может понадобиться включить эти файлы как часть вашего проекта.
Unity может импортировать проприетарные файлы из следующих программ для 3D-моделирования, а затем преобразовывать их в файлы .fbx:
Следующие приложения не используют .fbx в качестве посредника. Unity должен преобразовать их в файлы .fbx, прежде чем импортировать их в редактор:
Для получения дополнительной информации см. документацию по настройкам импорта SketchUp и настройкам импорта SpeedTree.
Неподдерживаемые форматы файлов моделей
В Unity нет встроенной поддержки файлов Cinema4D. Чтобы использовать файлы Cinema4D в Unity, вы должны экспортировать их из проприетарного программного обеспечения в виде файлов .fbx.
Ресурсы, сохраненные в виде файлов .ma, .mb, .max, .c4d или .blend, не могут быть импортированы, если на вашем компьютере не установлено соответствующее программное обеспечение для 3D-моделирования. Это означает, что у всех, кто работает над вашим проектом Unity, должно быть установлено правильное программное обеспечение. Например, если вы используете лицензию Autodesk Maya LT для создания файла .mb и скопируйте его в свой проект, любой, кто откроет ваш проект, также должен иметь установленный Autodesk Maya LT на своем компьютере.
3D File Formats Unity 2021 Supports and How to Import 3D Models
Unity 3D is a 3D game engine that allows users to create 3D games in an environment. Users can create 3d models and import them into Unity, but what file types are supported? This blog post will look at the 3d file formats Unity 2021 supports – including FBX files- and how to import these 3d models.
Unity supports the following 3D file formats: .fbx, .dae, .obj, .dxf, .skp, and .stl. Unity does not support the following 3d file formats: .ply or any other type of 3D files with a PLY extension. In addition to these file types, Unity also supports various application files from external software like 3DsMax (.3ds), Maya (.ma), Blender (.blend), Cinema 4D (.c4d), Modo (.lxo), Lightwave (.iff), SpeedTree (.stf) and Cheetah 3D.
How to Import a 3D file into Unity
The import process is very simple and involves a few steps: open Unity 3D, click “File” then select Import New Asset… It will show all available 3d files on your computer that you can place in the 3D space of your game.
Another option is to keep your project files in an organized project structure. 3D models can be imported into Unity through a project’s file browser and then dragged to the 3D space of your game.
The Best 3D File Type for Unity
Can 3ds max plugin/script import 3DS Max files?
Yes, 3D Studio MAX can be used as 3dt animation software for 3DS Max files in Unity without exporting any changes to the original file format. The only difference is that if 3DX is your chosen 3d modeling software then you may need a .max conversion program, such as COLLADA before 3ds max plugin/script can import 3DS Max files.
Can 3D modeling software support more than one 3d file type?
Yes! The most popular 3d animation software like VFX (visual effects) game development, architectural visualization or medical imaging with 3dt capabilities for creating realistic 3D computer graphics, 3ds max plugin/script or Maya can support 3d files types like .max and 3dx.
Leah van der Walt
Leah is a 3D Artist & VR / AR Developer with 8 years of experience. Based in South Africa, she is a passionate teacher and loves to listen to drum and bass in her spare time.