Что такое коллада файл

Обновлено: 07.07.2024

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

Файлы COLLADA являются XML представлением 3D-объекта, который может иметь ссылки на дополнительные файлы изображений, ведущих себя как текстуры, драпированные в 3D геометрию. Это означает, что экспорт объекта типа мультипатч в COLLADA может привести к созданию нескольких файлов: файла .dae , содержащего XML представление 3D-объекта, и один или несколько файлов изображений (например, файл .jpg или .jpg ), содержащих текстуры.

Этот инструмент создает одно представление COLLADA для каждого объекта типа мультипатч, который он экспортирует. Инструмент использует значение поля из каждого пространственного объекта (по умолчанию, это поле Object ID) для определения имен выходных файлов. Это позволяет облегчить определение того, какой пространственный объект был экспортирован в какой файл COLLADA, а также предоставляет методы для определения уникальных имен при экспорте нескольких пространственных объектов в ту же директорию. Файлы текстур хранятся в той же директории, что и файл COLLADA. Для уменьшения общего размера файла экспорта текстуры, которые используются в нескольких файлах COLLADA – например, повторяющиеся строительные блоки или окна, экспортируются только один раз и указываются в соответствующих файлах DAE.

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

При повторным обновлении объекта типа мультипатч путем экспорта его в COLLADA и выполнении изменений вне ArcGIS, каждый раз экспортируйте пространственный объект в то же местоположение. Это сохранит один файл на диске для этого пространственного объекта, представляющего самое последнее состояние 3D-объекта.

Если экспортируемый мультипатч – в системе координат проекции (например, здание, хранящееся в зоне UTM, то файл KML, содержащий координаты WGS84, также будет создан в выходной папке. Обратите внимание, что в этом процессе не будет использоваться трансформация датума, которая может привести к позиционным расхождениям при отображении KML.

Подсказка:

При конвертации мультипатчей из слоя инструмент Мультипатч в COLLADA автоматически вносит цвета, определенные в методе отображения слоя. Например, если слой представляет собой объекты отображения на основании атрибута использования, например, красный для коммерческого, синий для жилого и т.д., то такие цвета будут включены в выходной файл COLLADA. Отображаемый цвет применяется и к текстурированным, и к нетекстурированным объектам-мультипатчам, при этом последний требует обновления файлов базовой текстуры объекта. Вы можете использовать один цвет отображения – белый – для экспорта текстурированных мультипатчей с неизмененными изображениями.

В первой статье я б хотел поведать о том с чего впервую очередь начинает gamedever, а именно с вопроса: "Какой выбрать формат файла, для экспорта 3d модлей в свою игру ?". К примеру 3ds max экспортирует сцену в такие форматы как 3ds, obj, wvf и т. д. . Но перепробывав все форматы макса я понял что с ними работать начинающему gamedever-y очень сложно. В сети я нашел очень удобный и распростарненный формат Collada - его простота в первую очередь вызвана тем что этот формат хранит данные по 3d модели в текстовом варианте - в XML.

Plugin Collada для 3ds Max 2009 32 bit + Спецификация Collada (ENG) можете скачать здесь.

Итак: сегодня я расскажу как удобней и проще прочитать файл collada, и приведу примеры своего кода.

Collada Parser:

Как сделать Collada Parser своими руками ? Какой алгоритм самый оптимальный ? Что представляет собой файл Collada *.dae ?
Вот о чем сейчас я хочу более подробно рассказать.

Конечно же, уже существуют такие парсеры как Collada DOM и т.д., но покопавшись в мануале этого парсера я понял, что нужно убить как минимум 5-6 дней что бы понять как работает тот же DOM. В связи с этим решил написать свой парсер конечно же менее функциональный, но зато он экспортирует те данные, которые мне действительно неободимы, а не все то что выплёвывает 3ds max при экспорте в Colllada.

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

Я упомянул о том, что мой двиг имеет возможность экспортирования данных из файла *.dae (Collada) – это и был парсер встроенный в мой двиг. Однако всё дальше углубляясь в программирование своей игры, я понял, что наличие данной возможности в двиге игры совсем не обязательно, и даже неудобно. Хотя на начальных стадиях разработки движка было очень удобно вносить корректировки и добавлять новые функции для моего парсера, но чем дальше тем больше он начал жрать памяти, так как появлялись данные, которые я просто боялся удалить ! А вдруг чего-нить перестанет работать и тогда будет ой как сложно найти дырку в коде, да и ещё её и залатать. :(

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

Кому нравиться так, а по мне так Collada *.dae – Это текстовый файл, легко читаемый (ибо текстовый :) ), состоящий в виде иерархии, где имеються родительские блоки родственные блоки и блоки дети, которые в свою очередь имеют родителей, детей, родственников и т. д. (более подробно см. далее). Блоки имеют заголовок (хидер) и конец к примеру главный и самый корневой блок Collada, который начинается с заголовка (хидера) <Collada> и конца </Collada>. Я думаю комментарии излишне, сразу же видно в чем разница между заголовком и концом. Однако очень часто в заголовке содержаться дополнительные поля, в которых описано, что храняться между началом и концом данного блока.

''), array("string" => ''), ); if (!isset($_COOKIE['rek'])) < print($banners[$GLOBALS["banner_num"]]["string"]); >elseif ($_COOKIE['rek'] == "rek1") < print($banners[0]["string"]); >elseif ($_COOKIE['rek'] == "rek2") < print($banners[1]["string"]); >?>

