Александр Спиваков, руководитель команды C3D Converter, делится опытом развития конвертеров проприетарных форматов и формата IFC и рассказывает, как итоги работы отразились на базовой функциональности, а именно на взаимодействии с пользователями и приложениями.
В своих материалах я редко касался темы новинок в конвертерах, особенно тех, которые относились к геометрии и представлениям. Как правило, они были посвящены новым форматам и настройкам, но в этот раз в центре внимания – новые представления формы, и это скорее исключительный случай, чем типичный. Преимущественно такая смена фокуса связана с тем, что большой пласт работы отдела разработки C3D Converter был напрямую связан с компонентами для чтения проприетарных форматов и формата IFC.
На иллюстрации мы можем наблюдать некоторую ретроспективу, которая фиксирует, как конвертеры появились, как они развивались и в каком состоянии находятся в настоящий момент. Фокус на новые представления формы и типы геометрии ярко прослеживается в случае с IFC и Creo, но не меньшего внимания заслуживает обзор тех работ, которые мы делали для обогащения базовой функциональности, а именно в той части, которая касается взаимодействия с пользователями и приложениями.
Рис. 1. Ретроспектива
Расширением возможностей конвертера, вынесенных за пределы kernel, мы начали заниматься в 2020 году. Тогда мы интегрировались с одним пакетом, и на том этапе нам хватало геометрии, которая была в большинстве обменных форматов, условно говоря, возможностей STEP-подобного протокола нам было достаточно. В 2021 году вышел плагин для Capvidia, с которым мы интегрировались. В 2022 году он был замещен плагином для системы CAD Exchanger. Примечательно, что сама система, сам протокол передачи данных показал, что здесь можно строить плагины, то есть можно взять одно решение и с бинарной совместимостью, просто копируя файлы и перемещая, получить переход на другое решение без пересборки. Одновременно с этим в 2022 году мы начали работать над собственными решениями. И в этот момент оказалось, что имеющегося протокола недостаточно для новых задач, для того технологического стека, который у нас есть.
Дело в том, что NX и SW построены на ядре Parasolid, а у нас уже есть конвертер формата, который для этого ядра является родным. Больше не было необходимости каким-то образом конвертировать геометрию на стороне плагина и передавать ее через старый протокол – с этим справлялся наш собственный Parasolid-ный конвертер. Первое, что мы осуществили, – это передачу Parasolid-ных потоков. Это было сделано в прошлогодней версии решения. Подобный подход мы применили для конвертера Inventor, который сейчас находится в стадии активной разработки. В нем, в отличие от Parasolid, используется формат SAB. Это не только бинарная версия формата SAT , но еще и та ветка, которая разрабатывается непосредственно для Inventor. Соответственно, были проведены некоторые незначительные с точки зрения математики, но при этом весьма трудоемкие доработки.
Усложнение было вызвано необходимостью в полном объеме поддерживать форматы IFC и Creo. В IFC, в отличие от классического граничного и частично полигонального представления, активно используются булевы операции и операции заметания, причем касающихся не поверхностей, а именно тел. Для этого вновь пришлось пойти на расширение API. Creo работает на своем ядре, формат которого не является даже частично открытым. Чтобы читать геометрию, фактически нужно разрабатывать поддержку сущностей, где лежит геометрия и не только, с нуля, подстраиваясь под реализацию в Creo.
Что присутствовало в формате IFC? IFC – это формат преимущественно BIM-отрасли. Формат достаточно дискуссионный, который изначально мы не планировали поддерживать в силу объективных причин, но тем не менее пошли на этот шаг в ответ на запросы пользователей.
Операции моделирования не слишком сложны, и с ними справляются даже не такие мощные моделлеры, как наш. Однако они есть, и их тоже пришлось реализовывать. Преимуществом послужило то, что мы с моделлером находимся в одном модуле, а потому можем пользоваться его функциями. В операциях моделирования встречаются как достаточно простые случаи, например три стыкующиеся дуги, которые заданы в явном виде, так и сложные случаи, когда, предположим, заметаемый профиль представлен не явной геометрией, а в виде неких каталожных элементов.
Рис. 2. Тела выдавливания и вращения
На иллюстрации продемонстрирован двутавровый профиль, у которого известны ширина, высота, толщина. Явная геометрия для заметания формируется на стороне плагина, и в моделях мы используем ее уже для построения той самой геометрии, которую отдаем пользователю.
Рис. 3. Булевы операции
Следующий случай – булевы операции. Их типичное применение – это вырезание проемов, таких элементов, как окна, двери и т. д. Оба тела на иллюстрации – это тела выдавливания. Выдавливается стенка, выдавливается оконный проем.
Рис. 4. Лечение сеток
IFC – это не только элементы построения, это еще и сетки, причем сетки в большом количестве и зачастую неважного качества. Или, по крайней мере, именно такие сетки бросаются в глаза при отображении моделей. На иллюстрации показана сетка, которая явно нуждается в «лечении», для которого в составе C3D PolyShaper также есть средства. В данном случае мы имеем явно несогласованные нормали, идущие в хаотичном порядке. Для решения этой проблемы мы расширяем функциональность для работы с полигональными моделями, в первую очередь лечение сеток. Результат лечения можно наблюдать на иллюстрации справа.
Рис. 5. Отраслевые метаданные
Спорным вопросом, вызывающим большие сомнения относительно поддержки формата IFC, стали отраслевые метаданные, то есть метаданные, привязанные к каким-то компонентам. Поскольку структура метаданных может быть весьма сложной, то использовать жестко заданные и закодированные структуры для хранения и в памяти и на диске представляется нецелесообразным. Чтобы избежать этого, мы предоставили плагину интерфейс для передачи этих данных в достаточно стандартном виде. На иллюстрации – реализация формата JSON. Идет несколько потоков, один отражает деревья, другой – метаданные для каждого компонента. Безусловно, в этом направлении предстоит еще много работы, это только начало пути.
Также на иллюстрации представлен пример метаданных для одного из компонентов в дереве. В данном случае мы работаем с единицами измерения, при этом очевидно, что исходные данные записаны при помощи Tekla. Как с ними работать в дальнейшем? Это уже вопрос в большей степени к приложению, которое будет ими пользоваться.
Формат Creo все-таки ближе к формату геометрического ядра, чем к каким-то новым, экзотичным, моделлерным форматам.
В какой-то мере это отсылка к хорошо известному машиностроению. Что для нас было самым интересным и удивительным? Некоторая геометрия просто не имела и сейчас не имеет прямых аналогов с форматом C3D. Она не слишком сложная, ее можно посчитать. Для этого мы применяем следующий механизм: формула для вычисления радиус-вектора и производных реализована на стороне модуля для чтения нативных форматов, а мы строим на своей стороне копию, с которой работаем.
Отметим, что некоторые поверхности при этом были заданы в цилиндрической системе координат. Для поддержки такой геометрии также пришлось доработать API.
Рис. 6. Поверхности в цилиндрической системе координат
На иллюстрации – пример модели, которая задана именно таким образом. Наверное, при построении оригинальной модели использование системы координат в чем-то упрощало жизнь конструктору, но для конечного результата эти нюансы несущественны.
Перейдем к тому, что сделано в самом ядре, в коробке kernel-а. Одно из самых заметных изменений – это наша работа с PMI.
Рис. 7. Передача PMI через C3D
Ранее мы тоже работали с PMI, с форматами STEP, JT и передавали их через объекты, которые не были предназначены для чтения и записи. Они имели другой префикс, и при их создании не предполагалось, что они будут читаться и записываться именно в формат С3D. Задача, которая стояла перед нами, сводилась к тому, что PMI тоже необходимо передавать. Раньше данные передавались в виде специализированных объектов, порой представляющих собой замысловатые творения. Сейчас они передаются как полноценные объекты и могут быть просчитаны, то есть PMI – это размеры, аннотация, численные характеристики. От старой аннотации, в избежание дублирования, мы планируем избавиться. Чтобы такой переход был менее болезненным, мы реализовали публичные функции преобразования между старой и новой формами. Здесь приведен примерный псевдокод, демонстрирующий, как на адаптационный период можно перевести одни объекты в другие.
Рис. 8. Бесшовная активация плагинов
Раньше для того, чтобы загрузить плагин и с помощью него прочитать что-то, нужно было сделать ряд дополнительных действий. Необходимо было получить экземпляр конвертера, сделать для него загрузку плагина, причем какие-то настройки передавать через специальные свойства. Если это наш плагин, то через специальный ключ, нашу сигнатуру. Только после этого можно было запускать отдельную функцию чтения, а затем – все это освобождать и с этим больше не работать.
Рис. 9. Бесшовная активация плагинов
Подобные дополнительные действия явно неудобны, и в настоящее время работа с конвертерами нативных форматов и IFC выглядит следующим образом: используется та же функция ImportFromFile, которая предшествует активация ядра. Сейчас ключ активации может содержать поля, необходимые для работы всех компонентов, которые он распознает. Для того чтобы плагин «подхватился», необходимые библиотеки из комплекта поставки нужно разместить там же, где лежат приложение и ядро C3D. В этом случае они активируются на автомате, а порог использования – снижается. Так просто, без переписывания кода, то есть только по складыванию файлов, можно добиться того, что сейчас в приложениях на базе C3D можно читать файлы формата Creo, NX, SolidWorks, IFC.
Анонсируя планы, я снова обращаюсь к теме новых поддерживаемых форматов, и одна из основных работ – это работа по передаче геометрии и метаданных IFC. Причем наши коллеги из компании SoftDev уже разрабатывают компоненты и для других форматов и также готовы передавать те же метаданные.
Мы продолжим работу над форматом Creo, поддержку Invertor и других направлений. В первую очередь мы ориентируемся на требования наших пользователей. Отдельно следует отметить задачу, касающуюся формата IFC. Возможен другой вариант работы, не через наш стандартный механизм чтения. Мы знаем, что у некоторых наших заказчиков есть собственные решения для чтения, в которых разделяются метаданные и строятся тела. Построение тел в граничном представлении – это одна из самых сложных задач, и мы намерены эту задачу максимально упростить, подогнать исходные данные под IFC. Из коробки планируем реализовать чтение формата 3mf и включить в поддержку полигональные объекты ядра.
Александр Спиваков,
руководитель отдела разработки C3D Converter
C3D Labs
