Демоверсии
Блог
Arnold
05 Марта 2021

Создание, управление и передача ассетов с помощью Arnold Stand-ins, USD и MaterialX. Первая часть

Применение возможностей MtoA в едином производственном конвейере на основе USD и MaterialX.

Автор: Дмитрий Чехлов

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

Еще одно важное условие – использование универсальных инструментов и обмен необходимыми данными для достижения желаемого результата. Каждая система визуализации использует несколько инструментов для сохранения и импорта данных. Таким образом, модель, созданная в Autodesk Maya и настроенная для визуализации с помощью Arnold Renderer, может быть экспортирована в отдельные файлы, представляющие геометрическую модель и материалы, а после импортирована в Cinema 4D или Houdini с применением C4DtoA и HtoA соответственно. Все это становится возможным благодаря инструментам экспорта и импорта данных в едином окружении Arnold Renderer. Инструменты идентичны как для MtoA, так и других реализаций Arnold Renderer.

Из данной статьи вы узнаете о мощном инструменте Arnold Operators, доступном в Arnold Renderer, и возможностях экспорта и импорта моделей в форматах Universal Scene Description (USD) и MaterialX. Это первая публикация, посвященная теме USD и MaterialX, дающая вводные сведения о форматах данных и их применении в Arnold Renderer.

Какие задачи решаем

Во-первых, стоит разобраться, для чего необходимы инструменты на основе форматов данных USD и MaterialX? Наиболее актуальным ответом будет создание архивов и ассетов, а также передача данных в другое приложение или далее по производственному конвейеру.

Второе, на что нужно обратить внимание, – подход применения инструментария и API Arnold Operators, который позволяет выполнять оптимизацию сцены с минимальным потреблением памяти и ресурсов рабочей станции, при этом, при грамотной подготовке сцены, упрощает управлять ей и устраняет зависимость от конкретного приложения.

На рисунке ниже приведен слайд из моей презентации, посвященной передаче данных с помощью Arnold Renderer между несколькими DCC-приложениями.

Autodesk

Связь между приложениями и различными редакциями Arnold с помощью форматом USD, Alembic, OSL и MaterialX

Как видно, модель и материалы могут быть переданы между каждым приложением с помощью форматов Alembic, MaterialX, OSL, USD и родного для Arnold *.ass. Помимо этого, применение возможностей USD, OSL и MaterialX, снимают границу в передаче данных между системами визуализации в целом, ведь каждый файл можно отредактировать.

Допустим, в одном проекте создается материал и набор текстур для Arnold Renderer. Но впоследствии, в новом проекте, используется RenderMan или 3Delight. Для передачи данных между системами визуализации вы можете создать универсальные материалы и связи с текстурами, а после передать их с помощью MaterialX и OSL. Благодаря USD стало возможным передавать данные со всем необходимым стеком объектов и материалов в такие пакеты, как Houdini Solaris и Clarisse iFX.

В этой статье мы рассмотрим основу – как представлены данные в USD и MaterialX, какие возможности Arnold Renderer поддерживаются, а также как использовать их для передачи между приложениями и изменять с помощью Arnold Operators.

В Arnold 6 начали реализовывать поддержку форматов USD и MaterialX, а многие разработки включаются в поставку напрямую из production houses, таких как The MILL, Industrial Light & Magic, Sony Imageworks и др.

Данная статья станет основной для наших дальнейших публикаций, в которых особое внимание будет уделено передаче данных с помощью формата USD и MetarialX. Сейчас поддержка формата USD доступна в Autodesk Maya 2020, Houdini 18, Blender, Cinema 4D и других, а особое внимание разработке инструментов поддержки USD уделяют компании Autodesk и Side Effects.

Введение в Universal Scene Description (USD)

Что такое USD и для чего был разработан данный формат данных? Основными приложениями, в которые он интегрирован, являются Autodesk Maya и SideFX Houdini, так как они активно используются студиями PIXAR и WDAS (Walt Disney Animation Studios).

