Оптимизация рендеринга цифрового двойника мостового крана: 12–58 FPS

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

3D-сцена цифрового двойника мостового крана запускается не на высокопроизводительной рабочей станции, а на цеховом промышленном компьютере (i5-8500, встроенная графика, 4 ГБ разделяемой видеопамяти). При такой конфигурации плавный рендеринг модели крана на 200 000 полигонов вместе с заводским зданием без оптимизации невозможен. Замеры показывают: до оптимизации — 12 fps, после — 58 fps. Разница в 46 fps — именно то, чему посвящена эта статья.

Снижение полигональности: с 500 000 до 50 000 полигонов

3D-модель мостового крана в цифровом двойнике обычно создаётся из CAD-моделей, экспортированных из конструкторской BOM или STEP-файлов, и нередко насчитывает от 500 000 до 1 000 000 треугольников. Такая точность оправдана для структурной симуляции, но при рендеринге в браузере она становится катастрофой. Снижение полигональности — первая обязательная мера.

1.1 Стратегия снижения полигональности

Основной принцип снижения полигональности — «приоритет плоскостей»: большие плоские участки модели (стенка главной балки, накладка, боковые поверхности концевой балки) объединяются с помощью плоскостного обнаружения с сохранением контурных рёбер; на криволинейных поверхностях и в зоне сварных швов степень снижения уменьшается во избежание деформации. Рекомендуемый порядок работы: сначала с помощью Planar decimation довести плоские участки до минимального числа полигонов, затем применить Collapse decimation для вторичной оптимизации остальных зон, целевой показатель — не более 50 000 полигонов.

1.2 Рекомендуемые инструменты

• Blender Decimate Modifier: бесплатный, поддерживает Planar decimation и Collapse decimation, степень снижения контролируется точно
• Simplygon: промышленный инструмент автоматического снижения полигональности, поддерживает автоматическую генерацию цепочки LOD, дорогой, но эффективный
• MeshLab: с открытым исходным кодом, подходит для пакетной обработки

1.3 Критический предел снижения

Меньшее количество полигонов — не всегда лучше. При чрезмерном снижении контур модели деформируется, и это сразу заметно. Эмпирическое правило: после снижения визуальное различие между моделью и оригиналом в статическом состоянии должно быть незаметно невооружённым глазом. На практике наложите исходную и упрощённую модели друг на друга, включите полупрозрачное сравнение — отклонение контура менее 1 пикселя считается допустимым.

LOD-оптимизация: многоуровневая детализация для цифрового двойника

LOD (Level of Detail) — самый зрелый метод оптимизации в 3D-рендеринге: вблизи видна детализация, вдали — контур. В сценарии цифрового двойника оператор обычно не рассматривает детали сварных швов конкретного мостового крана — большую часть времени он наблюдает за работой нескольких кранов в обзорном режиме.

2.1 Проектирование уровней LOD

Уровни LOD делятся на 4 ступени в зависимости от дистанции обзора: LOD0 (детальный, 0–50 м), LOD1 (средний, 50–200 м), LOD2 (упрощённый, 200–500 м), LOD3 (дальний план, 500 м+). Количество полигонов и разрешение текстур для каждого уровня приведены ниже:

Если переключать уровни детализации LOD жёстко (резкая смена модели при достижении порога), визуально возникает эффект «скачка». Рекомендуется использовать компонент LOD из three.js с плавным переходом (fade), либо задать порог переключения в виде анимированного интервала (например, прозрачность плавно меняется в диапазоне 48–52 м). Кроме того, не нужно проверять переключение LOD каждый кадр — достаточно выполнять проверку раз в 200 мс, это снижает нагрузку на CPU.

Текстуры — основной источник потребления видеопамяти. Полный набор PBR-материалов (baseColor + roughness + metallic + normal + AO) в несжатом виде 2048×2048 занимает около 200 МБ видеопамяти на один мостовой кран. При одновременном отображении 5 кранов видеопамять переполняется мгновенно.

Рекомендуемые решения:

• ASTC 6×6 — формат сжатия текстур, разработанный ARM. Степень сжатия около 4:1, потеря качества приемлема. Полная поддержка в WebGL2.
• KTX2 + Basis Universal — кроссплатформенное сжатие текстур, распаковка выполняется непосредственно на GPU без участия CPU. В Three.js есть готовый загрузчик.
• Снижение разрешения текстур — для baseColor достаточно 1024×1024, для roughness/metallic — 512×512, для normal — 1024×1024, для AO — 256×256.

После оптимизации потребление видеопамяти на один мостовой кран снижается с 200 МБ до 45 МБ.

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

В Three.js нет встроенного механизма Occlusion Culling, поэтому его нужно реализовать самостоятельно или подключить стороннюю библиотеку:

• Portals — разделение заводского здания на несколько зон/помещений. Объекты внутри зоны отображаются только тогда, когда эта зона видна. Подходит для сцен со стационарной структурой здания.
• Hardware Occlusion Queries — использование WebGL2 (EXT_disjoint_timer_query или Occlusion Query) для проверки видимости объектов. Высокая точность, но задержка в 1 кадр. Подходит для крупных статичных объектов.
• Frustum Culling — включён по умолчанию в Three.js, отображает только объекты внутри пирамиды видимости камеры. Это базовая оптимизация, но её недостаточно — объекты внутри пирамиды видимости всё ещё могут быть скрыты другими объектами.

В реальных проектах рекомендуется подход Portals. Заводское здание делится на несколько зон вдоль направления пролёта. Каждый мостовой кран относится только к своей текущей зоне и соседним. Если оператор находится в зоне A, краны в зонах B и C не отображаются — обновляется только текстовая информация об их состоянии.

Рендеринг — это не только работа фронтенда. То, как данные передаются от бэкенда к фронтенду, в каком объёме и с какой скоростью, напрямую влияет на пользовательский опыт.

Данные о состоянии мостового крана обновляются каждые 100 мс, но 95% параметров остаются неизменными от кадра к кадру (например, номинальная нагрузка, пролёт и другие технические параметры никогда не меняются). Полная передача всех данных — это напрасная трата пропускной способности и ресурсов CPU на парсинг.

Решение: бэкенд отправляет только изменённые атрибуты. Каждая передача содержит bitmap-маску, указывающую, какие атрибуты изменились. Фронтенд обновляет только те 3D-объекты, чьи атрибуты изменились. На практике трафик снижается с 50 КБ/с до 8 КБ/с на один кран.

• JSON + gzip: степень сжатия около 6:1.
• JSON + Brotli (нативная поддержка в Chrome/Firefox): степень сжатия около 8:1, распаковка немного медленнее gzip, но приемлемо.
• Protocol Buffers (рекомендуется): бинарная кодировка, объём в 5 раз меньше JSON, скорость парсинга в 10 раз выше. Есть готовая библиотека protobuf.js, интеграция с Three.js безболезненная.

• WebSocket — полнодуплексный протокол, минимальная задержка, подходит для потоковой передачи данных в реальном времени.
• SSE (Server-Sent Events) — однонаправленная передача, нативная поддержка в браузере, встроенный механизм переподключения.
• Рекомендуется WebSocket с автоматическим переподключением (интервал heartbeat 15 с). При нестабильной сети на объекте — запасной вариант SSE.

Ключевая задача оптимизации потока рендеринга — вынести обработку данных из основного потока:

Рекомендации по аппаратной конфигурации

Оптимизация рендеринга на периферии: как добиться 60 FPS на промышленном компьютере

Стандартная конфигурация промышленного компьютера на большинстве заводов находится где-то между «начальным» и «стандартным» уровнем. После полного внедрения описанной выше схемы оптимизации средняя частота кадров при отображении 5 мостовых кранов на встроенной графике i5-8500 выросла с 12 FPS до 58 FPS. Если на объекте всего 1–2 мостовых крана, начальной конфигурации будет вполне достаточно.

Заключение

Оптимизация рендеринга на периферийных устройствах — это не магия, а три ключевых принципа: меньше передавать данных, меньше отрисовывать моделей, активнее задействовать GPU. Снижение пропускной способности на каждый мостовой кран с 50 КБ/с до 8 КБ/с, уменьшение количества полигонов с 500 000 до 50 000 и сокращение потребления памяти с 1,8 ГБ до 480 МБ позволяют добиться 60 FPS цифрового двойника даже на промышленном компьютере.

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

Часто задаваемые вопросы