Прекратите перестраивать колесо: Как масштабировать конвейер преобразования CAD-моделей в 3D-модели

Многие инженерные команды столкнулись с одной и той же проблемой. Файлы САПР накапливаются. Процесс написания отзывов замедляется. Те, кому нужно увидеть модель, не могут её открыть, а те, кто может её открыть, не имеют времени, чтобы преобразовать её для всех остальных.

Это руководство предназначено для всех, кто столкнулся с подобной проблемой: 3D инженеры, дизайнеры, разработчики и ИТ-специалисты, оказывающие им поддержку. В нем подробно разбирается, что требуется для масштабируемого процесса преобразования CAD-моделей в 3D-модели реального времени, почему специальные скрипты и разовые преобразования перестают работать в больших масштабах, и приводятся примеры компаний, которые решили эту проблему в производственной среде.

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

Для кого предназначено это руководство?

3D инженер, дизайнер или разработчик: это техническое описание того, что должен делать конвейер обработки данных.

Директор ИТ-отдела или директор по проектированию данных: здесь рассматриваются вопросы управления, стоимости и масштабируемости, которые важны для вас.

Обе группы преследуют общую цель: извлечь сложные 3D данные из разрозненных источников и надежно и многократно передать их тем, кто в них нуждается.

Глава 1: Разрыв между реальностью и данными — почему данные САПР оказываются разрозненными.

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

Большинство организаций так не работают. Дизайнеры и инженеры создают продукцию будущего с помощью специализированных инструментов САПР. Все остальные члены команды, от маркетологов до руководителей производства, просматривают чертежи и статичные слайды. В Unity это несоответствие называют разрывом в реальности : зачастую только тот, кто лучше всего понимает модель, может её преодолеть.

Существует три конкретных препятствия, которые создают разрыв между реальностью и реальностью:

• Инструменты. Системы автоматизированного проектирования (CAD), управления жизненным циклом приложений (PLM) и системы реального времени редко говорят на одном языке «из коробки». Каждая передача данных между ними сопряжена с риском потери информации или необходимости ее ручного восстановления.
• Время. Преобразование и оптимизация одной сложной сборки вручную может занять несколько дней. Умножьте это на сотни узлов и десятки производственных линий, и объем невыполненных заказов может оказаться значительным.
• Экспертиза. Люди, умеющие перемещать данные между этими инструментами, зачастую представляют собой небольшую группу специалистов. Когда они заняты или когда уходят, работа над проектом останавливается вместе с ними.

Ни одна из этих проблем не нова. Изменилась лишь цена игнорирования этих проблем. Продукция стала сложнее. Циклы рецензирования более распределены во времени, часто охватывая разные часовые пояса и дисциплины. И все чаще ожидается, что 3D модель будет обновляться так же быстро, как и исходный файл, из которого она была получена.

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

Глава 2: Что означает масштабируемость для 3D конвейера?

Любой процесс преобразования CAD-модели в 3D-модель легко назвать конвейером. Создать масштабируемый продукт сложнее. Разница сводится к пяти этапам, каждый из которых должен проходить без необходимости каждый раз переделывать его вручную.

1. Приём внутрь. Конвейер обработки данных должен принимать любой формат, который фактически использует команда проектировщиков, будь то инструмент САПР для проектирования механизмов, пакет BIM, облако точек, полученное в результате сканирования, или сетка, экспортированная из другого движка.

2. Конвертировать. Параметрические данные САПР и полигональные данные 3D моделирования в реальном времени — это не одно и то же, и никакая ручная обработка не изменит этого в больших масштабах. (В главе 3 объясняется, почему.) Конвейер должен выполнять этот перевод автоматически.

3. Оптимизировать. Как правило, импорт необработанных данных САПР слишком ресурсоемкий для обработки в реальном времени. Конвейер обработки данных должен оптимизировать файлы (например, упростить геометрию, создать необходимые уровни детализации) без необходимости открывать каждый файл вручную.

4. Централизуйте и управляйте. После преобразования модели необходимо обеспечить возможность ее поиска, определения актуальной версии и контроля доступа к ней, а также возможности внесения изменений.