Производственные процессы, используемые в создании фильмов с компьютерной графикой, обычно создают, хранят и передают большие объемы трехмерных данных, которые называются «описанием сцены». Каждое из множества взаимодействующих приложений в процессе (моделирование, затенение, анимация, освещение, эффекты, визуализация) обычно имеет свою особую форму описания сцены, адаптированную к конкретным потребностям и рабочим процессам приложения, и не может быть прочитано или редактировано любым другим приложением. Формат и инструменты Universal Scene Description (USD) являются первым общедоступным программным обеспечением, которое удовлетворяет потребность в надежном и масштабируемом обмене и расширении произвольных 3D-сцен, которые могут быть составлены из множества элементарных блоков (ассетов).

Autodesk

Страница формата USD в сети интернет

Формат USD предусматривает обмен ассетами (например, моделями) и анимацией. Но, в отличие от других пакетов обмена данными, также позволяет собирать и организовывать любое количество ресурсов в виртуальные наборы, сцены и снимки, передавать их из приложения в приложение и редактировать их не деструктивно (как переопределения) с помощью единого согласованного API, в одном графе сцены. USD предоставляет богатый набор инструментов для чтения, записи, редактирования и быстрого предварительного просмотра 3D-геометрии и затенения. Вдобавок, поскольку основной граф сцены и «механизм композиции» USD не зависят от 3D, USD может быть расширен удобным способом для кодирования и компоновки данных в других областях.

Формат USD является ядром конвейера для производства 3D-графики в PIXAR, используется во всех приложениях для моделирования и визуализации 3D-анимации, включая проприетарную систему анимации PIXAR Presto. PIXAR глубоко привержены развитию и совершенствованию USD, который позволяет решать разнообразные производственные задачи:

  • Предоставляет многофункциональный общий язык для определения, упаковки, сборки и редактирования трехмерных данных, облегчая использование нескольких приложений для создания цифрового контента. Как и многие другие форматы обмена, USD предоставляет низкоуровневую модель данных, которая на «уровне формата файла» определяет, как данные кодируются и организованы, а также набор (расширяемый) высокоуровневых схем, которые предоставляют значимые API и организацию для таких концепций, как геометрия или трансформация. На такой основе можно создавать кэш геометрии и материалов. Но USD идет дальше, предоставляя рекомбинантный набор «композиционных арок», которые можно использовать для упаковки, агрегирования, изменения и переопределения элементов примитивов и ресурсов с помощью высокопроизводительного механизма оценки времени выполнения, воплощенного в компактном графе сцены, известном как Stage, для разрешения результирующего «составного описания сцены» (composed scene description) и извлечения / создания из него данных.
  • Разрешает нескольким художникам совместно работать над одним ассетом и сценой. Основной аркой композиции в USD является оператор слоев нижнего уровня (subLayers operator), который позволяет нескольким художникам из одного или разных отделов одновременно работать над одним и тем же ассетом или сценой. При этом каждый художник работает в своем собственном файле (слое), после чего они будут объединены и допущены в «порядке значения», четко указанном в самих файлах USD. Эта способность автоматически настраивать данные затенения в более верхнем слое, когда художник по моделированию изменяет топологию геометрии, определенную в нижнем слое, не является чем-то особенным, но она позволяет каждому художнику работать независимо, не стирая и не редактируя работу других художников, и помогает обеспечить четкий контролирующий журнал изменений. Это помогает в решении таких проблем, как изменение топологии.
  • Максимизирует художественные итерации за счет минимизации задержек. Как и во многих других направлениях индустрии развлечений, одним из наиболее важных ингредиентов для создания высококачественного цифрового образа является возможность быстро и часто изменять дизайн, актив или анимацию. Одним из наиболее заметных препятствий для итераций в трехмерной графике является скорость, с которой художник может визуально получить обратную связь по результатам своих правок, и скорость, с которой он может переносить новые данные между несколькими приложениями или восстанавливать процесс, в котором произошел сбой. Скорость – основная постоянная цель проекта PIXAR USD. Компания продолжает изучать алгоритмические улучшения, более эффективные способы использования современных многоядерных систем и графических процессоров, а также методы сжатия для минимизации задержки при доступе к файлам в сети.

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

