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

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

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

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

Несколько слов не столько "в защиту 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 модели, то попробуем подготовить данные, полученные из СЕ.