SPATIAL, ACIS, CGM и будущее геометрических ядер

Я впервые принял участие в камерной конференции, в которой приняло участие примерно 60 человек, не считая сотрудников Spatial с учеными степенями по математике, немного похожими на яйцеголовых ботаников. Подобные конференции Spatial ежегодно проводит для своих лучших клиентов, чтобы рассказать им о состоянии дел и планах. Spatial — скромная по размерам компания, в ней работает около 100 сотрудников. Специализация компании — создание программных компонентов для использования в сторонних CAD/CAM/CAE системах. С 2000 года Spatial — дочерняя компания Dassault Systemes.

Наиболее известные продукты Spatial — это широко известное геометрического ядро ACIS и набор трансляторов для 3D-данных 3D InterOp. Менее известные продукты: другие геометрические ядра CGM (Convergence Geometric Modeler) и GGCM (General Geometric Constraint Manager), а также геометрический решатель CDS (Constraint Design Solver), все они достались Spatial от DS, где используются в CATIA V5 и V6. Все эти продукты — весьма интересные, но в этой заметке я остановлюсь лишь на наиболее известных и влияющих на жизнь многих CAD/CAM/CAE-пользователей — на геометрических ядрах ACIS and CGM.

ACIS

Эта возможность очень многое значит для пользователей ACIS. Например, присутствовавший на конференции представитель SpaceClaim сказал, что его компания будет использовать все продвижения по многопоточности, которые будут реализованы в ACIS. В общем, вполне ясно, что Spatial тратит много сил на внедрение многопоточности в ACIS. Однако, это обстоятельство мало что значит само по себе. Вспомним, что Spatial уже более двенадцати лет работает над механизмами многопоточности для ACIS, однако, за все эти годы удалось решить только несколько самых первоочередных задач. Скажем, многопоточность сравнительно легко реализуется, если в загружаемом файле имеется полигональное представление, но так бывает далеко не всегда. А что насчет обработки сопряжений сложных цепочек ребер в рамках одной детали? Вот это уже по-настоящему трудно.

Уже много лет я обсуждаю проблемы многопоточности с несколькими весьма опытными разработчиками САПР. Мы пришли к единодушному выводу: существует только несколько процессов (внятно декомпозируемых, без зависимостей), которые можно сравнительно легко реализовать в режиме многопоточности. В остальных же случаях внедрить многопоточность в программную архитектуру — весьма трудная задача: если только вы не заложили соответствующие возможности с самого начала. И такие возможности не были с самого начла заложены в ACIS, поэтому внедрить их теперь — огромная работа. Я впечатлен прогрессом, который продемонстрировали разработчики в Spatial, но будущее не сулит никаких чудес. Еще раз уточню: единственный вариант использовать преимущества многопоточности состоит в том, чтобы предусмотреть ее возможности разрабатывая новое геометрическое ядро с новой архитектурой.

CGM

Первые отзывы на этот релиз оказались положительными: клиентам Spatial (независимым вендорам) понравилась базовая функциональность, интерфейсы, документация. Но им не понравился огромный объем памяти, которого требует работа CGM. Во втором релизе CGM, Spatial добавил интерфейсы для большего числа операторов моделирования, а также расширил набор InterOp-форматов, реализовал поддержку 3DXML и поддержку обработки облаков точек.

Spatial не позиционирует CGM как ядро общего назначения, предназначенное на все случаи жизни. Это ядро нацеливается на поддержку определенных классов задач, для начала — задач метрологии и CAM. Однако по мере того, как Spatial реализует интерфейсы для всех операторов моделирования, продукт станет основой для любых продуктов, вплоть до полномасштабного САПР.

Фундаментальный вопрос относительно CGM состоит в том, является ли эта программа практической альтернативой Parasolid или ACIS (и, в данном контексте — Granite от PTC). Для нынешних применений — ответ: нет, не является. У вас ничего не выйдет, если вы попытаетесь заменить Parasolid или ACIS на CGM. Вопрос не в том, что лучше или хуже (хотя в некоторых приложениях такой вопрос правомерен): просто CGM будет работать совершенно не так.

У CGM есть одно качество, отсутствующее у других геометрических ядер: полная B-rep-совместимость с CATIA V5 и V6. Это выгодно тем независимым вендорам, которые хотят работать в экосистеме DS, но у которых недостаточно квалификации (или терпения!) для того, чтобы стать партнерами DS по разработкам (CAA — Component Application Architecture).

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

Помимо технических проблем, у CGM есть и другие: одна из них цена лицензирования. Дело в том, что DS (и, следовательно, Spatial) очень гордятся своим продуктом и оценят его выше, чем AСIS. Независимые вендоры, создающие свои CAD/CAM/CAE и другие подобные системы, часто лицензируют чужие технологические компоненты (например, ACIS, HOOPS, DCM и т.п.) на основе royalty — отчислений процентов от своих релевантных доходов. Такие отчисления могут находиться на уровне 15-17%, и ясно, что будет трудно убедить кого-то, что за CGM стоит платить лишние деньги — если совместимость с CATIA не является для покупателя решающим фактором.

Короче говоря, CGM развивается в сторону полноценного геометрического ядра, однако, вряд ли сможет заменить ACIS or Parasolid, и уж точно не является «геометрическим ядром будущего», которое сможет превзойти своих нынешних конкурентов.

А как насчет SolidWorks V6?

Я думаю, что для разработки своих продуктов SolidWorks будет использовать всю инфраструктуру DS CATIA/ENOVIA V6, но это — только мое предположение. И еще мне кажется, что для чтения существующих файлов SolidWorks, в SolidWorks V6 было бы разумно использовать недавно созданный в Spatial модуль для непосредственного чтения файлов Parasolid. В кулуарах той же конференции я побеседовал со своим старым приятелем — прекрасно разбирающимся в читалках файлов — и спросил его: есть ли принципиальная техническая возможность построить читалку для Parasolid, которая сможет обеспечить 100-процентную точность. Приятель ответил, что это возможно, объяснив, что Parasolid как раз отличается тем, что его форматы прочитать легче других потому, что в нем меньше странностей и глупостей (эти термины — не технические!). Понятно, что все разговоры о поколении продуктов SolidWorks V6 основаны лишь на догадках: ведь они будут выпущены не раньше начала следующего года. Однако представляется, что у Dassault Systemes есть достаточно ресурсов, чтобы будущие продукты оказались интересными и конкурентоспособными.