Что может делать формат USD

USD организует данные в иерархические пространства имен примитивов (в формате USD, prims – сокращение от primitive, далее в статье будет указываться как «примитивы» или «примы»). В дополнение к дочерним примитивам, каждый примитив может содержать атрибуты (attributes) и отношения или взаимосвязи (relashionship), вместе известные как свойства (properties). Атрибуты имеют типизированные значения, которые могут изменяться со временем. Отношения (взаимосвязи) – это многоцелевые «указатели» (pointers) на другие объекты в иерархии, и USD заботится об автоматическом переназначении целей, когда ссылка вызывает изменение пространств имен. И примитивы, и свойства также могут иметь метаданные (не меняющиеся во времени). Примитивы и их содержимое организованы в файловую абстракцию, известную как слой (layer).

Построенный на основе этого общего низкоуровневого описания сцены, USD предоставляет набор схем, которые устанавливают стандартное кодирование и клиентский API для таких общих концепций трехмерной компьютерной графики, как:

  • Геометрия. Схемы UsdGeom определяют (совместимые с OpenSubdiv) полигональные поверхности, трансформации, кривые, точки, поверхности NURBS и несколько вложенных твердых тел. Они также определяют концепцию произвольных primvars как атрибутов, которые могут интерполировать вдоль геометрической поверхности. Геометрические размеры и агрегированные, вычисляемые ограничивающие рамки (габаритные контейнеры); видимость обрезки и атрибут, называемый целью (purpose), который выражает (не анимируемую) условную видимость, полезную для развертывания LOD-прокси и управляющих.
  • Затенение. Схемы UsdShade определяют узлы примитивных шейдеров, которые могут быть объединены в графы и упакованы в материалы, на которых можно создать общедоступный интерфейс атрибутов, который будет управлять параметрами в содержащихся графах шейдеров. Хотя схемы UsdShade используются в подключаемых модулях USD для передачи затенения RenderMan из Maya в Katana, имейте в виду, что эти схемы постоянно меняются до выпуска формата USD 1.0.
  • Модель и ассет. Операторы композиции USD (USD Composition Operators) позволяют создавать комплексные сцены произвольных размеров. В качестве помощи в обработке, анализе и декомпозиции таких сцен USD формализует концепции модели и актива. Классификация примитивов model позволяет разбивать графы сцен на логические, управляемые блоки для обхода, управления рабочим набором и объединения / кэширования данных. Понятие asset проявляется в USD на двух уровнях: как основной тип данных для однозначной ссылки на внешний файл, который определяет, какие данные должны участвовать в асете / пути; и в схеме AssetInfo для размещения записи о том, какие активы были упомянуты в сцене, которая сохраняется, даже если сцена развернута.

Составление и замещение с помощью USD

Ниже приводится очень компактное описание семантики USD composition. В будущих статьях я дам более подробное, наполненное изображениями описание.

Вы можете «складывать» (stack) слои USD вместе с помощью арки компоновки слоев нижнего уровня, а движок компоновки будет открывать данные, содержащиеся в таких упорядоченных (вложенных) LayerStacks, аналогично тому, как составляются слои в Photoshop. Любой примитив в слое может также содержать одну или несколько ссылочных композиционных арок, которые нацелены на примитив в другом или том же слое и составляют дерево, основанное на целевом примитиве, в ссылающийся примитив – это основной способ собрать элементальные ассеты в агрегаты и полные сцены. Арка payload обеспечивает «отложенную ссылку», которую можно выборочно «загружать» (или «выгружать») из этапа после того, как этап был первоначально открыт. Разумное использование payload позволяет структурировать сцены так, чтобы клиенты могли легко управлять «рабочими наборами» (working sets), сохраняя в памяти только те части сцены, которые им необходимы для выполнения поставленной задачи. VariantSets позволяет создателю ассета объединять различные его варианты в единый пакет с «выбором вариантов», который последующие потребители активов могут переключать без разрушения на более сильных уровнях, чтобы изменить желаемый вариант. Любой примитив может определять несколько VariantSets, которые могут варьироваться по зависимым или независимым осям. Наконец, наследование и специализация композиционных арок устанавливают постоянные (через последующие, восходящие композиционные арки) отношения между базовым (base) и производным (derived) примитивом, так что производный примитив получает все переопределения, применяемые к базовому примитиву в любом месте сочинения. Техническая разница между наследованием и специализацией заключается в деталях, когда производные заключения win out находятся поверх базовых заключений, но практическая разница в том, что вы можете использовать наследование для простого mass edit всех экземпляров определенного класса примитивов или активов и специализации для создания derived, который всегда является specialized уточнением base во всех представлениях вашей сцены.

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

Переопределить следующее в отношении нижних слоев:

  • добавление новых примитивов, включая целые поддеревья, основанные на них;
  • деактивировать примитивы, что является подходом в USD для неразрушающего (и обратимого) удаления примитивов / поддеревьев;
  • изменение порядка примитивов, так как в некоторых контекстах упорядочивание пространства имен может иметь смысл;
  • добавить или удалить варианты в существующий набор вариантов;
  • добавить или удалить целые наборы вариантов или целевые объекты для наследования или специализации;
  • переопределение значения схемы и метаданных на уровне пользователя для примитива или свойства;
  • добавить новые свойства к примитиву;
  • изменить порядок свойств примитива (если это не указано явно, свойства перечисляются в порядке словаря);
  • заменить значение любого атрибута (предопределенное значение блокирует все более слабые timeSamples);
  • блокировать значение атрибута, чтобы у него не было авторского значения;
  • добавление, удаление и изменение порядка целей в взаимосвязях.

Наконец, USD предоставляет несколько функций на уровне графа сцены, которые могут значительно расширить типы и масштаб наборов данных, кодируемых в USD. Двумя наиболее известными являются собственное создание примитивов для очень компактного кодирования (и обработки) большого количества экземпляров / копий ссылочного ассета или примитива, применимого, когда копии не нуждаются в глубоком редактировании. И Value Clips, которые позволяют timeSamples набора примитивов быть разбросанными по многим файлам, а также (повторно) упорядочивать и восстанавливать временные интервалы неразрушаемые данным образом.

USD / Hydra для визуализации

Hydra – это фреймворк для визуализации, который поставляется как часть USD. Он соединяет несколько интерфейсов, которые работают с данными сцены, и несколько бэкэндов, которые отправляют данные сцены ядрам визуализации. Его первый и основной бэкэнд – это современный модуль визуализации на основе OpenGL, который является хорошо масштабируемым, многопроходным ядром визуализации и использует OpenSubdiv для визуализации тесселяции геометрии. Пакет также поставляется с простым path tracing трассировщиком лучей на основе Embree, который может служить примером для создания большего количества бэкэндов.

Интерфейс USD для Hydra используется в usdview и сторонних модулях расширения, включенных в пакет USD, и предназначен для обеспечения «достоверной» визуализации геометрии любой сцены, состоящей из примитивов, соответствующих схемам UsdGeom. Он также обеспечивает быстрый предварительный просмотр и потоковую передачу анимации для сцен в формате USD.

USD расширяемый и конфигурируемый формат данных