5. Распространить. Готовый продукт должен быть доступен для любого приложения или устройства, используемого конечным пользователем, и должен обновляться при изменении исходного файла.

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

Глава 3: Анатомия конвейера преобразования CAD-модели в 3D-модели в реальном времени.

Начнём с вопроса: почему 3D движок не может открыть файл САПР напрямую?

Ответ кроется в геометрии. Инструменты САПР описывают формы с помощью точных параметрических поверхностей, иногда называемых BRep или NURBS. Именно такая точность необходима инженеру-механику для проектирования детали с точностью до микрона. Однако 3D движки не отображают параметрические поверхности. Они отображают сетки: наборы плоских треугольников, которые достаточно точно аппроксимируют форму, чтобы выглядеть правильно на высокой скорости. Превращение одного в другое — это не вопрос выбора. Оптимизация сложных данных для использования в 3D движке — это первая задача, которую должен выполнить любой конвейер преобразования CAD-моделей в 3D-модели.

На этом этапе необходимо сохранить не только первоначальную форму. Эффективный конвейер обработки данных сохраняет:

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

Здесь важен охват формата. Unity Asset Transformer поддерживает более 70 форматов CAD, BIM, сеток и облаков точек, включая файлы AutoCAD, CATIA, STEP, IFC, Revit и glTF, поскольку инженерные группы редко используют только один инструмент. Если конвейер обработки данных поддерживает только те форматы, которые ваша команда САПР использует сегодня, он устареет, если другая команда, другой поставщик или другое приобретение внедрит что-то другое.

После преобразования геометрии, как правило, необходимо сделать её легче, прежде чем она будет готова к использованию в реальном времени. К типичным методам оптимизации относятся:

• Децимация, которая уменьшает количество треугольников.
• Ретопология — это метод восстановления упрощенной сетки из сложной.
• Генерация уровня детализации (LOD), благодаря чему удаленные объекты автоматически отображаются с более низким качеством.

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

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

Глава 4: Строить против Покупка — Почему даже достаточно хорошие трубопроводы выходят из строя в больших масштабах

Большинство процессов преобразования CAD-моделей в 3D-модели не начинаются с конвейеров. Они начинаются как сценарий. Инженеру нужно было преобразовать одну модель для одной презентации, он написал одноразовый скрипт экспорта, и это сработало. Спустя шесть месяцев этот скрипт запускается каждую неделю, никто не помнит всех его граничных случаев, и он ломается при добавлении нового инструмента САПР.

Это вопрос «разрабатывать или покупать», с которым рано или поздно сталкивается каждый руководитель, принимающий технические решения, и стоит честно оценить реальные затраты на разработку в больших масштабах:

• Хрупкость . Скрипты, написанные вручную, обычно создаются на основе файлов САПР, имевшихся у автора под рукой. Новая геометрия, новые форматы или необычные иерархические структуры, как правило, приводят к сбоям, которые трудно устранить постфактум.
• Риск, связанный с ключевым персоналом . Знания о том, как работает трубопровод, зачастую хранятся в головах одного-двух человек. Если они недоступны, работа конвейера останавливается.
• Скрытые затраты на техническое обслуживание . Каждая новая версия САПР, каждый новый формат файлов и каждая новая целевая платформа (например, веб, XR гарнитура, мобильные устройства) — это еще одна вещь, для поддержки которой необходимо обновлять скрипт. Это время, затраченное инженерами, которое не отражается в отчете до тех пор, пока не наступит просрочка.
• Единого источника истины не существует . Без централизованного управления активами разные команды в итоге получают разные, слегка несинхронизированные копии одной и той же модели.

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

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

Глава 5: Контрольный список для оценки решений, принимаемых в технической сфере.

Независимо от того, какой конвейер обработки данных вы оцениваете — разработанный собственными силами или приобретенный у поставщика, — все вопросы остаются теми же. Используйте этот контрольный список для сравнения вариантов на равных условиях.

Покрытие формата

• Сколько форматов CAD, BIM, сеток и облаков точек он поддерживает изначально?
• Сохраняет ли программа иерархию, материалы, метаданные и анимацию при импорте, или только исходную геометрию?

глубина автоматизации

