CFDManager/docs/cad_kernels.md

Геометрические ядра САПР: что доступно и что брать

Документ по задаче #5. Цель — выбрать геометрическое ядро, поверх которого строится САПР-часть CFDManager, и обосновать выбор, а не объявить его.

Сейчас в дереве нет ничего, что можно было бы назвать ядром: simv_mesh читает .obj через tinyobjloader, сваривает вершины и считает AABB. Ни B-rep, ни NURBS, ни булевых операций, ни параметрических форматов. Всё это придётся взять снаружи — своё ядро пишется годами и не является предметом этого проекта.

Требования и как они проверялись

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

№	Требование	Как проверялось
1	Лёгкость и оптимизированность	сборка и запуск на этой машине, вес артефактов
2	Rust-стек или доступное для Rust API	наличие крейта/биндингов, собрал и запустил
3	Базовое редактирование 3D (аналог Plasticity)	наличие булевых, фасок, скруглений, выдавливания
4	NURBS	какие поверхности представимы, что уходит в STEP
5	Стандартные параметрические и полигональные форматы	STEP/IGES на запись и чтение, STL/OBJ/glTF
6	Лицензия	текст лицензии и то, что она требует при поставке продукта

Шестое требование добавлено по следующей причине. Ядро — не библиотека утилит, его нельзя заменить за неделю; лицензионное условие, замеченное после того, как на ядре написан год работы, стоит переписывания продукта. Поэтому GPL-ядра и ядра с некоммерческой лицензией разбираются здесь наравне с техникой, а не в сноске.

Измерения выполнены на машине разработки: Windows 11, MSVC 19.37.32825 (VS 2022 Community), CMake 4.3.2, Ninja 1.13.2, Rust 1.97.1, сборки release. Числа, взятые из внешних источников, помечены явно.

---

Группа 1. Открытый исходный код

Open CASCADE Technology (OCCT)

Единственное зрелое открытое B-rep/NURBS ядро промышленного класса. Версия 8.0.1 от 30 июля 2026; семь модулей (Foundation Classes, Modeling Data, Modeling Algorithms, Visualization, Data Exchange, Application Framework, Mesh).

Форматы: STEP (AP203, AP214, AP242), IGES до 5.3, STL, OBJ, glTF 2.0, VRML 1.0 — на чтение и запись. ACIS, Parasolid, DXF, IFC, JT — только через платные компоненты Open Cascade, в открытую поставку не входят.

Лицензия — LGPL 2.1 с исключением, и исключение не то, за которое его обычно принимают. Полный текст OCCT_LGPL_EXCEPTION.txt разрешает ровно одно: включать в объектный код материал из заголовочных файлов библиотеки (инлайн-функции, шаблоны, CDL-классы) и распространять такой объектный код на своих условиях — при заметном уведомлении, что продукт использует OCCT. Про линковку исключение не говорит ничего.

Практический вывод: динамическая линковка — штатный путь, обязанности сводятся к уведомлению и к тому, что пользователь может подменить библиотеку. Статическая линковка остаётся под LGPL 2.1 §6 и требует выдать объектные файлы приложения, чтобы пользователь мог пересобрать его с изменённым OCCT. Это важно, потому что opencascade-rs со своим режимом builtin собирает OCCT статически (BUILD_LIBRARY_TYPE=Static в вызове CMake) — то есть самый удобный путь сборки оказывается как раз тем, который для проприетарной поставки неудобен.

Динамический путь существует: без builtin обвязка ищет предустановленную OCCT и, если та собрана с BUILD_SHARED_LIBS=ON, линкуется к ней как dylib (crates/opencascade-sys/build.rs:43). Но там же, строкой ниже, стоит жёсткая проверка версии: требуется мажор ровно 7 и минор не ниже 8, иначе сборка паникует. Поставить в системе свежую OCCT 8.0.1 и слинковаться с ней не получится — обвязка её отвергнет.

opencascade-rs — путь к OCCT из Rust

Крейты opencascade / opencascade-sys версии 0.3.0 (обновлены 24 августа 2026), биндинги через cxx, лицензия LGPL-2.1. Форк bschwind живой, 263 звезды; форк mkovaxx последний раз трогали в октябре 2025 — его рассматривать не стоит.

API высокоуровневый и на вид приятный:

