OpenCascade

Время идет, накапливаются вопросы от читателей. Было принято решение такие вопросы (по согласованию с авторами) публиковать, чтобы из этого произросла какая-нибудь польза. Итак, новая рубрика — «Вопросы от читателей».

Вас не должно смущать, что OpenCascade реализован на языке C++. Достаточно привести пример другого ядра — C3D или ACIS — чтобы убедиться как минимум в приемлемости такого решения. C3D выдерживает очень серьезную конкуренцию, даже будучи поставленным рядом с «лучшим ядром всех времен и народов» Parasolid. Последний, правда, написан на Си, но это скорее результат исторического стечения обстоятельств. Впрочем, Parasolid — очень закрытое ядро, и судить о нем непросто. На мой взгляд, для разработки сапровских ядер абстракции ООП незаменимы. Мне трудно представить как, скажем, на языке Си (без ООП) абстрагировать такие ключевые понятия как фичеры (features) — они отлично формализуются именно средствами объектно-ориентированного подхода. Быстродействие же ядра реально зависит от качества реализации его алгоритмов. Скажем, OpenCascade реализует собственную линейную алгебру, которая на порядки медленнее современных реализаций средствами, например, Eigen (библиотеки, которая, кстати, написана на C++ и использует всю мощь шаблонов).

Против Си не агитирую и не имею подобных мыслей. Напротив, это чистый и понятный язык, который должен хорошо подойти для низкоуровневой геометрии. Однако, на мой взгляд, технология почти не имеет значения. В больших и сложных «экосистемах» геометрических ядер работают другие законы. Чтобы написать хорошее ядро, я уверен, нужно свято блюсти такие принципы как модульность, научный подход к документированию (это очень серьезно), интенсивное полномасштабное автоматическое тестирование, встроенные в алгоритмы средства отладки и т.д. Парасолид крут, но не потому, что он на Си, а потому, что его используют миллионы инженеров по всему миру, его тестовая база содержит миллионы сценариев, в него угрохано что-то около 850 человеко-лет разработки, и его команда программистов и ученых способна тянуть такой проект. Кадры решают если не все, то очень многое.

Что касается C++, то его выразительные средства оказались хороши для реализации объектной модели по стандарту ISO-10303 (STEP), часть 42. Переписать каскейд на Си не получится. Полиморфизм, наследование и проч. ООП механизмы пронизывают его полностью.

ACIS реально фигурирует в научных статьях, причем нередко. Многие области инженерии требуют разработки специфических подходов, использующих геометрические модели и точные алгоритмы САПР. Другое дело -- разработка самих этих сапровских алгоритмов. Писать «под ACIS» или «под Parasolid» значит заведомо делать продукт, привязанный к конкретному вендору. Многие алгоритмы просто не будут работать на других ядрах. CAD-сообщество пыталось с этим бороться. Так, например, был введен интерфейс Djinn, который должен был дать унифицированный API к любому ядру. Но эта идея так и угасла в академической среде, поскольку она конфликтует с рыночными интересами основных игроков.

Мат. обеспечение, если говорить о низкоуровневой линейной алгебре и подобных вещах, можно сегодня делать на открытых библиотеках, т.е. независимо от вендоров. А вот алгоритмы моделирования, например, конвертация конструкторской модели в расчетную, операторы прямого редактирования (аля push/pull), расчет кинематики механизмов и проч. -- тут гораздо сложнее. Открытых средств часто нет. Многократно встречал статьи, научный результат которых может быть воспроизведен только с ACIS или Parasolid. Если у вас нет такого ядра, то вы вне игры. Это те самые «плечи гигантов», на которые желательно вскарабкаться исследователю от САПР для решения определенного круга задач. Далеко не все необходимое есть в OpenCascade. Скажем, нет операции «умного» удаления грани, нет тех же самых эйлеровых операторов, нет операций деформации тела и т.д. Другое дело, что в OpenCascade их можно добавить, но это нетривиально.

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

1. Какова общая архитектура ядра? Как организован API «вширь» (набор функций) и «вглубь» (что можно тонко настроить).
2. Какой фреймворк для прототипирования алгоритмов и приложений предоставляет ядро? Так, в OpenCascade это Draw, в ACIS -- Scheme AIDE. В Парасолиде -- не знаю, но есть мнение, что там фреймворк один из лучших.
3. Если есть возможность заглянуть в исходники, то из них тоже можно многое понять. Но исходники никто никогда не отдаст.

Особый интерес представляет документация, особенно, если она оформлена в виде научных статей или подробных технических отчетов. Геометрические алгоритмы формируются эволюционно, и старые архитектурные или идеологические ошибки имеют свойство мстить за себя. Плохое проектирование алгоритма непросто пересмотреть -- это очень затратный процесс. Но автор этих строк всегда с большим вниманием относится к сторонним геометрическим ядрам и пытается извлечь как можно больше информации об их устройстве. Чтобы достичь успеха нужно ведь знать не только типовые ошибки в своей области, но и лучшие практики.

Резюмируя, серебряной пули -- все-таки нет. Разработка ядра -- это серьезный научно-исследовательский проект, который должен вобрать в себя десятки и сотни человеко-лет труда. Кроме того, обязательно должна быть САПР, где будут «оседать» все улучшения ядра и новые фичи. OpenCascade -- это хорошее ядро, уже достаточно серьезно индустриализованное, но, увы, несравнимое с главными коммерческими игроками. Все поправимо, просто нужно грамотно поставить диагноз, чтобы назначить лечение.

OCAF -- это набор кирпичиков, позволяющих организовать ваши данные иерархически. В нем нет такой широко употребительной абстракции как «сборка» или «компонент сборки», но есть инструментарий, с помощью которого вы можете выразить эти типы данных самостоятельно. Есть и некоторые готовые решения, например, XDE, в которых иерархия меток (TDF_Label) призвана отражать структуру сборки, но это не более, чем пример использования окафа. Насколько я понял ваш вопрос, вас интересует, не воссоздается ли структура BREP в дереве OCAF. Нет, этого не происходит. Ваша геометрическая модель (экземпляр TopoDS_TShape) хранится в динамической памяти, а OCAF лишь использует внутренний указатель на эту модель. Другой вопрос, ЧТО вы называете «сборкой»? Повторюсь, в структурах данных OpenCascade такого типа как «сборка» нет, равно как нет этого типа и в окафе (даже в XDE это все присутствует в неявном виде). Сборки, как наборы взаимосвязанных деталей, появляются на уровне пользовательских приложений, то есть вне библиотеки.

Формат BREP -- это формат представления модели, такой же как STEP или IGES, только менее богатый. В нем нет ничего, кроме геометрии, нет мета-данных, нет даже версионирования. Этот формат обычно используется только для внутренних нужд передачи данных, и ни одна CAD-система извне такой файл не прочтет (просто потому, что это никому не нужно). Поэтому, если вам нужны мета-данные, то формата BREP не хватит. В зависимости от того, какие конкретно данные вы хотите сохранить рядом с геометрией, возможны разные варианты. Если, например, вам достаточно иметь имена объектов, цвета и прочие стандартные атрибуты, то можно записать STEP-файл. Если нужно что-то более специфическое, то придется использовать свой собственный формат. Можно использовать, например, OCAF.