• Может ли система обрабатывать сотни файлов в пакетном режиме без необходимости открывать каждый из них вручную?
• Предоставляет ли он API или SDK, чтобы ваша команда могла создавать скрипты и расширять его функциональность, а не ограничиваться фиксированным набором ручных действий?
• Может ли программа автоматически обнаруживать и перезапускать изменения в исходном файле?

Управление и контроль доступа

• Поддерживает ли система управление доступом на основе ролей, чтобы участники, рецензенты и зрители видели и делали только то, что им положено?
• Может ли это обеспечить единую версию истины для всех команд, вместо того чтобы допускать распространение дубликатов?

Гибкость развертывания

• Может ли оно работать в стандартном многопользовательском облаке, и, кроме того, может ли оно развертываться в виртуальном частном облаке или локальной среде для команд, которым необходимо хранить данные внутри собственной инфраструктуры?
• Интегрируется ли оно с системами управления идентификацией и доступом, которые уже использует ваша ИТ-команда?

Интеграция с существующими инструментами

• Совместимо ли это с инструментами проектирования, которые уже используют ваши команды, не только с пакетами САПР, но и с такими инструментами, как Blender, Maya или Photoshop для работы с контентом, не созданным в САПР?
• Вписывается ли это в ваш существующий рабочий процесс контроля версий, или же от него следует отказаться?

Общая стоимость владения

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

Ни один инструмент не сможет обеспечить идеальный результат по каждой строке. Цель этого контрольного списка не в том, чтобы найти идеальный ответ. Это необходимо для того, чтобы убедиться, что вы принимаете во внимание пробелы, которые вы выбрали сами, а не те, которые обнаружили уже после того, как производственный процесс начал приносить прибыль бизнесу.

Глава 6: Доказательства с места событий

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

Autoliv

Компании Autoliv , крупнейшему в мире поставщику систем безопасности для автомобилей, требовалось продемонстрировать клиентам сложные продукты безопасности в более интерактивной форме, чем это позволяли статические чертежи. Используя Unity Asset Transformer для автоматизации передачи и оптимизации данных САПР, компания Autoliv сократила этот процесс с четырех дней до шести часов на один продукт. Это не разовая победа — это постоянное отличие каждого нового продукта, который Autoliv выводит на рынок.

BMW Group

Компания BMW Group столкнулась с другой версией той же проблемы, но в гораздо большем масштабе: проблемы с контролем версий, несогласованные форматы файлов и сложности во взаимодействии с обширной глобальной библиотекой 3D моделей. Компания BMW разработала «3D Mine», платформу для управления 3D активами на базе Unity Asset Manager, чтобы стандартизировать способы хранения, поиска и совместной работы с 3D контентом командами дизайнеров, инженеров и маркетологов по всей компании.

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

Глава 7: Управление и безопасность в масштабах предприятия

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

Наиболее важными обычно оказываются три области:

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

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

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

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

Глава 8: Дорожная карта для вашего собственного конвейера

В рекомендациях Unity для корпоративного использования описан один из способов построения такой архитектуры: Asset Transformer отвечает за ввод и оптимизацию данных, Asset Manager — за централизацию и управление полученными ресурсами, а Pipeline Automation — за организацию всей последовательности в масштабе, и все они работают вместе как то, что Unity называет своим 3D движком данных. Это лишь одна из эталонных архитектур, а не единственная. Контрольный список в главе 5 покажет вам, соответствует ли этот или любой другой вариант потребностям вашей организации.

Глава 9: Что делать дальше?

Масштабируемый конвейер преобразования CAD-моделей в 3D-модели реального времени не создается за один день, но первый шаг невелик: проверьте свой текущий процесс, используя контрольный список из главы 5, и посмотрите, где есть пробелы.

Далее последуют несколько практических шагов:

• Изучите техническую документацию по Unity Asset Transformer и Unity Asset Manager , чтобы увидеть, как этапы, описанные в главе 3, соотносятся с конкретной реализацией.
• Начните бесплатную пробную версию Unity Industry , чтобы протестировать рабочий процесс на собственных CAD-файлах.
• Обратитесь к представителю Unity , если вашей организации необходимо спланировать развертывание в нескольких командах или развертывание виртуального частного облака.

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