Александр Спиваков, руководитель команды разработки C3D Converter, C3D Labs, описывает роль конвертера в качестве части C3D Toolkit, представляет сценарии использования C3D Converter — миграция и MultiCAD — в пользовательских приложениях, знакомит с доработками решения, сделанными в контексте этих задач, и планами развития конвертера.

Что собой представляет C3D Converter в составе C3D Toolkit и зачем он нужен? Глобально перед нами стоят две задачи.

Первая — обеспечить все остальные компоненты C3D Toolkit исходными данными для работы в их предметной области (это касается и C3D Modeler, и C3D Vision, и C3D B-Shaper). В отношении этой задачи речь идет об импорте или чтении файлов. Вторая задача — симметричная. При наличии некой 3D-модели, созданной остальными компонентами, возникает необходимость передать ее в часть приложения или большой системы, которые нашими возможностями явно не покрываются. Это может касаться расчетных процессов, печати и т. д.

Что мы для этого используем?

Существуют два основных подхода. Стандартный связан с чтением и записью файлов разных форматов. Это форматы как с открытой спецификацией, так и принадлежащие грандам. Вторая группа более многочисленна и представлена как форматами ISO STEP и JT, так и широко распространенными на практике — 3MF, IGES, OBJ, STL и др. Альтернативный подход более кастомизированный — использование плагинов для чтения форматов, которые не входят в "коробку". Нашим основным объектом является форма тел. Как бы она ни была представлена — в виде граничных представлений, полигональных объектов, точек, кривых — мы ее передаем. Кроме того, конвертеры отвечают за корректную передачу структуры сборки, атрибутов и PMI.

Остановимся на двух особенных сценариях, в которых C3D Converter используется максимально.

Сценарий миграции на конечнопользовательские приложения

Ускоренный сценарий - это миграция на какие-то конечнопользовательские приложения. Рассмотрим миграцию со стороннего вендора, допустим SolidWorks или AutoCAD, к примеру на КОМПАС-3D либо nanoCAD. Что мы имеем исходно? Предположим, в некоторой компании есть информационная система, в основе которой лежит продукция западного вендора. В этой системе доминирующую роль играет САПР, изначально также от разработчиков из-за рубежа. С течением времени оказывается, что для выполнения задач этой компании больше подходят отечественные решения ввиду разнообразных причин. Что должно получиться на выходе? В результате должны быть установлены копии наших программ и, соответственно, вся база документов и моделей — также переконвертирована. В данном случае речь идет именно о полной миграции данных. С подобным сценарием мы сталкиваемся, когда получаем запросы на доработку или запросы на исправление ошибок. Это достаточно сложная проблема, но иногда нам приходится ее решать.

Рассмотрим, что на самом деле может собой представлять информационная система какого-либо предприятия.

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

Сценарий встраивания в устоявшуюся экосистему

Есть ряд причин, почему нельзя оперативно мигрировать и применяют более консервативный сценарий. Во-первых, сроки миграции могут быть слишком внушительными. Иными словами, может потребоваться большой объем доработок, реализация которых займет время. Помимо этого, может обнаружиться необходимость доработки со стороны конечных пользовательских приложений. Причем недостаточно только доработать, изменения нужно внедрить, провести тестирование, а это вновь повлечет за собой временные издержки. Во-вторых, на предприятии заказчика, действительно, могут протекать сложные живые процессы, из-за которых нельзя просто взять и отказаться от имеющегося инструментария, без возможности отката к предыдущей системе. В-третьих, миграции могут препятствовать иные обстоятельства, связанные непосредственно с какой-либо отраслевой спецификой. С нашей точки зрения, эта система называется MultiCAD.

Пример

Добавим конкретики на примере экосистемы на базе системы NX.

В этом случае мы внедряемся в сферу САПР и замещаем, предположим, КОМПАС-3D в NX. Также нам нужно обеспечивать поддержку формата, который изначально предназначался для чтения PLM-системой. Следовательно, задача выглядит так: нужно читать и записывать JT и читать формат .PRT. Что передаем? Передаем всё. То есть это и B-Rep, и Mesh, и PMI.

Формат JT в C3D Labs поддерживается с 2018 года. Казалось бы, что нового может произойти с тех пор?

На самом деле, нововведений достаточно. Во-первых, это формат ISO, который пересматривается раз в пять лет. На момент разработки мы поддерживали версию 2012 года, сейчас актуален ISO 2017, и в ближайшее время его заменит версия ISO 2022 и ISO 2023. Во-вторых, существует вторая ветка формата JT — это то, что поддерживает непосредственно Siemens. Компания, естественно, выпускает обновления, но не сообщает об этом и не публикует соответствующую документацию. Тем не менее читать мы ее должны. В-третьих, вне форматов и документации особое значение имеет практика применения. Когда, кажется, все соответствует требованиям стандартов и документации, но при этом все-таки не работает.