let my_box = Shape::box_with_dimensions(10.0, 10.0, 1.0);
let another = Shape::box_with_dimensions(1.0, 1.0, 0.8);
my_box.subtract(&another).chamfer(0.07)

Есть write_step / write_iges / write_stl, read_step, mesh() с настраиваемым допуском, фаски, скругления, выдавливание, заметание по траектории.

Существенное отставание: occt-sys зафиксирован на OCCT 7.8.1, тогда как апстрим уже 8.0.1. Это не косметика — между ними мажорный релиз, и всё, что исправлено в 7.9 и 8.0, в этом пути недоступно, пока обвязку не обновят. Причём 8.0 заявлен командой OCCT3D (Capgemini Engineering) как релиз с ломающими изменениями API, чисткой интерфейсов и переработкой булевых операций, тесселяции и обработки допусков — то есть обновление обвязки будет не механическим, и ждать его быстро не стоит.

truck — чистый Rust

Единственный живой чисто-растовый B-rep/NURBS кернел. Apache-2.0, 1559 звёзд, коммиты в репозитории вплоть до 7 сентября 2026 — но крейты на crates.io не обновлялись с 20 сентября 2024 (truck-modeling 0.6.0). Два года git-активности без релиза — характерный признак: пользоваться придётся либо старым релизом, либо git-зависимостью.

Умеет: NURBS-геометрию, топологию (вершины/рёбра/грани/оболочки/тела), булевы операции (truck-shapeops), тесселяцию (truck-meshalgo), чтение и запись STEP (truck-stepio, есть и in, и out), полигональные форматы через truck-polymesh.

Остальные открытые — отсев с причиной

Проект	Состояние	Почему не подходит
Fornjot	архивирован 19 июня 2026	Автор закрыл проект: «This project has been shut down. Its goals were never reached», код read-only, пригоден лишь для «very simple models»
SolveSpace	живой, 4163★, GPL-3.0	GPLv3 несовместим с проприетарной поставкой; NURBS-булевы, по признанию самих авторов, медленные, ограничены поверхностями выдавливания и вращения и «not too robust even then»
BRL-CAD	живой, 1029★	CSG-ориентированное ядро с Tcl-инфраструктурой, не про интерактивное NURBS-моделирование
openNURBS	живой, 562★	Чтение/запись .3dm и NURBS-геометрия, но моделирования нет: ни булевых, ни фасок
curvo	живой, MIT, 0.1.91	NURBS-кривые и поверхности как математика, не B-rep ядро
Manifold	живой, Apache-2.0, есть крейт manifold3d 0.4.1 (обновлён 9 сентября 2026)	Быстрые и надёжные булевы, но по полигональным сеткам; NURBS и B-rep отсутствуют как понятие. Полезен позже — для подготовки геометрии к расчётной сетке, не как ядро
CGAL	живой	Вычислительная геометрия, не САПР-ядро; ядро GPL с платной альтернативой

Отдельно стоит отметить libslvs из SolveSpace: это решатель геометрических ограничений, то есть ровно та подсистема, которой нет ни у OCCT, ни у truck. К выбору ядра он отношения не имеет, но к параметрике — прямое (см. раздел о том, что придётся писать самим).

---

Группа 2. Закрытый код, бесплатные и некоммерческие лицензии

Задача изначально говорила про открытые ядра; рамка расширена владельцем проекта. Результат этой группы отрезвляющий: бесплатного входа в промышленное ядро нет ни у одного из четырёх.

C3D Modeler (C3D Labs)

Единственное коммерческое геометрическое ядро российской разработки, одно из пяти лицензируемых ядер в мире. B-rep с NURBS, обмен со STEP, IGES, Parasolid, ACIS, полигональными форматами. API — C++ с C-обёрткой; Rust-биндингов нет, их пришлось бы писать самим.

Публично доступна только 90-дневная пробная версия с техподдержкой. Бесплатной некоммерческой или академической лицензии в открытом доступе найти не удалось: у компании есть образовательные партнёрства с вузами, хакатоны и стажировки, но лицензия под них публично не описана и выдаётся по договорённости. Условия коммерческой лицензии компания называет гибкими и определяет индивидуально; цифра в 1 750 000 ₽ в год за лицензию разработчика плюс роялти встречается во вторичных источниках и здесь не проверена — уточнять её нужно у самой C3D Labs.

Parasolid (Siemens)

Ядро, на котором построена названная в задаче Plasticity, а также SolidWorks, NX и десятки других систем. Эталон по надёжности булевых и качеству поверхностей.

Лицензируется коммерчески; публичных условий, прайса, бесплатного или академического тарифа в открытом доступе нет — вход только через переговоры с Siemens, и по отзывам разработчиков процесс и суммы для небольших проектов оказываются заградительными. Rust-биндингов нет.

3D ACIS Modeler и CGM Modeler (Spatial / Dassault Systèmes)

Второе историческое коммерческое ядро (ACIS, с конца 1980-х) и ядро CATIA (CGM). Технически полноценные B-rep/NURBS ядра. Ситуация с лицензией та же, что у Parasolid: публичных бесплатных или академических условий нет, пробный доступ и академические программы — по запросу. Rust-биндингов нет.

Zoo Design API (бывш. KittyCAD)

Самый близкий к требованию 2 вариант: проприетарное ядро, написанное на Rust, GPU-native, выдаёт настоящий B-rep. Есть официальный Rust-клиент kittycad.rs, открытые Design Studio и язык KCL.

Но это облачный сервис, а не библиотека: геометрия считается на их серверах, тарификация поминутная, бесплатно даётся 20 минут API (баланс $10), дальше pay-as-you-go. Для настольного САПР с интерактивным редактированием это означает зависимость от сети, задержку на каждую операцию и оплату за использование, которая растёт вместе с числом пользователей. Для проекта, который сам по себе считает гидродинамику локально, такая схема противоречива.

Обмен форматами отдельно

CAD Exchanger SDK, HOOPS Exchange, ODA — не ядра моделирования, а конвертеры. Они закрывают требование 5 там, где ядро не справляется (DWG, JT, CATIA, NX), и имеют смысл как дополнение к выбранному ядру, если такие форматы понадобятся. Все три коммерческие. Для OCCT, который сам читает STEP и IGES, необходимости в них на текущем этапе нет.

---

Сводная таблица

Обозначения: ● полностью, ◐ частично, ○ нет.

Кандидат	1. Лёгкость	2. Rust	3. Редактирование	4. NURBS	5. Форматы	6. Лицензия и её риск
OCCT + opencascade-rs	○ 2,7 ГБ сборки, exe 19,4 МБ	◐ биндинги есть, но на Windows не собираются без патчей	● булевы, фаски, скругления	● полноценно, аналитика сохраняется	● STEP/IGES/STL/OBJ/glTF	LGPL-2.1+искл.: динамическая линковка — ок, статическая обязывает
truck	● 98 с сборки, exe 1,6 МБ	● родной, собрался с первой попытки	◐ булевы есть (в 4–6 раз медленнее), набор беднее	◐ есть, но аналитика уходит в B-сплайны	◐ STEP r/w, полигоны; IGES нет	Apache-2.0 — риска нет
Fornjot	—	●	○	○	○	архивирован
SolveSpace	●	○	◐	◐ слабые булевы	◐	GPL-3.0 — стоп для проприетарного
openNURBS	●	○	○	●	◐ только 3dm	своя, свободная
Manifold	●	● крейт manifold3d	◐ только сетки	○	◐	Apache-2.0 — риска нет
C3D Modeler	◐	○ писать самим	●	●	●	90 дней, дальше платно
Parasolid	◐	○	● эталон	●	●	платно, условий публично нет
ACIS / CGM	◐	○	●	●	●	платно, условий публично нет
Zoo Design API	● клиент лёгкий	● родной Rust	●	●	●	облако, поминутная оплата

---

Измерения

Всё в этом разделе измерено здесь, а не переписано из чужих статей.

truck

Зонд: два куба → булево объединение → тесселяция → экспорт OBJ и STEP. Написан по документации и скомпилировался с первой попытки без правок — показатель того, что API соответствует документации.

Что	Значение
холодная сборка release	98,6 с
пакетов в графе зависимостей	103
исходники самих крейтов truck	1,9 МБ, 233 файла, 10 крейтов
размер target/	446,8 МБ
исполняемый файл зонда	1,60 МБ
построение двух кубов	116 мкс
булево объединение (плоскости)	1,72 мс
тесселяция результата	340 мкс, 60 вершин / 36 граней
экспорт STEP	445 мкс, 17,6 КБ
экспорт OBJ	637 мкс, 8,8 КБ

