какие форматы моделей поддерживает unity3d
Unity и интерактивная графика
• Для классификации инструментов можно выделить три основных признака. Является ли инструментальное средство стандартной частью редактора Unity, инструмент не является частью стандартного инструментария, но является расширением, встраиваемым в Unity. Инструмент вообще не является частью среды разработки Unity, но прекрасно интегрируется в пайплайн Unity. Немаловажной особенностью можно считать взаимозаменяемость отдельных инструментальных средств. Всё это обеспечивает достаточность выбора.
• Другой важный фактор – это трансферные форматы файлов, которые можно использовать совместно с Unity и для обмена данными между редакторами. Для Unity предусмотрены интерпретаторы для исходных форматов файлов разных редакторов- lxo, mb, ma, max, dxf, 3ds, dae, Blend, obj, и др., но стандартом является FBX, при помощи которого переносятся как модели, так и анимация, включая скелетную и вертексную (морфинг), так же группы сглаживания UV сеты, вертексный цвет и многое другое. Есть специфические форматы для параметрической генерации контента – это SBSAR и OTL. Имеется возможность создавать свои интерпретаторы для импорта и экспорта других файловых форматов, либо использовать сторонние. Как пример, можно использовать интерпретатор формата MDD для использования кэша вершинной анимации в Unity, создавая такой кеш в каком-либо анимационном редакторе.
• Unity не обладает встроенной системой моделирования и текстурирования. Эта часть работы выполняется в традиционных средствах моделирования и текстурирования. Спектр этих средств велик. Maya, Modo, и.т.д.
• Всё же для Unity предусмотрены простейшие инструменты моделирования и редактирования UV развёрток. Эти средства поставляются сторонними разработчиками. Некоторые из них распространяются свободно. К примеру, Game Draw и UV Editor Pro.
• Физика и физические симуляции. Часть разработчиков избегают физических симуляций в реальном времени, а другие, напротив, выстраивают вокруг этого весь проект. Unity использует PhysX, а сами физические атрибуты очень важны для интерактивной графики. К примеру, габариты столкновений (colliders) используются не только для физики, но и для обеспечения интерактивности этих объектов. Объект перестаёт быть просто 3D объектом, когда ему присваивается collider. Объект становится участником событий в сцене. Сквозь него нельзя пройти, его можно кликнуть и получить информацию или какое- то действие. Это отличает интерактивную графику от традиционной, где важно только внешняя видимость симуляции физических свойств с конечным, ожидаемым визуальным эффектом.
• Шейдинг. Магию шейдеров трудно переоценить. До сих пор многие CG художники полагают, что качество картинки ограничено рамками редактора материалов и механизмом отрисовки финального изображения на мониторе. Это не совсем так. Качество графики, в первую очередь, зависит от реализации шейдеров, которые отдают инструкции видеокарте или рендеру, как следует отрисовывать освещение и затенение на объекте, как отрисовать текстурные каналы, как должно работать отражение или преломление. Непонимание роли шейдеров в качестве изображения, порождает миф о том, что графические возможности Unity ограничены тем качеством, что достижимо при использовании стандартного набора шейдеров, распространяемого вместе с пакетом. Эти стандартные шейдера, следует рассматривать как примеры того, от чего можно отталкиваться при написании своих, уникальных шейдеров. Для этого используется классический CG language, именуемый так же, как Си для графики. Однако не для каждого художника видится возможным нырнуть в особенности написания кода на CG. По этой причине, появились (и продолжают появляться) разные редакторы шейдерной логики, где применяется традиционное нодовое редактирование. Это гораздо ближе для 3D художников. Наиболее интересные редакторы шейдерных «деревьев» (редакторы шейдеров)- Stumpy, Fusion и Forge. Хотя, следует отметить, что наиболее продвинутые результаты в шейдинге достигаются через работу с кодом. Интерактивная графика предполагает, так же, возможность производить изменения на уровне материалов поверхностей в реальном времени. Это достижимо при обращении к шейдеру через материал. Так, что интерактивность материалов для поверхностей объектов- это особая сфера внимания для интерактивной графики. Шейдеры нужны не только для материалов, но и для фильтров обработки итогового изображения. Эти фильтры обрабатывают картинку на высокой частоте fps и на них приходится большая доля увеличения качества итогового изображения
• Визуальное программирование применяется в таких программах как Houdini и Grasshopper для Rino. В редакторе движка UDK, тоже имеется такое средство- Kismet. Визуальное программирование предполагает конструирование алгоритмов исполняемых сценариев при помощи редактора графов. Каждый отдельный оператор имеет визуальный вид ярлыка со слотами для входящих и исходящих данных, и называется узлом (node). Последовательность таких узлов- операторов, соединённых связями входящих и исходящих данных (графами), образует древовидное ветвление сценария и называется дерево графа (Graph Tree). Почти во всех 3D пакетах есть такие редакторы графов, при помощи которых можно настроить шейдинг материалов. Unity позволяет использовать нодовые редакторы для создания скриптов, как альтернативу традиционному написанию кода. Во первых это uScript Visual Scripting, который полностью имитирует Kismet. Имеются и другие аналоги- Antares Universe (VIZO), Playmaker, и др. Польза от таких редакторов в том, что помогает людям с образным, а не абстрактным складом мышления, комфортно работать со скриптингом. Можно сразу видеть всю структуру алгоритма, а это важно для «правополушарных» художников. Автор Antares VIZO, как-то сказал, что сподвигло его создать такой фундаментальный инструмент визуального программирования: «Мне гораздо удобней видеть алгоритм в визуальном виде», т.е., по сути, он создавал инструмент для себя. Также и команда разработчиков uScript, привыкшая иметь дело с Kismet, решила создать для себя подобную среду для Unity. Всё же многие профессиональные программисты критично относятся к подобному способу программирования и проповедуют традиционное написание кода. У такой позиции есть весомые аргументы, но одно другому не мешает. Можно использовать весь набор средств.
• 2D. Стоит упомянуть, что Unity имеет особую популярность у разработчиков 2D игр. Было время, когда разработчики игр на Flash, выражали массу сомнений, что Unity сможет соперничать с Flash в разряде 2D игр. Потом Unity покусилась на формат Flash, используя Molehill. Теперь, когда стало ясно, что формат flash больше не будет развиваться и поддерживаться, многие разработчики и художники обратили свой взор на Unity, как самую преемлемую среду создания 2D игр. Последняя версия Unity, предоставляет спектр фитч для реализации 2D приложений и игр. Продвинутый генератор спрайтов, спрайтовая анимация, физика для 2D, использование Mecanim для 2D анимации.
Описание Формата
Формат сцен Unity реализован при помощи языка сериализации данных YAML. Хотя мы не можем рассмотреть здесь все особенности YAML, это открытый формат, и его спецификации доступны бесплатно на сайте YAML. Каждый объект в сцене записан в файл как отдельный YAML документ, который представлен в файле через последовательность —. Заметьте, что в данном контексте термин “объект” обозначает GameObjects, Components и другие данные сцены в совокупности; каждый из этих объектов требует собственный YAML документ в файле сцены. Базовая структура сериализованного объекта может быть объяснена из примера:-
Первая строка содержит запись “!u!1 &6” после маркера документа. Первое число после “!u!” обозначает класс объекта (в данном случае, это GameObject). А число, следующее за амперсандом, это идентификационный номер объекта (ID), уникальный внутри файла, хотя и назначающийся каждому объекту произвольно. Каждое сериализуемое свойство объекта обозначается линией, такой как эта:-
Это Transform компонент, присоединенный к игровому объекту (GameObject), определенный через YAML документ выше. Присоединенная часть обозначается линией:-
Числа с плавающей точкой могут быть представлены в десятичном виде или как шестнадцатиричное число в формате IEE 754 (обозначенные префиксом 0x). IEE 754 представление используется для кодирования значения без потерь, и используется Unity при записи значений, которые не имеют короткого десятичного вида. Когда Unity записывает числа в шестнадцатиричном виде, они также записываются в десятичном виде в скобках в целях отладки, но только первый вид считывается при загрузке файла. Если хотите отредактировать эти значения вручную, просто уберите шестнадцатиричное число и введите десятичное. Вот несколько корректных примеров записи чисел с плавающей точкой (все представляют число один):
Свойства обычно идут с префиксом “m_”, но в остальном следуют имени свойства, которое определено в справке по скриптам. Второй объект, определенный ниже в файле, может выглядеть следующим образом:- …поскольку GameObject ID в файле был 6.
Как мне импортировать модели из моего 3D редактора?
Для импорта 3D модели в Unity вы должны перетащить файл модели в окно проекта.
В инспекторе > вкладка Model Unity поддерживает импорт моделей из всех популярных 3D редакторов.
Особенности импорта из разных 3D пакетов смотрите на следующих страницах:
Текстуры
3D форматы
Импортирование мешей в Unity может быть выполнено с помощью двух основных типов файлов:
Любой из этих типов позволит вам добавлять свои меши в Unity, но есть соображения относительно того типа, который вы выберите:
Экспортированные 3D файлы
Преимущества:
Недостатки:
Собственные файлы 3D приложений
Преимущества:
Недостатки:
Модели
Файлы моделей, размещенные в папке Assets внутри проекта Unity, автоматически импортируются и сохраняются как ассеты Unity.
Файл модели может содержать 3D модель персонажа, здания или части мебели. Модель импортируется в виде набора ассетов. В окне Project(проект) главный импортированный объект представляется в виде Model Prefab(префаб модели). Обычно также существует несколько Mesh объектов, на которые ссылается Model Prefab.
Файл модели может также содержать данные анимации, которые можно использовать для анимации данной модели или других моделей. Данные анимации импортируется как один или несколько Анимационных Клипов.
Настройки импорта для мешей
Import Settings для модели будут показаны в закладке Model инспектора FBX импортера, когда модель выделена. Это влияет на меш, его нормали и импортированные материалы. Настройки применяются для каждого ассета на диске, поэтому, если вам нужен ассет с другими настройками, создайте (и соответственно переименуйте) копию файла.
Хотя изначально настроек по умолчанию может быть достаточно, будет лучше, если вы изучите список настроек, перечисленных ниже. Они могут помочь определить, что вы желаете сделать с игровым объектом.
Некоторые общие корректировки, для примера, могут быть следующими:
Руководство экспорта FBX
Unity поддерживает FBX файлы, которые могут быть получены из многих популярных 3D-приложений. Используйте эти указания, чтобы гарантировать лучший результат.
Select > Prepare > Check Settings > Export > Verify > Import
Что вы хотите экспортировать?
Будьте внимательны при экспорте контекстов, например, мешей, камер, источников света, рига анимаций и т.д.
Что вам следует включать в экспорт?
Подготовьте ваши ассеты:
Как мне включить в экспорт эти элементы?
Проверьте настройки экспорта FBX
Какую версию FBX вы используете?
Используйте последнюю версию FBX по возможности.
Autodesk регулярно обновляют их инсталлятор FBX, что может привести к разным результатам с разными версиями их собственного ПО и других сторонних 3D приложений
Версию можно посмотреть в Advanced Options > FBX file format
Если вы столкнулись с какими-либо проблемами, то при необходимости вы можете откатиться до версии 2012.2
Будет ли оно работать?
Проверьте ваш экспорт
Импорт!
Пример диалогового окна FBX из Maya:
General, Geometry и Animation 
Lights, Advanced options
Unity: Сборка под Android или «размер имеет значение»
В некоторых случаях необходимо работать над снижением размера сборки для Андроид. Например, установка тяжеловесных APK для пользователей мобильного интернета может влететь в копеечку. Превышение размера APK в 50 Мб в Google Play выливается в дополнительные трудности при аплоаде.
Мы разрабатывали под Андроид на Unity 2D-игру, которая изобилует картинками (большинство с областями прозрачности) и разнообразными звуками, и столкнулись с проблемой размера APK. Забегая вперед скажу, что решив ее и снизив вес в 1,5 раза, мы получили в 1,5 раза больше скачиваний. Заставляет задуматься, не правда ли?
Пытаясь побороть проблему приложений-тяжеловесов, мы обратились к замечательной документации от Unity. Выяснилось, что там данная тема обсуждается лишь вскользь. Упоминается, какие именно аспекты влияют на размер сборки и как воздействовать на эти аспекты, чтобы сделать APK меньше, а также приведено немного конкретики по поводу настроек импорта изображений.
Другую полезную информацию по данному вопросу в интернете мы практически не нашли. Потому провели небольшое исследование, результатами которого спешим с вами поделиться.
ИЗОБРАЖЕНИЯ
Уточним насчёт изображений. В нашей игре соблюдается принцип pixel-perfect. Все изображения без альфа-канала имеют плавный градиент. Остальные изображения с прозрачностью, а непрозрачные области тоже имеют плавный градиент.
Проанализируем, какой вклад в размер АРК вносят изображения в формате PNG и JPG.
Картинки в формате PNG
Далее мы сохранили первую картинку в Photoshop с настройками: Compression->None/Fast, Intrelaced: Yes. Получили файл размером 9000 Кбайт, однако в сборку он добавил те же 236 Кбайт.
Это подтверждает слова из документации, о том, что Unity перекодирует все ассеты во внутренний формат. Очевидно, он приблизительно соответствует формату PNG, сохранённому в фотошопе с настройками: Compression->Smallest/Slow, Intrelaced: No. И Unity перекодирует все PNG в этот формат, независимо от начального формата файла.
Картинки в формате JPG
Опыты однозначно показали, что изображения JPG вносят вклад в размер сборки пропорционально своему размеру. Пока не совсем понятно, как ведёт себя Unity в случае, если ассет находится в формате JPG. Мы сохранили ту же самую (первую) картику в JPG и получили очень маленький файл на файловой системе (75 Кбайт). Однако в сборке он занял непомерных 767 Кбайт (*).
Мы проводили эксперимент на большом количестве разных картинок, здесь я привожу лишь малую часть исследований. В других экспериментах нам наоборот удавалось снизить общий размер сборки конвертированием всех файлов из PNG в JPG.
Причин этого явления выявить пока не удалось.
Скорее всего, снова имеет место внутренний формат Unity, однако точные принципы взаимодействия колдовского механизма Unity с ассетами JPG выяснить пока не удалось.
Еще один способ работы с JPG будет описан ниже.
ЗВУКИ
Для звуков значение имеют две настройки импорта: Audio Format и ForceToMono.
Файлы в формате WAV занимают больше места в сборке, чем файлы в формате MP3 (вклад в размер сборки приблизительно равен размеру файла). Стерео WAV файл займёт меньше места, если выставить ForceToMono = true. Точно такого же эффекта можно достичь, если конвертировать файл в «моно» ещё до импорта (тогда ForceToMono не будет доступна в инспекторе).
Однако если для файла WAV установить настройку импорта AudioFormat = Compressed, то в сборке он займёт места столько же, сколько и соответствующий MP3 файл высшего качества (Audacity: variable bitrate, 220-260 kbps). То есть Unity самостоятельно кодирует звук в формат MP3.
Для файлов в одинаковом формате действует принцип прямо пропорционального вклада в размер сборки.
Остальные настройки импорта на размер сборки никак не влияют. Они влияют на количество места, занимаемое звуком в RAM.
А ТЕПЕРЬ О КОНКРЕТНЫХ ШАГАХ К НАШЕЙ ЦЕЛИ
Таким образом, совет: для снижения нагрузки на ОЗУ
* избегать больших областей прозрачности в изображениях;
* не формировать атласы с большими участками прозрачности, особенно в NGUI.
(Но это мы отвлеклись от основной темы.)
Несколько слов о dll
Документ приводит список обязательно включаемых в сборку dll и призывает минимизировать количество дополнительных dll (особенно тяжёлых). В частности, по возможности не использовать System.dll (добавляет к APK 2 Мбайт). Однако даже если мы будем избегать ссылок на методы из этой библиотеки, System.dll всё равно (по состоянию на Unity 4.5.5) включается в сборку, так как её подтягивает обязательная Mono.Security.dll. Потому, получается, что официальная документация Unity в этом месте не совсем релевантна.
А вот использования других (необязательных) dll желательно избегать во имя снижения размера сборки.
На сегодня у нас всё. Спасибо за внимание!
(Просьба рассматривать данный материал как более-менее систематизированные результаты исследования, а не как универсальное руководство к действию. Буду очень рад комментариям, замечаниям, конструктивной критике, возражениям, предложениям, дополнениям. И, конечно, несказанно рад буду узнать, какие приёмы применяют коллеги из других компаний для решения обсуждаемого вопроса.)