Prim, layer и stage
Prim — элемент иерархического описания сцены. Его свойства могут содержать типизированные значения, связи и временные данные. Layer хранит набор описаний, а stage представляет результат их композиции. Слои USD не являются пиксельными слоями изображения: они задают сведения об объектах и их свойствах.
Практический пример: модель мебели хранится в одном наборе данных, материал — в другом, размещение в интерьере — в третьем. Художник света может добавить свой вклад, не переписывая исходную геометрию. Но команда должна договориться об именах, структуре и ответственности, иначе перенос конфликтов просто меняет форму.
Сборка и переопределения
USD предоставляет composition arcs, включая sublayers, references, payloads и variants. Они решают разные задачи: объединение слоёв, включение ассетов, отложенную загрузку и выбор вариантов. Правила силы определяют, какие данные попадут в итоговую сцену при нескольких мнениях об одном свойстве.
Важно не путать возможность переопределения с автоматическим исправлением зависимостей. Если поменялась топология модели, ранее подготовленные назначения могут потребовать проверки. USD сохраняет структуру изменений, но не способен сам понять художественный смысл всех связанных данных.
Большая сцена и рабочий набор
Payload позволяет отложить загрузку части содержимого. Это удобно, когда художнику нужен только участок большого окружения. При этом иерархия и правила композиции помогают работать с ассетом как с частью общей сцены. Выигрыш зависит от того, как проект разделён и какие данные действительно требуются текущей операции.
Практическая рекомендация: делите ассеты по производственным задачам, а не только по размеру файла. Слишком мелкие элементы увеличивают сложность управления, слишком крупные заставляют загружать лишнее. Измеряйте время открытия, обновления и рендера на характерной рабочей сцене.
Hydra и renderer — отдельные понятия
В экосистеме USD Hydra служит архитектурой взаимодействия данных сцены и render delegates. Наличие такого пути не делает все подключённые renderer одинаковыми. Каждый интерпретирует поддерживаемые схемы и собственные расширения, а отображение материалов и специальных эффектов требует проверки.
Если файл открывается без ошибки, это ещё не подтверждает полную визуальную переносимость. Procedural shader, volume или специальный атрибут могут оказаться недоступны принимающей стороне. Надёжный обмен описывает не только расширение файла, но и разрешённый набор схем, материалов и версий.
Практический контракт обмена
Сначала согласуйте масштаб, ось ориентации, временной диапазон, имена и разрешение путей. Затем экспортируйте небольшой ассет с характерными материалами и проверьте его в целевой среде. Только после этого переносите большой проект. Для архива сохраняйте исходники, зависимости и описание используемой конфигурации.
При сравнении изображения отдельно фиксируйте color management и renderer. Отличие beauty может появиться даже при правильно перенесённой геометрии. Результат проверки лучше формулировать конкретно: какие свойства дошли, какие преобразованы и какие потребовали ручной адаптации. Обещание «USD всё сохраняет» скрывает именно те границы, которые важны для производства.
Когда система оправданна
USD особенно полезен там, где сцена собирается из повторно используемых ассетов и над ней работают несколько дисциплин. Для единичного простого обмена может хватить более узкого формата. Выбор определяется необходимостью композиции и сопровождения, а не модностью аббревиатуры.