Прощай, ActiveX: как мы заменили плагин SolidWorks для ЭТМД на веб-решение на Three.js

Многие разработчики живут в мире современных фреймворков, но есть сектор, где время застыло в эпохе Windows XP и Internet Explorer 6. Это промышленность. До недавнего времени просмотр 3D-моделей в наших системах осуществлялся через специализированный плагин для SolidWorks, встроенный в IE через ActiveX.

Когда Microsoft официально отправила IE на покой, а заказчики потребовали поддержку мобильных устройств и Linux-терминалов, мы поняли: пора менять стек. В этой статье я расскажу, как мы переписали клиентскую часть визуализации с нативного ActiveX-контрола на Three.js, какие подводные камни встретились при работе с CAD-геометрией и как мы добились производительности, сравнимой с десктопным приложением.

Проблема: Наследие ActiveX

Наша исходная архитектура выглядела типично для промышленных систем 2010-х годов:

1. Сервер: Хранилище документов (SQL + File Storage).
2. Клиент: Веб-портал, работающий только в Internet Explorer.
3. Визуализация: ActiveX-контрол (на базе движка SolidWorks/OpenGL), который рендерил модели .sldprt и .step прямо в окне браузера.

Почему это стало невыносимо:

• Безопасность: ActiveX — это дыра в безопасности корпоративного периметра. Современные браузеры блокируют их по умолчанию.
• Зависимость от ОС: Решение работало только на Windows. О поддержке macOS, Linux или iOS можно было забыть.
• Интеграция: Внедрение изменений в UI требовало пересборки COM-объекта и переустановки клиента на сотнях рабочих мест.
• Производительность: На больших сборках (1000+ деталей) IE просто «падал» с ошибкой памяти.

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

Выбор стека: Почему Three.js?

Мы рассматривали несколько вариантов:

1. Готовые коммерческие вьюверы (например, Autodesk Forge): Дорого, зависимость от вендора, данные уходят в облако (не приемлемо для оборонки/гостайны).
2. Babylon.js: Отличный движок, но сообщество Three.js в контексте кастомизации под CAD оказалось больше.
3. Three.js: Открытый код, гибкость, возможность написать свои шейдеры для выделения граней и огромная экосистема.

Мы выбрали Three.js с планом постепенной миграции.

Техническое решение: Пайплайн конвертации

Главная проблема веб-визуализации CAD — это форматы. Браузер не умеет нативно читать .sldprt или .step. Тянуть их на клиент и парсить через step-js — долго и больно для больших сборок.

Архитектура конвертации: Мы вынесли тяжелую обработку на бэкенд (микросервис на C++ с использованием OpenCascade):

1. Загрузка исходного файла (STEP/IGES/SolidWorks).
2. Упрощение геометрии (удаление мелких фасок, не видимых на экране).
3. Триангуляция и экспорт в glTF 2.0.
4. Сжатие геометрии через Draco.

// На стороне клиента (Three.js)
import { GLTFLoader } from 'three/examples/jsm/loaders/GLTFLoader.js';
import { DRACOLoader } from 'three/examples/jsm/loaders/DRACOLoader.js';

const dracoLoader = new DRACOLoader();
dracoLoader.setDecoderPath('/draco/');

const loader = new GLTFLoader();
loader.setDRACOLoader(dracoLoader);

loader.load('model.glb', (gltf) => {
    const model = gltf.scene;
    // Настройка теней и материалов
    model.traverse((child) => {
        if (child.isMesh) {
            child.castShadow = true;
            // Оптимизация материалов для CAD-стиля
            child.material.side = THREE.DoubleSide; 
        }
    });
    scene.add(model);
});

Результат: Размер файла уменьшился в 5-10 раз по сравнению с исходным STEP, время загрузки на клиенте сократилось с 15 секунд до 1-2 секунд.

Реализация инженерного функционала

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

1. Выделение граней и сборочных единиц

В нативном плагине это работало через выбор объектов в дереве модели. В вебе мы использовали кастомный Raycaster и метаданные, внедренные в glTF при конвертации.

const raycaster = new THREE.Raycaster();
const mouse = new THREE.Vector2();

function onMouseClick(event) {
    mouse.x = (event.clientX / window.innerWidth) * 2 - 1;
    mouse.y = -(event.clientY / window.innerHeight) * 2 + 1;

    raycaster.setFromCamera(mouse, camera);
    const intersects = raycaster.intersectObjects(scene.children, true);

    if (intersects.length > 0) {
        const object = intersects[0].object;
        // Подсветка через emissive материал
        highlightObject(object);
        // Показать спецификацию по ID объекта
        showBOMData(object.userData.partId);
    }
}

2. Измерения (Measure Tool)

Самая сложная часть. Нужно было рисовать линии поверх 3D-сцены с привязкой к точкам. Мы использовали CSS2DRenderer для подписей и LineLoop для линий измерений. Координаты брались напрямую из вершин меша, что гарантировало точность, достаточную для визуального контроля (до 0.01 мм).

3. Взрыв-схемы (Exploded View)

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

Проблемы и решения (Failures)

Без граблей не обошлось. Вот что пошло не так на старте:

1. Проблема масштаба: CAD-системы работают в метрах/миллиметрах, Three.js предпочитает условные единицы. При импорте больших сборок (например, ангар) возникали артефакты з-буфера (z-fighting).
   • Решение: Принудительный скейлинг геометрии при конвертации и настройка camera.near / camera.far под конкретные сцены.
2. Производительность на слабых машинах: Инженерные ноутбуки часто не имеют мощных видеокарт.
   • Решение: Внедрили уровень детализации (LOD). Если камера далеко — показываем упрощенный бокс вместо детальной модели двигателя.
3. Координатные системы: В SolidWorks ось Y часто вверх, в WebGL — Y вверх, но в некоторых экспортах случался Z-up.
   • Решение: Унификация на этапе конвертации в OpenCascade. Все модели приводятся к единой системе координат до отправки на клиент.

Итоговые метрики

После внедрения решения на Genervis в промышленную эксплуатацию мы получили:

Заключение

Переход с устаревших плагинов на современные веб-технологии в промышленном секторе — это больно, но необходимо. Three.js доказал, что может справляться с задачами, которые раньше считались прерогативой тяжелого десктопного софта.

Для нас в Genervis это открытие новых возможностей: теперь мы можем встраивать 3D-визуализацию в любые системы (ERP, PLM, LMS) без установки дополнительного ПО.

Следующий шаг — внедрение WebGPU для работы с облаками точек и сканами, но это тема для отдельной статьи.

Код некоторых утилит для конвертации мы планируем открыть. Буду рад ответить на вопросы по архитектуре и работе с CAD-форматами в комментариях!