Несмотря на то что USD будет в первую очередь использоваться как встроенная подсистема, широта охватываемых им областей требует, чтобы он был расширяемым по ряду направлений. USD поставляется с собственным механизмом обнаружения модулей расширения и следует точкам модулей расширения:

  • Разрешение Ассетов (Asset Resolution). В сцене, на которую часто ссылаются, может быть выгодно иметь степень разделения между путями к ассетам, записанными в файлах USD, и «явным путем к файлу», из которого в конечном итоге будет загружен ассет. Интерфейс ArResolver может быть настроен для каждой установки USD, что позволяет, например, разрешить соглашения об именах для конкретного ассета и применить динамический контроль версий. USD поставляется с реализацией преобразователя по умолчанию, которая допускает простое разрешение ресурсов в стиле searchpath.
  • Форматы файлов. Слой USD можно плотно заполнять транслируемыми из любого совместимого формата файлов данными, реализовав для необходимого формата интеграцию модуля расширения SdfFileFormat. Таким образом реализованы собственные ascii и binary редакции формата USD, а также включенная поддержка чтения файлов Alembic через подключаемый модуль Alembic USD.
  • Схемы. USD включает в себя инструмент для создания новых схем (классов C ++, привязок Python и всего необходимого шаблона) из простого описания схемы в usd ascii. Это можно использовать для добавления новых типов схем примитивов USD и API в ваш конвейер или пакет, с которыми вы сможете взаимодействовать в своих плагинах уровня приложения, как если бы они были собственными схемами USD. Для типизированных схем, которые концептуально можно отображать, вы также можете научить фреймворк Hydra визуализировать их.

Что USD не умеет?

Нет GUIDS. USD использует текстовое иерархическое пространство имен для идентификации своих данных, что означает, что это «пути пространства имен» (namespace paths), с помощью которых переопределения связываются с их определяющими примерами / свойствами. Как следствие, когда внутреннее пространство имен ссылочного актива изменяется, переопределения более высокого уровня, ранее записанные в ссылаемых ассетах, отпадут. Одно из решений этой проблемы – идентифицировать данные по уникальному глобальному идентификатору (GUID), а затем связывать переопределения с тем же GUID, что и определяющий примитив. При решении проблемы редактирования пространства имен идентификаторы GUID вносят в конвейер другие проблемы и потенциально ограничивают гибкость композиции. В прошлых версиях USD компания PIXAR использовала форму GUID для детализации модели / актива, и тщательно взвесив все за и против, разработчики решили, что стоимость случайных операций с исправлением пространства имен распространяется на коллекцию of assets, и стоит заплатить за простоту создания и агрегации активов, а также за удобочитаемые представления асетов в ascii, которые получаются из путей пространства имен в качестве идентификаторов.

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

Кроме того, чем больше вариантов поведения и семантики выполнения будет добавлено к USD, тем сложнее будет успешно обмениваться данными между приложениями, поскольку в настоящее время между поставщиками ПО нет широкого согласия в отношении того, каким должно быть это поведение.

USD и его инструменты формирования схемы должны подходить для кодирования объектов для данных снаряжения в обоих направлениях в конкретном приложении или настраиваемом конвейере, а USD действительно предоставляет средства, которые клиент может использовать для создания более обширных кешей в памяти поверх UsdStage, чтобы обеспечить доступ с меньшей задержкой к данным, закодированным в USD. Но пока они не играют существенной роли в том, что, как считают разработчики, является основной директивой USD, а именно, как масштабируемый обмен геометрическими данными и данными затенения между приложениями в конвейере создания 3D-контента.

 

