Как стать автором
Обновить

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

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


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

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

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

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

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

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

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


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

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

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

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

Публикации