Рассмотрим подробнее формат JT

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

Граничное представление (B-Rep)

Отдельного внимания заслуживает граничное представление (B-Rep).

В формате JT оно хранится, судя по практике использования, в виде Parasolid X_T. В части чтения поддержка актуальных версий Parasolid X_T — наша ежегодная работа, которую мы выполняем на регулярной основе. Сложнее было с записью. В ответ на записанные файлы в формате JT приходили обеспокоенные ответы заказчиков, которые не могли прочесть точные модели. При этом, если мы записывали те же файлы в X_T, сложностей с чтением не возникало. Нам удалось разобраться, что служило помехой. Дело в том, что формат X_T предоставляет такую возможность, как запись внедренных схем. Это средство совместимости разных версий между собой. То, что ранее представлялось некритичным, в определенный момент стало препятствием. Такими методами, как пристальное всматривание и эксперименты, мы научились записывать детали, и они также стали открываться в NX, обеспечив возможность дальнейшей работы.

Трудности со сборками

После того как была решена проблема с деталями, возникли трудности со сборками.

Когда мы осуществляли экспорт с помощью редуктора из КОМПАС-3D, то получали смещение в начало координат. Это реальный случай из практики использования. За структуру сборки в формате JT отвечает сегмент LSG (Logical scene graph), в котором имеется множество разных сущностей (Metadata, Instance, Part, Group и пр.). Какую из них использовать — большой вопрос. С одной и той же моделью случались диаметрально противоположные ситуации. При открытии в JT2Go все детали оказывались на местах. При открытии в САПР — происходило смещение. Однако и с этими требованиями NX мы разобрались, унифицировали конвертер в соответствии с требованиями, не потеряв в производительности еще и в других системах.

Чтение нативных форматов

Один из самых сложных вопросов — это чтение нативных форматов .PRT.

Такая задача стояла перед нами с 2019 года, и тогда у нас был выбор — делать полностью собственное решение или лицензировать сторонний компонент. Тогда наши заказчики — разработчики КОМПАС-3D — приняли решение лицензировать пакет Capvidia, который поддерживает не только .PRT, но и множество проприетарных форматов САПР. Мы должны были написать соответствующий модуль интеграции. С одной стороны, мы писали часть модуля исходя из требований Capvidia, с другой стороны, готовили ответную часть на базисе 3D. За год мы научились читать не только формат .PRT, но и еще порядка десятка других форматов (сканированные сетки, сборки и т. д.). Однако, как оказалось, то, что легко достается, еще легче потерять. Сегодня в нашем распоряжении остался интерфейс плагинов. Какое решение было принято? Мы нашли нового технологического партнера. Им стала компания CAD Exchanger, и ее специалисты, своими силами и за достаточно короткий промежуток времени, фактически восстановили полную функциональность того, что было сделано. Проблем с чтением больше не возникало. Тем не менее опыт оказался болезненным, и параллельно мы стали разрабатывать собственное решение, вернувшись к этой идее. Теперь те же самые иллюстрации мы получаем из решения, которое сами же и написали.

Интересные задачи

Обратимся к интересным задачам.

Правку ошибок никто не отменял. Что мы сделали? При вычислении Parasolid мы столкнулись с новым случаем — потребностью делать скругления по двум кромкам. В рамках предобработки нам пришлось плодотворно поработать в формате JT, в частности с единицами длины, геометрией.

Кроме того, «из коробки» у нас появилась поддержка нового формата 3MF.

Это формат для 3D-печати, где требования к сеткам гораздо более строгие, но и на выходе должен получаться результат, наиболее подходящий для 3D-принтеров.

Планы

Рассмотрим планы развития C3D Converter.

Если говорить о «коробочном» решении, то задача — научиться читать формат 3MF, поддерживать формат SAB в дополнение к SAT и продолжить совершенствовать качество трансляции. Что касается плагинов, мы поддерживаем .PRT, однако не намерены на нем останавливаться: следующие по списку — SolidWorks, Creo и IFC. При этом в отношении SolidWorks уже проделана значительная работа. Многое мы можем читать, и существуют примеры сборок, засчитанные уже нашим решением, на которых видны и сборки, и некоторые элементы PMI.

Александр Спиваков

Руководитель команды разработки C3D Converter
C3D Labs