Тестирование загрузчиков STEP формата для VR

    Мы, компания ООО «ВР Концепт», уже 5 лет ведем разработку программного обеспечения VR Concept для организации коллективной работы с любой 3D-моделью, в том числе САПР, в шлемах виртуальной реальности.

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



    Немного предыстории


    Цель нашего программного обеспечения — помочь компаниям ускорить согласование проектов между лицом, принимающим решение, руководителем проекта, исполнителями, партнерами и заказчиками, за счет переноса обсуждения из плоскости чертежей, картинок на мониторе и натурных макетов в виртуальную реальность, работа с проектов в масштабе 1:1 (на основе 3D-модели) с возможностью рассмотреть его будто он уже реализован или построен. Использование технологии виртуальной реальности позволяет повысить эргономические характеристики проектируемого объекта, снизить количество и стоимость ошибок в проекте, повысить эффективность обучения сотрудников на производстве и снизить риск возникновения чрезвычайных ситуаций. Кроме того, технология применяется в сфере обучения.

    Для реализации поддержки САПР форматов мы используем разные подходы, начиная от самостоятельной реализации по открытым стандартам, использования Open Source и, в том числе, с помощью коммерческих решений, включая ядра САПР.

    Реализация поддержки JT формата и знакомство с загрузчиком C3D Labs


    По результату работы с текущими заказчиками, мы приняли решение по реализации формата JT, который сильно востребован в машиностроении, особенно у заказчиков, которые работают с программным обеспечением Siemens NX. Мы провели анализ разных способов по реализации такого загрузчика, основными критериями выбора такого решения были качество загрузки JT, скорость поддержки, условия использования (ежегодная оплата, процент с продаж, возможности и условия тиражирования) и цена. В результате выбрали решение компании C3D Labs, тем более, что к этому моменту мы уже начинали прорабатывать интеграцию с САПР Компас-3D, компании Аскон. А C3D является ядром этого САПР.

    Также C3D Labs представляет доступ и к другим форматам, таким как: JT, C3D, X_T, X_B, STEP, IGES и ACIS SAT. Но часть из этих форматов, а конкретно STEP и IGES, уже были реализованы в VR Concept с помощью другого продукта — Open Cascade.

    Партнерство с компанией C3D Lab заключили в июне 2019 года. В июле начали работу над реализацией загрузчика формата JT с помощью C3D. У нас ушло примерно 3 человека-месяца и уже осенью был готов загрузчик. Первые пользователи получили сборку VR Concept с поддержкой JT в сентябре. А уже в октябре были реализованы и другие форматы JT, C3D, X_T, X_B, STEP, IGES и ACIS SAT. Новую версию VR Concept мы выпустили в декабре и в ней уже присутствовала поддержка всех этих форматов с помощью ядра C3D.

    Тестирование загрузчиков STEP


    Самый популярный из перечисленных форматов — это машиностроительный формат STEP. И у нас было две реализации загрузки с помощью разных библиотек. Стояла задача сделать выбор или оставить обе реализации.

    Мы решили провести тестирование сравнения двух загрузчиков STEP в VR Concept, реализованных на разных платформах.

    Для тестирования мы использовали 64 различных модели формата STEP с различными характеристиками. Варьировался размер файлов (от 43 Кб до 269909 Кб) и количество объектов/тел модели (от 45 до 18483)


    Модель предоставлена компанией АСКОН

    В зависимости от вышеуказанных характеристик по результатам теста сформировали следующую таблицу, показывающую время загрузки моделей с различным количество тел/объектов:
    Диапазон количества объектов (тел) Количество моделей в выборке Среднее время загрузки VR Concept c Open Cascade (сек) Среднее время загрузки VR Concept с C3D(сек)
    1-1000 39 32,5 9,84
    1000-3000 23 93,4 54,2
    более 3000 2 454 57,5

    Также отобрали три модели для детального показательного сравнения. Компрессор (ниже по тексту), троллейбус (предыдущая картинка) и экскаватор LEGO. Модели эти довольно объемные, с количеством тел более 2000. Одну из них можно посмотреть и проверить самостоятельно по ссылке. А вот так она выглядит у нас:



    В зависимости от вышеуказанных характеристик по результатам теста сформировали следующую таблицу:



    Вместо выводов


    Мы не ожидали получить такой результат, если честно! C3D оказался намного шустрее в чтении формата STEP, чем Open Cascade, при одинаковых настройках и визуального качества результата. Кроме того, как нам кажется, при этом качество отображения модели с C3D даже чуть лучше.


    Еще одно сравнение качества визуализации в увеличенном масштабе: сверху Open Cascade, снизу C3D. Модель компрессора предоставлена компанией АСКОН

    Да, мы не сравнивали оба этих конвертера вне нашего решения, поэтому если у вас есть данные на этот счет, будем рады им! Возможно, у вас есть мысли в защиту Open Cascade? Поделитесь, пожалуйста, в комментариях.

    Мы продолжаем тестировать и сравнивать Open Cascade и C3D на разных 3D-моделях. Будем рады, если поделитесь своими 3D-моделями — мы проведем тестирование на них и поделимся результатом!

    Комментарии 10

      0

      Скажите, время замеряли конкретно загрузки модели из файла, или вместе с визуализацией?


      И почему картинки компрессора разные? Обе картинки получены вашим рендером?

        0
        Спасибо за ваши вопросы!
        Время замеряли именно загрузки и генерации сетки. Модель после загрузки отправляется сразу на рендер и это занимает секунды, все происходит внутри одной системы.
        У компрессора не на всех объектах задан материал и используется наш механизм случайной закраски, чтобы объекты визуально были лучше различимы.
          0

          Спасибо. Интересно посмотреть на тайминги этих этапов отдельно. Где проседает opencascade, на формировании или на тесселяции, она ведь тоже не бесплатна.

            0
            Спасибо за наводку, доработаем лог в будущей версии — посмотрим.
        0
        Есть вопросы немного в сторону и возможно не по адресу, но всё же.

        По работе периодически приходится импортировать в КОМПАС-3D (он так же работает на ядре C3D) файлы формата STEP. Довольно часто, на больших сборка, он либо не справляется, либо делает это весьма долго. Т.е. импорт может длиться часами с полной загрузкой одного ядра и ни к чему не привести. Или обрабатывать десятки минут и выдать проблемную геометрию. В таких ситуациях я запускаю FreeCAD. За редким исключением FreeCAD отрабатывает всё быстро и практически без ошибок.

        Собственно вопросы:
        1. Делали ли вы сравнение с решениями применяемыми в FreeCAD?
        2. Если да, то есть ли соображения почему скорости так сильно отличаются?
        3. Можно ли параллелить процесс импорта с точки зрения математики и особенностей формата файлов вторичного представления 3D?
          0
          Конвертер STEP — один из первых модулей C3D Converter, где удалось обеспечить ускорение за счёт многопоточности. То, что время от начала импорта до появления изображения на экране может отличаться в разных приложениях на базе C3D (при одинаковых настройках импорта) — это особенность реализации модельного документа. Стандартная реализация C3D предусматривает размещение всей модели в оперативной памяти, в то время, как КОМПАС-3D, например, создаёт файлы компонент на диске. Возможно, это обстоятельство при каких-то условиях служит причиной задержки изображения модели в окне.
            0
            Спасибо за вопросы! С FreeCAD не сравнивали, проверим. По поводу третьего вопроса коллеги из C3D уже ответили :)
            +1

            Коллеги, добрый день!


            Несколько слов не столько "в защиту Open Cascade", сколько объяснений, почему вы наблюдаете отличающиеся результаты.


            (Вероятно, по моему имени вы сможете догадаться о продукте, который я представляю ;-). Не буду раскрывать его названия — не знаю какие здесь на Хабре условия, чтобы не получить сразу бан за рекламу. Назовем его условно CE. Вы легко его нагуглите ;-)


            Наш бизнес — конвертеры и мешеры, которые сейчас пока сидят поверх геометрической модели ядра Open CASCADE, но значительно шире списка, представленного в посте. А в далеком прошлом я работал в OCC, в том числе и над упомянутыми здесь компонентами. Поэтому постараюсь прокомментировать "со знанием дела").


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


            1. парсинг файла (зачитывание файла в промежуточную структуру представления в памяти)
            2. конвертация (перевод из промежуточного формата после шага 1 в структуру данных ядра)
            3. триангуляция — построение сетки из полученной геометрической модели (B-Rep, Boundary Representation)
            4. отображение триангуляции на экране.

            Шаги 1-3 определяются выбранным вами ядром (OCC vs C3D). Если вы использовали свой собственный механизм отображения, то шаг4 — скорее всего общий для обоих случаев, хотя и его вклад может меняться от ядра к ядру (например, в зависимости от того, насколько ядро предоставляет эффективный API для доступа к триангуляции, может происходить или не происходить копирование каких-то данных).


            Максимальный вклад в вашем случае наверняка вносят пп.2 и 3. В п.2, OCC, например, содержит непосредственно мэппинг (построение B-Rep сущностей из STEP) и т.н. Shape Healing — адаптацию, коррекцию и построение недостающих данных из исходного файла, чтобы удовлетворять требованиям ядра. Такой компонент неизбежно должен присутствовать в каждом ядре, т.к. записывающая система может использовать иное ядро, а требования формата могут позволять записывать информацию неоднозначно. Например, большинство систем пишут в STEP (как и другие форматы) только 3D представление кривых, лежащих в основе B-Rep ребер. OCC же требует наличия и 2D, и 3D представления. Поэтому OCC SH достраивает недостающее представление (например, проецирует 3D кривую на поверхность или аппроксимирует 3D кривую по параметрической в 2D пространстве поверхности). Другой пример — упорядоченность ребер в контуре (цикле), замкнутость 2D контура (что требует добавления дегенеративных ребер на поверхностях с сингулярностями или построения ребер-швов, сдвигов кривых на периодических поверхностях) и т.д. и т.п. Shape Healing может занимать львиную долю в п.2. Например, в наших собственных написанных конвертерах (не от OCC!) для Parasolid (и следовательно для JT, Solidworks, Siemens NX) доля Shape Healing составляла 90-95% времени.


            Схожий компонент, если есть в C3D, может занимать существенно другое время и возможно степень "тщательности", с которой такой алгоритм может работать, сильно разнится по сравнению с OCC. Такой компонент может отсутствовать в явном виде, а подобные "исправления"/"адаптации могут быть разнесены по всему коду конвертера. Список таких проверок и исправлений будет сильно разниться между любыми ядрами. Более того, такое время может быть размазано между алгоритмами. Например, при импорте, чтобы удовлетворить минимальным требованиям ядра, нужен один уровень "параноидальности" проверок, а перед выполнением булевых операций уровень требований может быть другой (например, более строгие требования по допускам и т.д.). Поэтому просто для визуализации Вам хватает базовой адаптации, но такую модель нельзя будет отдать в какую-нибудь моделирующую операцию.


            П.3 — мешер. Здесь тоже могут сильно отличаться алгоритмы и их параметры, и время работы.


            Мы в CE начинали с использования алгоритмов OCC, но с течением времени переписали на свои, заменив многие ключевые для нас алгоритмы, в том числе из-за недостаточной производительности. Это и все конвертеры, и мешер, и многие геометрические алгоритмы (проекции, и др), и более эффективное использование Shape Healing и др. Для нас это core business, поэтому здесь мы пытаемся выжимать максимум по мере возможностей (и параллелизм, и отложенные загрузки и проч.)


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


            Надеюсь, чем-то помог )).


            Удачи!


            Роман


            P.S. Если сможете предоставить 3D модели, то попробуем подготовить данные, полученные из СЕ.

              0
              Роман, спасибо за подробное описание работы конвертера. Отталкиваясь от него, могли бы Вы пояснить, что Вы имели в виду под фразой «если он есть в C3D», говоря про функционал адаптации?

              C3D Converter с самого начала предназначался для получения моделей, к которым можно применять операции моделирования. Если Вы предполагаете, что высокое быстродействие конвертера от C3D по сравнению с решением на базе OpenCASCADE достигается за счёт отключения «тяжёлого» функционала, отвечающего за самую «параноидальную» адаптацию, то это не так. В C3D Converter нет опции, предназначенной для решения задач визуализации в ущерб качеству B-Rep.

              Возвращаясь к истории C3D, отметим, что разработка моделера и конвертера в рамках единого продукта страхует от ситуаций, когда изменения в одном модуле провоцируют ошибки в другом. Такие ситуации довольно легко отслеживаются и разрешаются в рабочем порядке. При этом улучшения, сделанные для одного компонента, улучшают и другой.
                0
                Коллеги,
                Под фразой «если он есть в C3D» имелось в виду наличие компонента, подобного Shape Healing в OCC. Поскольку я не работал с C3D, то не знаю, как реализован у вас подобный функционал. Например, как я сказал, на начальных этапах влияние Shape Healing у нас было более 90%. Сейчас мы делаем большУю часть собственной обработки (например, процедурной геометрии из Parasolid) в рамках конвертера, так что влияние Shape Healing сильно уменьшается.
                В SH есть алгоритмы, которые имеют O(N^2) сложности, поэтому на некоторых моделях влияние может быть более сильным.

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое