Геометрическое ядро и его влияние на разработку продуктов

В течение последних несколько лет наблюдается явно повышенное внимание к теме геометрических ядер для САПР. Не последнюю роль в этом сыграли слухи о том, что Dassault Systemes собирается заменить ядро в SolidWorks. Впрочем, на мой взгляд, сегодня уже стало ясно, что Dassault не имеет планов такой замены, а, скорее, создает на основе своего ядра новый продукт.

И все-таки, в чем же суть всего этого шума вокруг геометрического ядра? Что нам за дело до того, какое именно ядро находится под оболочкой нашего любимого САПР-инструмента? Стоит ли нам об этом думать? Знаете ли вы, как геометрическое ядро может повлиять на ваши возможности эффективного конструирования ваших продуктов? Удивительно, что ответ на эти вопросы зависит от множества факторов.

Я сознаю, что мое дальнейшее рассуждение представит проблемы несколько упрощенно, это меня не останавливает. По своей сути, САПР-ядро — это геометрический вычислитель, движок. Он воспринимает команды, выполняет их и выдает результаты. Чаще всего, эти результаты представляют собой некоторые геометрические данные. Каждое рыночное геометрическое ядро может иметь те или иные уникальные свойства.

• Команды, или «функции», поступающие на вход ядер, весьма специфичны для каждого ядра. Кроме того, каждой функции соответствует специфичный набор аргументов или параметров, с которыми функция имеет дело. Разумеется, все эти данные должны быть представлены ядру в подходящем формате. Стандартов для функций/команд ядра не существует.
• Помимо этого, ядра задают геометрию самыми разнообразными способами. Некоторые из них работают с аналитической геометрией, некоторые — с B-сплайнами, другие — с NURBS. А есть и такие, которые понимают все упомянутые формы представления и в своей работе умеют их успешно сочетать. Стандартов для взаимодействия форм представления также не существует.
• Геометрические ядра также различаются по возможностям работы с (геометрической) точностью. Некоторые ядра более стабильны, когда имеют дело с низкой точностью, другие — более эффективны при работе с высокой точностью. Большинство ядер позволяют САПР-системам настраивать точность геометрии и управлять ею: либо предварительной настройкой, либо — автоматически. И для параметров точности для геометрии в САПР также не выработано никаких стандартов.
• Наконец, и геометрические вычисления иногда производятся в разных ядрах по-разному. Возможно, проще всего это различие усмотреть на примере функций скругления (round) или сопряжения (blend) углов. Каждое ядро вычисляет геометрическое место точек по-разному: это проявляется очень наглядно. Для вычислений этого типа геометрии стандарта не существует. Ниже приводятся примеры, взятые из некоторых САПР, наиболее популярных на рынке. Посмотрите внимательно на разницу в топологиях этих примеров. Отметьте, как по-разному в этих примерах генерируются планарные грани. Как правило, по одному взгляду на то, как выполнено скругление углов, мне удается определить, какая из САПР была использована для создания 3D-модели. Повторяю: для этих типов вычислений стандартов нет.

Во всех четырех случаях мы имеем одну и ту же геометрию, сопрягаемую одним и тем же радиусом
Все сопряжения выполнены одной операцией

Это были примеры некоторых значительных различий. Их можно привести гораздо больше — особенно, в области моделирования поверхностей свободной формы.

Итак, вернемся к вопросу: что все эти свойства ядер означают для процесса создания продукта?

Работая с САПР, мы обычно строим два уровня информации. К ВЕРХНЕМУ уровню относится определение конструктивных элементов (features), включая любую импортированную или неупорядоченную геометрию, эскизы, параметры и другие функции моделирования. Все это — дерево истории построения, или, как скажут некоторые — «намерение проектировщика» (design intent). К НИЖНЕМУ уровню относится результирующая геометрия. (Разумеется, используя прямое моделирование, вы будете иметь дело только с нижним уровнем.) При переносе САПР-данных с одного ядра на другое придется рассмотреть оба уровня.

Сначала рассмотрим более сложный — ВЕРХНИЙ уровень. (Те из вас, кто работает c прямым моделированием, могут пропустить этот абзац и сразу перейти к рассмотрению НИЖНЕГО уровня.) Параметрический и основанный на истории построения САПР по определению хранит в дереве каждую функцию, посылаемую в ядро. Эти функции вместе с их параметрами группируются в определение «параметрического конструктивного элемента» («parametric feature»). Например, эскиз с размером выдавливания определяет собой геометрический примитив. Ограничения («constraints») контролируют размеры и расположение нового примитива. Затем добавляется булева функция, которая должна сигнализировать, добавляет или вычитает данный примитив соответствующий объем в родительской геометрии. Эта булева функция с примитивом и соответствующими параметрами передается в ядро, где вычисляется результирующая геометрия. Данная функция ядра работает всякий раз, когда происходит обращение к этому «конструктивному элементу». Как отмечалось выше, функция ядра со всеми ее необходимыми параметрами является спецификой каждого ядра. Весьма вероятно, что функция одного ядра понималась другим ядром, и даже, если это случается, геометрические результаты могут оказаться весьма различными.