Второй зонд — на кривых поверхностях: цилиндр (через вращательное заметание) против куба, пересечение и объединение.

Что	Значение
булево пересечение цилиндр ∩ куб	32,6 мс (в 19 раз дороже плоскостного)
булево объединение цилиндр ∪ куб	29,5 мс
результат тесселируется	да, 84 вершины

Третий зонд — чтение STEP обратно: файл, записанный первым зондом, разобран за 11,1 мс, из него восстановлены 1 оболочка, 12 граней и 18 плоскостей. То есть круг «записал — прочитал» у truck замкнут. Мелочь, характеризующая зрелость API: Table::from_step возвращает Option, а не Result, поэтому причина неудачного разбора вызывающему не сообщается вовсе.

Обе булевы операции отработали — это лучше, чем можно было ожидать от ядра такой зрелости. Но экспорт цилиндра в STEP показал существенное: файл содержит B_SPLINE_SURFACE и PLANE, и не содержит CYLINDRICAL_SURFACE. То есть аналитические поверхности truck не сохраняет, всё сводится к сплайнам. Файл валиден, но принимающая система получает вместо цилиндра сплайновую аппроксимацию: хуже для распознавания элементов, хуже для точности, тяжелее.

OCCT через opencascade-rs

Сборка этого пути оказалась мерой сама по себе — она упёрлась в три препятствия подряд, и каждое стоит знать заранее.

1. CMake 4.x против OCCT 7.8.1. occt-sys собирает OCCT 7.8.1, чей cmake_minimum_required объявляет совместимость ниже 3.5. В CMake 4.3.2 такая совместимость удалена, и конфигурация падает сразу: «Compatibility with CMake < 3.5 has been removed from CMake». Обходится переменной окружения CMAKE_POLICY_VERSION_MINIMUM=3.5. В OCCT 8.0.1 этой проблемы нет — но обвязка на него не переведена.
2. Генератор Visual Studio. Крейт cmake по умолчанию берёт генератор «Visual Studio 17 2022», который на этой машине не отработал: установлены и Build Tools 2026, и VS 2022 Community. Лечится CMAKE_GENERATOR=Ninja из среды vcvars64.bat.
3. Длина пути Windows. Дерево OCCT глубокое, и в каталоге с длинным путём сборка предупреждает про CMAKE_OBJECT_PATH_MAX (187 символов при пределе 250) и падает. Понадобился короткий путь вида C:\occprobe.

После того как все три обойдены, сборка идёт и само ядро OCCT собирается успешно. А потом падает компиляция cxx-мостов — тремя однотипными ошибками в собственных заголовках обвязки:

b_rep.hxx(16): error C2440: невозможно преобразовать
  "opencascade::handle<Geom_Surface> *" в "std::unique_ptr<Handle_Geom_Surface, ...>"

Что	Значение
время до провала	36 мин 09 с (01:59:43 → 02:35:52)
объём target/ к этому моменту	~1,0 ГБ
исходники OCCT (occt-sys 7.8.1)	87 МБ, 14 984 файла; скачиваемый архив 13,7 МБ
ошибок компиляции	3, все в b_rep.hxx
собралось ли ядро OCCT	да
собрались ли биндинги	нет

Причина — коллизия имён: обвязка объявляет собственные типы Handle_Geom_Surface и им подобные, которые под MSVC сталкиваются с одноимёнными типами самого OCCT. Это известная незакрытая проблема проекта, а не особенность этой машины: PR #196 «Handle name conflict to fix Windows build» был влит ещё в январе 2025, PR #230 «Fix MSVC handle name collisions» от 19 августа 2026 — закрыт, не влит, а PR #216 «Fix Windows build» открыт с октября 2025 и всё ещё не принят.

Проверка обхода: патч из непринятого PR #230 (переименование Handle_* → RustHandle_*, 26 файлов) применяется к текущему master чисто — git apply проходит без конфликтов. После него мосты компилируются, но сборка падает уже на линковке: 23 неразрешённых символа, среди них InitializeAcl и InitializeSecurityDescriptor, то есть не подключены системные библиотеки Windows. Это ровно предмет второго, до сих пор открытого PR #216 — и наложить его поверх первого не получается, два непринятых патча конфликтуют между собой в build.rs. Понадобилось дописать четыре строки вручную:

println!("cargo:rustc-link-lib=dylib=advapi32");
println!("cargo:rustc-link-lib=dylib=gdi32");
println!("cargo:rustc-link-lib=dylib=shell32");
println!("cargo:rustc-link-lib=dylib=comdlg32");

После этого всё собралось и заработало. Итого, чтобы получить рабочий OCCT-из-Rust на Windows, потребовались: три настройки окружения, один непринятый PR и четыре строки своей правки.

Что	Значение
холодная сборка до провала (без патчей)	36 мин 09 с
пересборка после патчей (ядро уже собрано)	1 мин 45 с
исходники OCCT (occt-sys 7.8.1)	87 МБ, 14 984 файла; архив 13,7 МБ
размер target/	~2,7 ГБ
исполняемый файл зонда	19,4 МБ (против 1,60 МБ у truck)

Работа зонда: куб 10×10×10 минус куб 6×6×6, фаска 0,5, тесселяция, три экспорта и чтение STEP обратно.

Операция	Время
два примитива	503 мкс
булево вычитание	7,46 мс
фаска по всем рёбрам	20,2 мс
тесселяция	12,1 мс, 174 вершины / 86 треугольников
экспорт STEP	25,4 мс, 110,8 КБ, 2378 сущностей
экспорт IGES	14,6 мс, 87,3 КБ
экспорт STL	15,2 мс, 22,4 КБ
чтение STEP обратно	48,4 мс, те же 174 вершины
всего	145 мс

Прямое сравнение на одной задаче

Чтобы сравнение было честным, обоим ядрам дана одна и та же работа: цилиндр радиуса 2 высоты 4, пересечение и объединение с кубом 1,5, затем запись цилиндра в STEP.

	truck	OCCT
цилиндр ∩ куб	32,6 мс	7,2 мс
цилиндр ∪ куб	29,5 мс	4,7 мс
тесселяция результата	84 вершины	38 вершин
STEP цилиндра, размер	13 281 байт	5 652 байта
боковая поверхность в STEP	9 × B_SPLINE_SURFACE	1 × CYLINDRICAL_SURFACE

Последняя строка — самая содержательная во всём документе. Там, где OCCT пишет одну аналитическую цилиндрическую поверхность, truck пишет девять сплайновых заплаток: файл вдвое толще, а принимающая система видит не цилиндр, а его аппроксимацию. Булевы операции при этом у OCCT в 4–6 раз быстрее.

Мелкая, но заметная деталь эксплуатации: OCCT при записи STEP печатает в stdout собственную статистику трансфера («Statistics on Transfer», рамки из звёздочек). В библиотеке, встраиваемой в приложение с интерфейсом, этот вывод придётся глушить.

---

Рекомендация

Основной вариант — Open CASCADE Technology, из Rust через opencascade-rs.

Причины, по порядку веса:

1. Это единственное открытое ядро, которое закрывает требования 3, 4 и 5 целиком. Всё остальное открытое либо не умеет моделировать (openNURBS, curvo, Manifold), либо умеет плохо и под GPL (SolveSpace), либо закрыто (Fornjot).
2. Требование 2 выполняется без написания биндингов. opencascade-rs даёт готовый Rust-API с булевыми, фасками, тесселяцией и обменом форматами.
3. Требование 5 закрывается из коробки: STEP AP242 и IGES на чтение и запись — это то, чем САПР обменивается с внешним миром, и ни truck, ни полигональные библиотеки этого в таком объёме не дают.
4. Зрелость: ядро развивается с 1990-х; на нём построены FreeCAD (его B-rep/NURBS слой — это OCCT), CadQuery и 3D-часть KiCad.

Цена решения, названная честно и измеренная: ядро тяжёлое (87 МБ исходников, 2,7 ГБ сборочного каталога, 19,4 МБ исполняемый файл против 1,6 МБ у truck), это C++ с версией 7.8.1 в текущей обвязке, а сама обвязка на Windows из коробки не собирается: понадобились три настройки окружения, патч из непринятого PR #230 и четыре строки правки build.rs. Плюс лицензия, обязывающая к динамической линковке при проприетарной поставке — а динамический путь требует системной OCCT ветки 7.x.

Это не аргумент против выбора, но это работа, которую придётся сделать до того, как будет написана первая строка САПР-логики, и её лучше запланировать явно. Разумный первый шаг после утверждения — форк opencascade-rs с наложенными исправлениями: иначе каждый разработчик проекта будет проходить этот путь заново, а обновление апстрима будет ломать сборку.

Запасной вариант — truck, и он не запасной «на всякий случай», а по конкретному сценарию: если проект останется целиком на Rust и согласится на собственную реализацию недостающего. truck легче, собирается за полторы минуты, не тянет C++ и не создаёт лицензионных обязанностей вовсе (Apache-2.0). Но за это придётся заплатить отсутствием IGES, потерей аналитических поверхностей при экспорте, более скудным набором операций и работой с крейтами двухлетней давности либо git-зависимостью.

Отдельно про требование 3. В задаче эталоном названа Plasticity — она построена на Parasolid, и это надо понимать буквально: уровня её прямого моделирования (push/pull по грани с мгновенной перестройкой тела) ни одно открытое ядро само по себе не даёт. OCCT предоставляет операции, из которых такой режим собирается, но собирать его придётся самим.

Про закрытые ядра. Ни одно из четырёх не даёт бесплатного пути в продукт: C3D — 90 дней, Parasolid и ACIS/CGM — только переговоры, Zoo — поминутная оплата и облако. Возвращаться к ним осмысленно тогда, когда у проекта появится бюджет и станет ясно, что именно в OCCT не устраивает: менять ядро на этапе прототипа дороже, чем позже, когда требования известны точно.

---

Что придётся писать самим поверх любого ядра

Это не недостаток конкретного кандидата, а общее свойство: ядро даёт геометрию, а не САПР.

• Решатель геометрических ограничений. Ни OCCT, ни truck его не содержат. Без него нет параметрического эскиза. Кандидаты: libslvs из SolveSpace (GPL-3.0 — то же лицензионное ограничение, что и у самого SolveSpace), либо собственная реализация.
• Дерево построения и история операций. Ядро выполняет операции, но не помнит, в каком порядке и от чего они зависели.
• Топологические имена. Устойчивая идентификация граней и рёбер между перестроениями — классическая трудная задача, ядром не решается.
• Связь с расчётной частью. Для CFD нужна сетка, а не B-rep: понадобится контролируемая тесселяция и, вероятно, воксельное или SDF-представление, согласованное с решателем KBC.

---

Что нужно от владельца проекта

1. Утвердить ядро — критерий готовности задачи #5 сформулирован именно так.
2. Решить вопрос линковки, если продукт будет проприетарным: удобный путь (builtin) даёт статическую сборку OCCT, а динамический требует предустановленной в системе OCCT ветки 7.8/7.9 — версию 8.x обвязка отвергает. Выбор: принять обязанности LGPL 2.1 §6, держать системную 7.x, либо править обвязку под себя.
3. Согласиться на форк opencascade-rs (или явно отказаться): без него сборка на Windows воспроизводится только вручную, по шагам из раздела измерений.
4. Если решено смотреть на закрытые ядра всерьёз — запросить условия у C3D Labs (90-дневная пробная плюс индивидуальные условия) и у Siemens по Parasolid. Регистрация и подписание — действия владельца, агентом они не выполняются.

---

Источники

• Open CASCADE Technology — обзор и форматы
• FOSDEM 2026: OCCT3D 8.0 — ломающие изменения и развитие ядра
• OCCT_LGPL_EXCEPTION.txt — текст исключения
• Релизы OCCT (8.0.1, 30.07.2026)
• opencascade-rs
• opencascade-rs PR #230 «Fix MSVC handle name collisions» — закрыт, не влит
• opencascade-rs PR #216 «Fix Windows build: …missing system libraries» — открыт
• truck — shape processing kernel by Rust
• Fornjot — архив, заявление о закрытии
• SolveSpace — использование как библиотеки
• openNURBS
• Manifold
• curvo
• C3D Toolkit — лицензирование
• C3D Toolkit — тестовая версия
• Zoo Design API
• Zoo — тарифы API
• kittycad.rs — Rust-клиент Zoo