Как математическая библиотека КОМПАС-3D превратилась в C3D Toolkit для разработчиков САПР → часть 1

в 13:44, , рубрики: 3d kernel, api, c3d, c3d toolkit, C3DKernel, cad, cad сапр 3D ядро, CAD/CAM, аскон, Блог компании АСКОН, геометрическое ядро, математика, ооп, сапр, ядро, метки: , , , ,

В предыдущих постах мы рассказывали о том, как разрабатывается и тестируется САПР КОМПАС-3D. Дополнительно запущен цикл статей по разработке приложений с использованием API КОМПАС-3D. Пришло время рассказать о «начинке», которая управляет всеми построениями в КОМПАСе – ядре геометрического моделирования C3D или просто геометрическом ядре C3D.

Как математическая библиотека КОМПАС-3D превратилась в C3D Toolkit для разработчиков САПР → часть 1 - 1
Автолестница пожарная АЛ-30 (изготовитель: ООО «Пожарные Системы»)

Зачем нужно геометрическое ядро, когда имеется доступ к API CAD-системы?

Наличие в CAD-системе интерфейса прикладного программирования API позволяет расширять возможности системы проектирования и способствует значительному сокращению времени разработки дополнительных программных компонентов к уже имеющейся на предприятии САПР. Это достигается за счёт использования готового набора функций, представленных в удобной и понятной для разработчика форме. Как правило, внутренняя реализация таких функций скрыта от программиста-пользователя API и представляет собой объект интеллектуальной собственности обладателя исходных кодов программного обеспечения.

Особенности работы с интерфейсом прикладного программирования прописываются в технической документации. Здесь же указывается, какие значения необходимо подавать на вход конкретной функции, чтобы получить на выходе корректные значения согласно предназначению данной функции. То есть API позволяет абстрагироваться от реализации отдельных программных блоков при разработке приложений:

Как математическая библиотека КОМПАС-3D превратилась в C3D Toolkit для разработчиков САПР → часть 1 - 2
Работа с API-интерфейсом по принципу «чёрного ящика»

Благодаря наличию в КОМПАС-3D собственного API базовая функциональность системы с течением времени была дополнена приложениями для проектирования радиоэлектронной аппаратуры и электрооборудования, деталей машин, трубопроводов, металлоконструкций, зданий и сооружений различного назначения.

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

Большинство современных САПР базируются на дереве построения 3D-модели, а значит каждая новая операция приводит к перестроению всего дерева, поэтому с помощью ядра намного проще проводить итерационные построения, в частности создание зубчатых передач:

Как математическая библиотека КОМПАС-3D превратилась в C3D Toolkit для разработчиков САПР → часть 1 - 3
Коническая передача, построенная приложением «Shaft» без использования геометрического ядра: множественные операции построения скрыты в макроэлементе

Как математическая библиотека КОМПАС-3D превратилась в C3D Toolkit для разработчиков САПР → часть 1 - 4
Коническая передача, построенная приложением «Валы и механические передачи» с использованием функциональности геометрического ядра: для построения зубцов требуется всего две операции (Картинка кликабельна)

С применением в разработке геометрического ядра уменьшается вероятность поломки модели при смене пользователем версии приложения, да и в целом повышается стабильность работы программы при непредсказуемых действиях пользователей. А включение математической библиотеки в основу разрабатываемого решения позволяет обеспечить независимость от существующих программ. Как минимум, это означает, что не нужно тянуть за проектом дистрибутив сторонней (часто тяжелой) системы и производить лицензионные отчисления за использования связанной САПР. Тем не менее, последнее утверждение нельзя считать весомым аргументом, так как разработчики приложений часто ориентируется на аудиторию конкретной CAD, CAM или CAE системы, иногда достигающей значения в десятки и сотни тысяч активных пользователей.

Геометрические и игровые ядра

Набор геометрических функций в САПР образует в совокупности геометрическое ядро системы, которое отличается от игрового движка с реалистичной 3D-графикой. Наиболее наглядно это демонстрируется через аналогию с графическими редакторами. Как известно, часть из них работает с растровой графикой, основанной на точках. Другие редакторы оперируют векторной графикой, которая базируется на кривых линиях. Точно также в 3D-приложениях существует полигональная графика, которая основывается на положении точек в пространстве (из них строятся полигоны), и сплайновая графика, представляющая собой сочетание математических формул и уравнений.

Выражаясь в терминах САПР, можно сказать, что полигональная графика строится на фасетном представлении геометрии. Такое же представление используется в игровых движках и в различных анимационных пакетах для создания спецэффектов кино:

Как математическая библиотека КОМПАС-3D превратилась в C3D Toolkit для разработчиков САПР → часть 1 - 5
Фасетное представление геометрии 3D-модели

Математически точное описание 3D-модели задаётся граничным представлением. Его основная особенность в том, что для представления формы геометрической модели используется набор граней, проходящих по границе, которая отделяет внутреннее пространство моделируемого объекта от остальной части пространства. Как вы уже, наверное, догадались – именно это представление используется в геометрических ядрах:

Как математическая библиотека КОМПАС-3D превратилась в C3D Toolkit для разработчиков САПР → часть 1 - 6
Граничное представление геометрии 3D-модели

Но тогда почему для геометрического ядра не подходит полигональная графика?

Можно выделить три основных причины:
Масштабируемость. Любой объект необходимо беспрепятственно увеличивать и уменьшать. Дефекты геометрии неуместны.

Как математическая библиотека КОМПАС-3D превратилась в C3D Toolkit для разработчиков САПР → часть 1 - 7
Охотничье хозяйство в натуральный размер. При увеличении модели все грани сохраняют форму (Картинка кликабельна)

Гладкость. Сетка из треугольников для работы с чертежами не подходит — на чертеже нужны гладкие и чёткие контуры, а сетка создаст визуальную грязь.

Как математическая библиотека КОМПАС-3D превратилась в C3D Toolkit для разработчиков САПР → часть 1 - 8
Пример передачи фасетной модели в чертёж. Видно как сливаются места сгущения сетки (Картинка кликабельна)

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

Как математическая библиотека КОМПАС-3D превратилась в C3D Toolkit для разработчиков САПР → часть 1 - 9
Обработка модели в CAM-системе Esprit

В действительности же причин значительно больше, но это – профессиональные тонкости.

Невероятно, но факт: современные системы проектирования (и КОМПАС-3D – не исключение) работают с двумя представлениями геометрии. Граничное представление используются в процессе моделирования, после чего производится расчёт триангуляционной сетки и строится полигональная модель, которая затем отправляется в видеокарту для отрисовки визуальной сцены. На данном этапе в процесс может вмешаться ядро визуализации, например C3D Vision, которое отвечает за управление отрисовкой модели с использованием средств математической, программной и аппаратной оптимизации. Подробнее об этом мы расскажем в следующих статьях.

Сложный выбор: купить ядро или написать собственное?

Каждый разработчик инженерного программного обеспечения рано или поздно оказывается перед выбором: писать ли необходимые математические алгоритмы самому или приобрести готовые компоненты на стороне? В истории АСКОН использование сторонних модулей рассматривалось в 1995 году, когда обсуждалась разработка КОМПАС-3D. Тогда был выбран тернистый пусть самостоятельного написания геометрических функций, в основе которых лежит довольно сложная математика. Подробнее ознакомиться с ней можно, прочитав книгу Николая Голованова по геометрическому моделированию:

Как математическая библиотека КОМПАС-3D превратилась в C3D Toolkit для разработчиков САПР → часть 1 - 10Как математическая библиотека КОМПАС-3D превратилась в C3D Toolkit для разработчиков САПР → часть 1 - 11
Оглавление и обложка книги «Геометрическое моделирование» Н.Н. Голованова (Картинки кликабельны)

Мало кто знает, что позднее, в 2000-х годах, в АСКОН повторно рассматривался вопрос использования стороннего математического ядра для работы с 3D. Было произведено тестирование доступных на рынке CAD-компонентов и принято стратегически важное решение о продолжении разработки собственного геометрического ядра. Оно получило имя C3D, что является сокращением от внутрикорпоративного названия проекта «Core3D». Сегодня это ядро успешно используется не только внутри АСКОН, но и в проектах других разработчиков систем автоматизированного проектирования в России и за рубежом.

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

Как математическая библиотека КОМПАС-3D превратилась в C3D Toolkit для разработчиков САПР → часть 1 - 12 Аркадий Камнев, Менеджер по продукту C3D.

Автор: АСКОН

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js