Перенос этого ВЕРХНЕГО уровня из одного ядра в другое очень напоминает попытку компилирования ФОРТРАН-программы на С-компиляторе. Это не сработает. Функции и соответствующие параметры просто не совместимы. По существу, функции, хранимые в дереве истории построения, для их работы в другом ядре необходимо транслировать в другое представление. В САПР-индустрии было предпринято несколько попыток создания трансляторов для перевода ВЕРХНЕГО уровня из одного ядра в другое, но результаты оказались весьма скромными. Кстати, это обстоятельство является одной из причин слабого прогресса в области геометрических ядер: мы находимся в плену этого ВЕРХНЕГО уровня. Внесение слишком большого объема изменений в ядро, может нарушить совместимость с предыдущими версиями истории построения, т.е. — с функциями ядра. В истории САПР можно найти много примеров этой проблемы.

Итак, перенос ВЕРХНЕГО уровня от ядра к ядру может быть источником большого риска при разработке продуктов. Трансляция должна работать безошибочно, иначе история/намерения конструктора могут быть утеряны. Между прочим, если бы все-таки удалось создать полную и надежную трансляцию ВЕРХНЕГО уровня из одного формата ядра в другой, вам вообще не пришлось бы заботиться о НИЖНЕМ уровне: в ходе обработки оттранслированного ВЕРХНЕГО уровня, целевое ядро воссоздало бы для вас всю геометрию.

Теперь рассмотрим НИЖНИЙ уровень, т.е. — геометрию (читатели, пользующиеся параметрическим моделированием и точной трансляцией ВЕРХНЕГО уровня, могут пропустить этот раздел: если только ваш ВЕРХНИЙ уровень не содержит много импортированных или неупорядоченных геометрических элементов). Как уже упоминалось, геометрические ядра способны порождать геометрию в самых разнообразных формах и с самой разной точностью. Хотя у нас есть промышленные стандарты для геометрии (IGES, STEP), повторю, что для параметров точности и конструктивных элементов таких стандартов не существует. Перенос геометрии с одного ядра на другое не проходит безболезненно. Если вы хоть раз транслировали геометрию с помощью форматов STEP или IGES, скорее всего, вам знакомы такого рода недостатки.

Ошибки или лакуны в оттранслированной геометрии могут возникнуть, например, в результате трансляции аналитических поверхностей в NURBS или — обратного процесса. Их причиной может также стать проблема точности. В других случаях негативный эффект трансляции может проявиться из-за внутренних САПР-процедур, относящихся к IGES или STEP, но не исключается, что ответственность за негативные эффекты несут экспортирующее и импортирующее ядра. Скорее всего, всем нам понятно, как некачественная трансляция геометрии может повлиять на процесс разработки продукта. Подобного рода эффекты могут встретиться при переносе геометрии с одного ядра на другое. К счастью, средствами, которые позволяют оперативно устранить несовершенства геометрии, обладает большинство современных САПР-систем, не так ли?

Итак, какое же влияние геометрическое ядро оказывает на процесс разработки продукта? Вариантов — много. Меняя ядро, вы собираетесь перенести ВЕРХНИЙ уровень или НИЖНИЙ? Видимо, можно начать с анализа «за» и «против» каждого из этих вариантов. И вот — несколько заключительных вопросов для размышления:

• Как вы полагаете, что произойдет, если для концептуального проектирования вы будете использовать одно ядро, а для детального проектирования — другое?
• Насколько устойчив ваш ВЕРХНИЙ уровень? Поддерживаете ли вы при моделировании строгие стандарты?
• На каком уровне точности вычислений работает ваше ядро? Смогут ли другие ядра, если потребуется, без ошибок воспринимать поддерживаемую вашим ядром точность?
• С каким уровнем ассоциируете вы свои чертежи: с ВЕРХНИМ или с НИЖНИМ?
• Как одновременное использование разных ядер в процессе разработки продукта влияет на концепцию единой цифровой модели?
• Какие из следующих за этапом проектирования функций управляются ВЕРХНИМ уровнем, а какие НИЖНИМ?