НАСЛЕДИЕ USD В PIXAR
Формат USD – это четвертое поколение composed scene description, разработанного в PIXAR. После «Истории игрушек», в которой каждый кадр описывался одним линейным программным файлом, начиная с «Приключения Флика» и продолжая следующими десятью художественными фильмами, команда разработчиков PIXAR начала добавлять и развивать концепции ссылок, наложения, редактирования и вариации в контексте своей собственной системы анимации Marionette (известной внутри как Menv).
К 2004 году стало ясно, что, хотя Marionette и стала достаточно мощной, ее органически возникшее происхождение стало препятствием для постоянного стабильного развития и способности студии использовать такие важные инструменты, как многоядерные системы. Студия взяла на себя обязательство спроектировать и разработать основную систему анимации второго поколения, теперь известную как Presto, которая впервые была использована в «Храброй сердцем», а после применялась и во всех последующих фильмах.
Одна из проблем с Marionette, которую намеревалась решить в Presto, заключалась в том, что ее различные функции для составления и переопределения описания трехмерной сцены не всегда могли эффективно использоваться вместе, потому что они были распределены между тремя различными форматами и «механизмами композиции». Presto представил второе поколение описания сцены, которое было унифицировано, позволяя ссылаться, переопределять, изменять и выполнять другие операции со всеми уровнями детализации от одного объекта до всей модели, среды или кадра, записанных в одном формате ascii и оцененных с помощью единого движка композиции.
Однако в то же время PIXAR, наряду с большей частью индустрии кино и спецэффектов, сочли выгодным перейти от конвейера, в котором анимация и оснастка сохранялись до рендеринга, к конвейеру, в котором они были запечены в эффективные «кэши поз» (pose caches), содержащие анимированные позиционные точки и преобразования, так что освещение, эффекты и визуализация могут уменьшить задержку (и объем памяти), с которой они могут получить доступ к данным. Следовательно, в 2008-2009 годах команда разработчиков конвейера начала создавать TidScene, геометрическую схему, поддерживаемую двоичной базой данных (Berkeley DB), с облегченным графом сцены в качестве механизма для создания и чтения данных с временной выборкой. Ключевые элементы TidScene включали высокопроизводительный (на то время) модуль визуализации с OpenGL, который позволял выполнять предварительную визуализацию прямо из TidScene во всех приложениях конвейера, а также разработку встроенной функции ссылок, которая использовалась (возможно, злоупотреблялась) для создания слоев, графа сцены, «изоляции» (т. е. загрузка только части сцены), ссылки на ресурсы и некоторой поддержки вариаций.
Скорость, масштабируемость и универсальный конвейерный доступ кэшей поз TidScene были успешными, но также вернули PIXAR в то место, где было несколько конкурирующих систем для создания составного описания сцены с разной семантикой, API и местами в конвейере, где их можно было использовать. Мандат для проекта USD, инициированного в 2012 году, заключался в объединении недавно переработанного и улучшенного механизма композиции и низкоуровневой модели данных от Presto с ленивым доступом, моделью данных с временной выборкой и облегченным графом сцены от TidScene. USD предоставляет совершенно новый граф сцены, который находится на вершине того же самого механизма композиции, который использует Presto, и ввел параллельные вычисления на всех уровнях описания сцены и ядра композиции.
Ключевым компонентом проекта USD была разработка ультрасовременной масштабируемой архитектуры визуализации с помощью OpenGL, получившей название Hydra. Hydra поставляется как часть проекта USD, потому что добавляет огромную ценность к применению USD в конвейере и используется во всех модулях расширения, а также предоставляет эталон и справочник о том, как использовать многопоточность USD для быстрой загрузки сцены и визуализации. Как эффективное обновление в ответ на динамическое редактирование UsdStage. Тем не менее, Hydra является самостоятельным продуктом и уже имеет другие прямые внешние связи, отличные от USD (включая Presto и модули для Maya и KATANA), и выходит за рамки своей оригинальной архитектуры, основанной на OpenGL, для обслуживания других компонентов, например, клиенты, отслеживающие пути.
поделиться
Для сбора статистики по работе PointCGI, мы cобираем данные о пользователях. Используя PointCGI, вы соглашаетесь с нашей политикой обработки персональных данных, включая технологию cookie.