С 2023 года компания «СИБУР Диджитал» использует продукты C3D Labs, в том числе веб-фреймворк C3D Web Vision, интегрированный в собственное веб-приложение для управления инженерными данными. Результаты этой интеграции вышли далеко за рамки внедрения программного решения и стали примером продуктивного взаимодействия команд СИБУР и C3D Labs. Совместная работа в области управления требованиями и системного анализа бизнес-контекста привела к появлению ряда технических улучшений, направленных на развитие функциональности продукта.
Одним из ключевых направлений стала оптимизация производительности во фреймворке C3D Web Vision 2.0. В центре внимания — поддержка задач, связанных с инженерными данными, прежде всего — эффективная работа с крупными, протяженными и часто нерегулярными 3D-моделями.
1. Работа с инженерными данными
Фреймворк управления инженерными данными решает широкий круг прикладных задач (рис. 1). Сотрудники производственного блока используют его для визуальной локализации объектов на установке и поиска оборудования по номеру тега. В этом помогают инструменты просмотра моделей, API-функции поиска и выделения объектов, а также отображение структуры модели в виде дерева.
Проектировщики применяют измерительный модуль C3D для получения расстояний, радиусов и построения сечений. Специалисты строительного департамента сопоставляют изометрические чертежи с 3D-моделями, используя модуль просмотра.
Одной из главных проблем остается работа с большими моделями. Попытки синтетического разделения моделей на зоны не решают ее — напротив, это мешает проверке коллизий и точным измерениям на стыках. Разрывы в трубопроводах, кабелях и конструкциях, вызванные таким делением, исключают полноценный анализ. Кроме того, пользователи теряют возможность видеть оборудование в контексте всей модели, что затрудняет понимание его функциональной роли и связей. Переключение между файлами также увеличивает накладные расходы и приводит к потере рабочего контекста.
Оптимизация модуля C3D Web Vision 2.0 направлена на решение этих проблем — обеспечение стабильной работы с крупными, целостными моделями, повышение производительности и улучшение пользовательского опыта.
2. Модель парогазовой установки мощностью 800 МВт (ЗАО «Трест Севзапэнергомонтаж»)
Крупные промышленные объекты, такие как нефтеперерабатывающие и газоперерабатывающие заводы, функционируют как единые связанные системы (рис. 2). Для эффективной работы необходима целостная модель, позволяющая оценивать размещение объектов, маршруты, доступ, а также интерфейсы между различными инженерными разделами — технологией, КИП, электрикой, строительной частью и инфраструктурой.
На основе анализа бизнес-контекста была сформулированы требования к системе: ключевые функции, метрики и ограничения. Приоритетной задачей стала загрузка моделей в формате .c3d размером до 20 Гб. Важными метриками, которым следовало соответствовать, были:
Time-to-First-Pixel (TTFP) — время отображения первых графических элементов не должно превышать 10 секунд с момента начала загрузки модели;
FPS (frames per second) — при визуализации моделей до 10 миллионов объектов частота кадров должна быть не ниже 30.
Дополнительные задачи включали учет приоритетов при загрузке геометрии (в первую очередь — объектов, находящихся ближе к камере), а также наличие всех инструментов, необходимых в рабочем процессе (выбор объектов, измерение и построение сечений).
Реализация этих требований осложнялась рядом ограничений, обусловленных архитектурой клиентской рендеринг-системы. В качестве минимальной конфигурации рассматривались устройства с процессором Intel i5, 8 Гб оперативной памяти и интегрированной видеокартой с 1 Гб видеопамяти. Кроме того, необходимо было учитывать ограничение объема памяти, доступной браузерам на базе ядра Chromium, равное 4 Гб.
3. Исходная схема загрузки больших моделей (версия 1.x фреймворка C3D Web Vision)
В первой версии фреймворка C3D Web Vision структура модели представлялась единым блоком, размер которого мог достигать 300 Мб. Процесс загрузки происходил в три этапа (рис. 3).
- Загрузка структуры — клиент запрашивал и получал данные о структуре модели, включая список узлов и объектов.
- Формирование очереди загрузки — на основании полученной структуры движок определял, какие геометрические файлы необходимо загрузить и в каком порядке.
- Загрузка геометрии — блоки геометрии обрабатывались как единый уровень без дополнительной декомпозиции.
Это уровни максимальной детализации. Типовая модель занимала около 10 ГБ в формате .c3d, а наиболее тяжелые достигали 20 и более гигабайт. Только после выполнения трех предварительных этапов становился доступен рендеринг модели в веб-интерфейсе.
В чем заключаются недостатки такого подхода при работе с экстремально крупными моделями? Первый — в необходимости полной загрузки блока структуры до начала рендеринга. Это ведет к дополнительным задержкам и паузам в отображении. Кроме того, сам блок может весить сотни мегабайт, что создает трудности при передаче через корпоративные прокси-серверы и увеличивает нагрузку на браузер при обработке. Второй — в хранении геометрии. Размер геометрических блоков до 10 Гб превышал актуальные на тот момент ограничения браузеров (4 Гб), что делает невозможной полную загрузку геометрии и ее корректное отображение в веб-среде. Третий — в ограничениях визуализации на движке WebGL 1.0. В старой версии были ограничены возможности шейдинга, отсутствовала поддержка UBO и имелись жесткие лимиты на количество вершин в буферах. Для преодоления этих ограничений была разработана серия улучшений (рис. 4).
4. Усовершенствованная структура фреймворка C3D Web Vision
Первое улучшение связано с поиском одинаковой геометрии (инстансинг). Идея проста: вместо многократного хранения повторяющихся сеток мы сохраняем нужную геометрию один раз, а в остальных случаях используем ссылки на этот общий экземпляр. На наших моделях с высокой степенью повторяемости фрагментов это позволило сократить объем наибольшего уровня детализации с 20 до 6 Гб — почти втрое.
Второй комплекс работ — лечение сетки. Это типовая и крайне актуальная задача в нашем бизнес-домене. При экспорте моделей из CAD-систем и их конвертации в формат .c3d возникали известные проблемы триангуляции: отверстия, нестыковки полигонов либо избыточная детализация при моделировании криволинейных поверхностей. Был добавлен отдельный этап, отвечающий за исправление сетки.
Третья группа улучшений — работа с уровнями детализации геометрии. Это также важная задача в нашем бизнес-домене: крупные объекты часто содержат чрезмерно большое количество полигонов, что не нужно при просмотре, например издалека. Поэтому было реализовано четыре уровня детализации — от грубого представления в виде габаритного параллелепипеда до максимально точного отображения исходной геометрии.
Четвертое улучшение — многопоточная генерация. Поскольку генерация Cache для моделей с десятками миллионов объектов занимала значительное время, на этапе создания Cache был реализован мультипроцессинг.
В результате проведенной работы была существенно переработана структура хранения модели. Во-первых, формирование модели динамической загрузки и очереди было перенесено в офлайн. Это позволило выделить отдельный блок, отвечающий за динамическую загрузку. Во-вторых, структура, ранее представляемая в виде одного большого блока, была разбита на несколько частей. Благодаря этому стало возможным передавать модель в обход ограничения корпоративных прокси-серверов на размер файла в 50 Мб. В-третьих, были реализованы различные уровни детализации. Габаритные параллелепипеды остались частью структурного блока, а три уровня геометрической детализации были выделены в отдельные блоки. В случае модели размером 20 Гб это позволило уменьшить максимальный размер блока в 3,3 раза — до 6 Гб, главным образом за счет инстансинга. Кроме того, появились блоки с деградированной геометрией общим объемом 1,3 Гб, которые можно быстро загружать динамически вместе с соответствующими структурными блоками. Это решение позволило укладываться в ограничение браузера (4 Гб).
В версии 2.0 появились и технологические улучшения: переход на движок WebGL 2.0 расширил возможности работы с API-геометрией. Поддержка uniform-буферов и шейдеров в glsl 3.0 обеспечила более гибкие возможности для шейдинга без увеличения расхода графической памяти. В числе новых функций — frustum culling (отсечение объектов за пределами сцены) и pixel culling (исключение из отрисовки объектов, занимающих менее 5 пикселей на экране по причине малых размеров или удаленности от камеры).
5. Уровни детализации модели
На рис. 5 показано, как в динамике выполняется переход между уровнями детализации модели. Изначально отображается габаритный параллелепипед, а затем происходит постепенный переход к более детальным уровням.
При визуализации крупной типовой модели размером 10 Гб в формате .c3d в версии 2.0 получены следующие результаты (характеристики рабочего места: Intel i5, 8 Гб RAM, интегрированная видеокарта с 1 Гб видеопамяти AMD Radeon или Intel HD).
Ограничение памяти браузера (4GB)
- Быстрая генерация cache (20 минут — более чем десятикратное ускорение по сравнению с версией 1.0).
- Время до появления первой графики на экране уменьшено до 1 сек.
- Время загрузки всех видимых данных: ~30 сек.
- Разные уровни детализации в зависимости от положения камеры.
- Приоритетная загрузка — сначала загружается геометрия, которая ближе к камере.
- Отображение с большой частотой кадров (FPS 60+, в первой версии — не более 5).
6. Модель для нагрузочного тестирования
Для нагрузочного тестирования была создана синтетическая модель трубопроводной системы (рис. 6). Она включает около 100 тысяч уникальных объектов без использования инстансов и около 20 миллионов треугольников. В версии 1.x такой объем не поддерживался — модель не открывалась. В версии 2.0 модель загружается без ошибок, при этом обеспечивается четкая ориентация в пространстве, точная локализация объектов и стабильный FPS на уровне 60.
Улучшения, о которых шла речь, будут включены в будущий релиз и станут общедоступными. Компания «СИБУР Диджитал» активно участвовала в формировании требований к системе, ориентируясь на специфику нашего бизнес-домена. Среди ключевых задач, решаемых в рамках сотрудничества, — работа с большими моделями, проблемы триангуляции при экспорте и взаимодействие с CAD-системами. Важнейший критерий при переключении уровней детализации — стабильность частоты кадров на уровне 30 FPS. Для этого необходимо, чтобы одновременно в сцене отображалось порядка 30 миллионов треугольников. Данная метрика используется как практическое ориентирующее значение при определении порогов переключения уровней.