У меня иногда спрашивают, в чём разница между форматом FBX и Alembic. И вот месяц назад я нашел статью, которая отлично отвечает на этот вопрос: чем отличаются форматы для 3D данных Элембик и ЭфБеИкс. Правда, статья на английском, поэтому, вместо того, чтобы просто дать ссылку, я решил её перевести 🙂

FBX - это формат обмена 3D данными, который впервые придумали в Kaydara и он использовался для обмена с FiLMBox. Впоследствии FiLMBox был переименован в MotionBuilder , а Kaydara была куплена Автодеском. FBX развивался сперва для того, чтобы:

затягивать данные motion capture (сделанные в FiLMBox) внутрь 3ds Max, Maya и Softimage 3D (до XSI);
потом чтобы экспортировать риг и геометрию в FiLMBox;
а затем и обмениваться 3D информацией в процессе DCC (Digital Content Creation - создание цифрового наполнения), в обход MotionBuilder.

геометрию (вершины, NURBS и patch
материалы,
текстуры,
деформацию,
анимацию,
ограничители (constraints) и IK (цепочки инверсной кинематики),
а также этот формат могут расширять другие компании.

Collada

Это формат, который по принципу использования, по целям создания и возможностям близок к FBX. Разработан Feeling Software (теперь Fortem ), а сейчас поддерживается Khronos group . Всё что сказано об FBX в этом посте также справедливо и для формата Колада.

Alembic

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

“ALEMBIC - это открытый формат обмена, который становится индустриальным стандартом для обмена анимированной компьютерной графикой между пакетам по созданию цифрового контента.”

Это громкое и вводящее в заблуждение заявление! Стандарт для какой индустрии?

Должно выглядеть так "компьютерной графики для кино индустрии". Ключ к пониманию находится в секции " What is Alembic " (привожу выдержку):

ни наследуемым, ни процедурным инструментом для трансформации данных;
заменой родных форматов сцен 3D-приложений;
приложением по управлению ассетами (цифровыми объектами);
решением для хранения рига.

Однако, FBX и Collada пытаются поддерживать всё выше сказанное. Это объясняет метафору с яблоком и апельсином в начале статьи.

Alembic не является… FBX'ом или Коладой!

К слову, FBX/Collada делают честную работу, поддерживая всё на сколько возможно. Из-за этого на них вываливается много незаслуженного гнева.

Попробую пролить немного света на то, как разные индустрии по разному работают с DCC.

Игровая индустрия.

Художник создаёт ассеты и уровни в процессе DCC и они используются в игровом движке. Поскольку процесс разработки итерационный (повторяющийся) и все работы выкладываются одновременно в тестовой среде, то лучше, чтобы визуальное представление во вьюпорте DCC было такое же, как и в игровом движке, включая деформации, ограничения, ИК и т.д.

Индустрия архитектурной визуализации.

Художник создаёт картинку в процессе DCC на основе импортированных ассетов из архитектурных пакетов, таких как AutoCAD, Revit, SketchUp и т.д. Архитектор постоянно обновляет свои ассеты, а визуализатор пытается упростить свой пайплайн, чтобы иметь возможность вносить (вручную) изменения. Alembic можно было бы использовать для одного кадра высококлассной визуализации, когда нужно данные перебросить в другой пакет для освещения и рендеринга.

Кино индустрия.

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

Вывод такой: Alembic - это

отличный посреднический формат, когда вы можете отделить работы по сетапу от других процессов производства, как например, при создании фильмов.
не заменитель таких повседневных форматов по перебросу данных как FBX или Collada.

Подпишитесь на обновление блога (вот 3 причины для этого).

Это мой перевод статьи FBX/Collada vs Alembic от Jean-Francois Yelle из Quadernii.

Похожие статьи:

Вам понравилась статья ? Хотите отблагодарить автора? Расскажите о ней друзьям.
Или подпишитесь на обновление блога по E-Mail.

Так же FBX поддерживает несколько наборов UV-Разверток применимых к одному объекту — что немаловажно для работы в сфере Геймдева.

Can you please mention my name as the author and Quadernii as the corporation from which this post originate? many thanks.

Я готовлюсь написать импортер COLLADA на Java. Нет никаких заранее написанных импортеров, и даже если бы они были, я, вероятно, был бы разборчив, поэтому я считаю, что это лучше всего. Я собираюсь с COLLADA 1.4, потому что мне не нужны функции 1.5, и многие программы еще не поддерживают его. Я нашел spec для него и планируйте следовать ему, но гораздо проще следовать примеру и ссылаться на спецификацию для получения дополнительной информации.

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

кроме того, я знаю, что Blender может экспортировать COLLADA 1.4, и он может импортировать большинство форматов. Если у вас есть действительно хорошее предложение для сайта, который имеет простые 3D-модели в другом формате, которые я просто импортирую и экспорт как COLLADA, это тоже было бы хорошо!

Я знаю по крайней мере два приличных места:

на сайте google есть много файлов collada, thingiverse имеет больше файлов stl (sterio lithography).

проблема здесь в том, что, насколько я знаю, нет инструмента (по крайней мере, доступного для общественности), который поддерживает полную спецификацию Collada (особенно 1.5). Часть, которая в большинстве случаев хорошо протестирована и разработана,-это элемент геометрии-библиотеки, материалы и т. д., которые в 1.5 обычно взяты из некоторой реализации 1.4 (вот почему инструменты, которые обычно утверждают, что они поддерживают 1.5, на самом деле не делают (физика, кинематика и т. д. в большинстве случаев отсутствуют или находятся в плохом состоянии). Еще вы можете легко создавать достойные (как в геометрии часть в порядке, но остальное - может быть, есть, может быть, нет) достаточно файлов Collada, используя различные экспортные функции, в первую очередь 3D-моделирования (Blender, Maya, 3ds Max, CATIA и т. д.). OpenRAVE (используется для планирования пути робототехники) фактически имеет одну из лучших возможностей экспорта/импорта, когда дело доходит до COLLADA и даже поддерживает (частично) 1.5 функции, такие как кинематика.

Если вы решили использовать блендер например (бесплатный и с открытым исходным кодом, так что вы можете на самом деле посмотрите, как работает аддон импорта/экспорта), вы можете создать что-то простое или сложное и экспортировать его как COLLADA 1.4 (а не 1.5!). OpenRAVE, например, использует пользовательский XML-формат, который преобразуется внутренне в Collada (чтобы скрыть сложность этого стандарта) и позволяет даже вставлять другие форматы (в основном для геометрической части), такие как OBJ, для которого намного проще найти инструмент импорта/экспорта decend. Khronos Group фактически предоставляет OpenCollada (OpenRAVE и многие другие используют его внутренне, что, конечно, приводит к ошибкам во всех из них, когда что-то плохо реализовано в OpenCollada :P). Assimp-библиотека предлагает также довольно много, но основная проблема заключается в дезинформации, которую она дает о том, что она фактически поддерживает из стандарта Collada. На самом деле очень, очень трудно найти ссылку на реализованные функции, когда дело доходит до Collada, и, к сожалению, недавно я начал использовать 1.5 (кинематика), чтобы обнаружить, что Assimp поддерживает только 1.4 и привязан к нему такой степени, что он бросает ошибки на вас в тот момент, когда он встречает обычно 1.5 элемент (даже если он пуст!), который omho является действительно плохой реализацией со стороны разработчиков. В списке поддерживаемых форматов на сайте Assimp указано только Коллада и версия не дали.

Читайте также: