САПР. Эпизод второй, несерьёзный
Когда попросил И.И.Гуглова создать скрипт CSG-анимации:
(Контентом нейросети является скрипт, приведший к такому удивительному результату :)))
(Контентом нейросети является скрипт, приведший к такому удивительному результату :)))
Идея неплохая. Я в начале года купил по приколу Bambu H2D, и немного поигрался с Fusion, напроектировав там всяких безделушек типа держателей лыжных палок.
Решил сейчас набросать нечто подобное в вашем каде. Первое, что бросилось в глаза:
* Глючит вращение мышкой. Если зажать правую кнопку, вращается как-то криво. Если просто щелкнуть - не работает. Получатся только нажать - повернуть криво - отпустить - повернуть нормально.
* Не работают snap points на всех уровнях зума. Я уменьшил масштаб и попытался создать простейшую фигуру - две параллельные горизонтальные прямые, концы которых соединены кривыми Безье. Без ювелирного прицеливания мышкой четко в конец прямой, кривая создавалась немного со смещением, и не стыковалась. С увеличенным масштабом работало лучше, но синяя подсветка на черном фоне - то еще удовольствие (или у меня проектор старый).
* Без таймлайна это вообще несерьезно. Оригинальный дизайн держателей в Fusion я делал чуть ли не в десяток итераций. Опа, прищелкнулось к полке, но палка цепляет снизу. Возвращаемся на 10 шагов назад, добавляем 5мм к extrude, fusion пересчитывает весь дизайн. Опа, крепеж оборвался. Сделаю-ка я его потолще на этапе, когда он один, а не 4 копии по углам. Здесь я такого не увидел. Если ваш движок такого не умеет изначально, добавлять это потом будет очень тяжело.
* Половина надписей на английском, половина на русском. Мы живем в век нейросетей. Оставьте в коде метки типа <span>$$TRANSLATE:Extrude</span>, потом одним промптом тот же клод, или кто там у вас за него, создаст/обновит список таких строк, и заменит на что-то типа <span id="translate"> и getElementById("translate").content = LoadResource("translate"). Если этот промпт рутинно запускать после каждой добавленной фичи, о переводах можно вообще не думать.
По мелочам:
* Нужен construction. Создание временных плоскостей со смещением/поворотом. Создание осей и т.п.
* Нужно редактирование размеров при создании скетчей. В fusion я начал рисовать линию, набрал на клавиатуре 10, и у меня зафиксировалась длина, позволив выбрать направление.
* Нужны вспомогательные фигуры на скетчах с редактируемыми размерами. Если мой скетч - круг, отделенный на 5мм от прямоугольной стенки, эти 5мм должны быть параметром, который можно поменять спустя 99 ревизий, и он пересчитает весь остальной дизайн.
Это с точки зрения пользователя. С точки зрения бизнеса - делать полноценный продукт вы будете долго, поэтому ищите первых платных пользователей. На веб многие серьезные пользователи будут плеваться. Дестктоп будут пиратить. Госы могут потребовать откат, потом сделать вас крайним. Может оказаться, что при всей крутости проекта продавать его просто некому. Но идея отличная. Сам думал что-то подобное на пенсии накалякать, благо с нейросетями этот процесс стал гораздо более творческим и менее рутинным, если уметь в архитектуру. Удачи!
Это результат экспорта 3D-данных для САПР из программы расчёта пассивного Wi-Fi-ретранслятора, созданной с помощью вайбкодинга. ИИ также предложил конструкцию антенн.
Пришлось немного "пободаться" с ним на предмет неточностей и ошибок в выходных файлах.
По моему опыту самодельный ретранслятор себя уже оправдал ранее (для 4G и на других антеннах, но не суть), так что тема проектирования таких устройств актуальна.
Теперь остаётся на досуге протестировать программу на реальных антеннах и кабелях.
И есть идеи развития ...
Приветствую сообщество! Почему-то в последние пару лет я упорно не замечал, что Autodesk ушел из России (шутка), но постоянно обновлял свой любимый Fusion 360 через боль и страдания. Параллельно со мной страдали некоторые мои товарищи, практически все мои обучающиеся, да и думаю много кто ещё. Дополнительной проблемой стал перевод пары учебных аудитории на Ubuntu, а Fusion 360 существует исключительно для Windows, и костыли через wine работают криво. Единственная бюджетная (бесплатная) альтернатива, это FreeCAD, но интерфейс у него не самый дружелюбный, особенно для школьников.
Идея появилась совершенно случайно, за разговором с коллегами. А почему бы не написать простенький 3D-редактор для моделирования под 3D-печать. С простым интерфейсом и работой прямо в браузере. Целился я в нечто среднее между Tinkercad и Fusion360. Так появился КонтрCAD.
Главная цель была в формировании правильной инженерной логики и понимания принципов работы операций в САПР.
Изначально планировалось, что дети впоследствии перешли бы на более продвинутый САПР (например, Компас). Но в итоге получилось, что можно работать в моём редакторе с начальных и до старших классов.
Вводные были следующие:
Простой интерфейс, интуитивно понятный (насколько это возможно) даже ребёнку.
Библиотека примитивов, чтобы младшим было полегче осваиваться.
Чертеж (желательно похожий на fusion) и базовые САПР-инструменты (выдавливание, вращение, выдавливание по траектории).
И все это максимально доступное, желательно вообще без установки.
А главное - работа на клиенте, дабы ограничить нагрузку на сеть и сервер (изначально у проекта сервера вообще не было).
Естественным выбором в этом случае стало js-приложение.
1. Простой редактор с кучей багов.
2. Переписывание всей логики на параметрическую, написано параметрическое ядро. Хранение проектов сделано в виде списка операций с параметрами (с возможностью удалить, редактировать, или добавить операцию).
3. Опять переписывание всего редактора полностью с целью перехода на ES6 модульную архитектуру.
4. Переписывание чертежа полностью для перехода на сущности (линия, окружность, дуга и т.д.), внедрения параметризации, системы ограничений и вариационного решателя.
5. Реализация серверной части (API и сайта). Предыдущие пункты были в том числе подготовительные, поэтому редактор был практически готов к этому.
На js не очень много библиотек для работы с графикой, наиболее популярная на данный момент three.js. Эта библиотека используется для всей визуализации, а также импорта и экспорта.
Сначала я пробовал работать с геометрией тоже через three.js, но у нее не самые надёжные алгоритмы, и реализация геометрических методов достаточно простая.
Поэтому я перешёл на manifold-3d. Эта супер-библиотека гарантирует манифолдный (водонепроницаемый) результат, имеет продвинутые геометрические функции и очень быстро работает. Это wasm сборка очень популярной библиотеки manifold, написанной на c++, благодаря этому она и намного быстрее. Она отвечает за бинарные операции, а также Extrude и Revolve. Многие другие алгоритмы пришлось реализовывать своими силами.
Ну про разработку я много где писал, про техническую часть выходят статьи на Хабре (сейчас немного его забросил, но новые статьи обязательно будут, и не одна).
Окно редактора на первый взгляд напоминает Tinkercad, но пусть вас это не вводит в заблуждение.
Сверху панель инструментов с расставленными по группам кнопками:
1. Файловые операции.
2. Назад/вперёд (операции истории).
3. Операции создания.
4. Операций модификации.
5. Инспектирование.
Справа расположено меню с 4 вкладками:
1. Библиотека.
2. Свойства.
3. Список объектов на сцене.
4. История.
Любую вкладку можно закрепить по умолчанию. Соответственно, если вам не нравится детский вид библиотеки, можно просто закрепить список объектов.
Общего гизмо для перемещения, поворота и масштабирования намеренно нет, как раз для формировании правильной инженерной логики. Чтобы обучающийся понимал, что для разных операций требуются разные инструменты.
Также в этих инструментах есть дополнительные настройки.
Но перемещать объекты можно и указателем, правда не все. Для перемещения доступны все 3D-объекты, кроме плоскостей (чертёж и рабочая плоскость). Это сделано для защиты от случайных перемещений.
Но если нужно, плоскости тоже можно переместить, достаточно включить инструмент "Перемещение".
Логику TinkerCAD с объектами-отверстиями я намеренно не стал делать. Во-первых, она мне просто не нравится, а во-вторых, я не люблю бездумно что-то копировать. На мой взгляд она в принципе нарушает логику построения модели через операции. Ни в одном взрослом САПР вы такого не найдете, и ребенку при переходе на них приходится менять логику мышления. А не лучше ли сразу учить правильно?
Поэтому бинарные операции как во взрослых САПР разделены.
А если надо как-то изменить операцию, с этим отлично справляется параметрическая история.
Как я уже сказал, проект - это просто список операций с параметрами, а при запуске проекта модель заново строится по этому списку. Можно без труда добавить или удалить операцию из любого места истории. Модель автоматически перестоится. Многие операции поддерживают редактирование параметров. Да можно даже открыть файл проекта в блокноте и отредактировать.
LLM с таким форматом тоже хорошо дружат, поэтому в будущем с высокой долей вероятности появится и генерирование деталей.
Дабы перемещение по истории не тормозило, в версии 0.9.63 я наконец добавил кэшировние операций.
Проекты можно сохранять в файлы, открывать из файла, импортировать из файла в текущий проект. Ограничений нет.
А также можно хранить проекты непосредственно в самом редакторе при помощи хранилища проектов.
Хранилище может хранить проекты локально на компьютере (в IndexsedDB) и в облаке.
Локально даже у неавторизованных пользователей есть возможность хранить до десяти проектов.
Для хранения в облаке требуется аккаунт и достаточный уровень доступа (к сожалению, на данный момент дать всем место для хранения я не могу себе позволить. Пока облако доступно лишь спонсорам).
Для импорта доступны stl и obj. Экспорт 3D-моделей доступен в кучу форматов.
Если бы не было чертежа, я бы не называл этот редактор САПРом :)
Чертеж появился в самой первой версии. Изначально чертеж был простой чертилкой, даже размеров не было. Главная проблема была в сущностях (точнее в их отсутствии ). Фигуры рисовались сразу готовые, а не из набора примитивов.
Постепенно я пришел к выводу, что в таком виде он не перспективен, и нужно все переделывать (хоть и не хотелось). На js я подходящей реализации чертежа не нашел (хотя и не то чтобы очень активно искал), поэтому решил написать геометрическое ядро, вариационный решатель и систему ограничений самостоятельно.
После этого чертеж стал параметрическим, при изменении какого-либо параметра (размера, угла и т.д.) пересчитывается и все остальное, как и в большинстве САПР. Большинство ограничений устанавливаются автоматически. Размерные ограничения ставятся аналогично Fusion 360 (при вводе значения во всплывающее поле).
Как раз после этого обновления я и начал называть свой редактор САПР, по моему мнению ранее он до такого звания не дотягивал, хотя был уже на несколько голов мощнее TinkerCAD.
В итоге получился вполне стандартный для САПР режим чертежа, даже наверное интуитивно понятнее и удобнее, чем у других.
Появилось большинство стандартных инструментов:
Множество фигур;
Линейный (скорее квадратный) и круговой массивы;
Отступ;
Ножницы;
Скругление;
И множество геометрических ограничений.
Если нужно, можно чертить и с 3D-видом. И даже с перспективной камерой.
Чертеж, какой бы он крутой не был, не имеет смысла без дальнейших операций. В КонтрCAD есть классические: выдавливание (Extrude), вращение (Revolve) и недавно появилось выдавливание по траектории (Sweep). Скоро появится Loft.
Все эти инструменты позволяют выбрать, какую область чертежа вы хотите использовать. При черчении эти области заливаются разными цветами, а при наведении указателем, со включенным инструментом, подсвечиваются.
Выдавливание позволят выдавить выделенные области чертежа в выбранном направлении (наружу, внутрь или в обе стороны). Можно применить сразу операцию объединения и вычитания. Также можно выдавливать грани объектов, тогда сразу включается операция "Объединение".
Помимо этого, выдавливание поддерживает скручивание и задание конусности.
Выдавливание по траектории позволяет тоже выдавить выделенные области чертежа, но уже не просто в какую-то сторону, а по заданной траектории. Траекторию нужно тоже нарисовать на чертеже.
Вращение поворачивает выделенные области чертежа вокруг заданной оси. В основном используется для создания круглых объектов.
У меня изначально была идея сделать не просто редактор, а полноценную облачную платформу с хранением проектов в облаке, работой в группах и прочими плюшками. Немного доработав чертеж, я перешел к этой задаче. Изначально запустил сервис КонтрCAD Cloude.
Но потом выкупил домен kontrcad.ru, и решил его уже переделать в полноценный сайт проекта.
Естественно, помимо описанного есть множество других инструментов. Есть 3D и 2D текст с загрузкой собственных шрифтов, загрузка изображений, генераторы шестерней и резьбы (генератор резьбы, на мой взгляд, вообще один из самых продвинутых, он её еще и нарезать умеет), 3D-текстурирование (про него была прошлая статья). Все в один пост не вместить.
Попробовать можно online, без регистрации и совершенно бесплатно: https://www.kontrcad.ru/
Новости об обновлениях в основном выходят в Telegram и ВК. Краткий список всех обновлений и планов на будущее есть в дорожной карте.
Поддержать разработку можно на boosty и ВК. Спонсоры проекта сейчас первыми получают ключ доступа к облачным функциям.
Буду благодарен за медийную поддержку, обратную связь, сообщения об ошибках и предложения по развитию :)
Доброго времени суток друзья. Вот уже пол года я веду разработку КонтрCAD - это браузерный 3D‑САПР (система автоматизированного проектирования) для моделирования, в первую очередь под 3D‑печать. Я его разработал как доступную альтернативу TinkerCAD и Fusion360 (целился я в нечто среднее). За это время добавлена куча крутых возможностей, и скоро об этом будет отдельный пост, а пока я решил рассказать об одном из последних обновлений:
После появления BumpMesh, минимум человек пять мне написали с просьбой добавить аналогичный инструмент в КонтрCAD. Я долго откладывал реализацию этого инструмента, так как были более приоритетные задачи. Но вот очередь дошла и до него!
Инструмент 3D-текстурирования поверхности позволяет изменить геометрию модели на основе текстуры для получения рельефной поверхности, что позволяет скрывать швы и слои. Можно наложить текстуру как на весь объект, так и по маске.
Лукавить не буду, принципы я подсмотрел у BumpMesh, но реализацию я написал собственную. Она немного проще, но почти такая же функциональная.
А учитывая, что этот инструмент интегрирован в САПР, возможности появляются впечатляющие.
Можно покрутить вживую: https://www.kontrcad.ru/public/project/proj_1784631797487_fc985847-960a-4eae-a29c-c5ebaf46e47c
1. Включаете инструмент.
2. Загружаете текстуру или выбираете встроенную. Можно регулировать масштаб, поворот и смещение текстуры. У встроенных текстур (они генерируемые) можно настроить разрешение и частоту повторов. Также можно настроить размытие текстуры.
Параметром "Сила" можно регулировать величину смещения вершин. Если задано 1мм, то вершины сместятся в указанную сторону на 1мм.
По умолчанию наложена трипланарная проекция текстуры на весь объект. Аналогично BumpMesh, помимо трипланарной есть ещё плоская (с выбором направления), сферическая и цилиндрическая проекции.
3. Если нужно накладывать не на весь объект, можно использовать маскирование. Маску можно наложить заливкой (с настройкой чувствительности) и кистью. Но кисть работает по исходной геометрии, если треугольников было не много, то работать будет не очень точно (лучше использовать заливку)
Не могу не упомянуть про минусы такой технологии текстурирования, они у всех инструментов 3D-текстурирования одинаковые.
Главный минус - это существенное усложнение геометрии. Без разбивки модели на кучу, нет, КУЧУ мелких треугольников, такое текстурирование не осуществить. Соответственно, на модели появляются тысячи, а то и миллионы треугольников. Модель становится существенно тяжелее (легко может дорасти до 100 и более Мб.), увеличивается и длительность операции с ней.
Поэтому я занялся этим инструментом только после внедрения кэширования в параметрическую модель. Иначе после пары операций текстурирования ждать отмены операций пришлось бы вечность. Но даже так первичное построение модели (при открытии проекта), или перестроение со сбросом кэша (при редактировании операции) занимает время.
В рамках САПР, в таком случае, я советую просто отделить от основной модели часть, на которую нужно наложить текстуру, а потом бинарной операцией присоединить обратно.
Основная фишка КонтрCAD - как раз нативная поддержка STL, соответственно, вы можете закинуть модель в редактор не только для текстурирования поверхности, но и для любой другой работы.
Попробовать можно online, без регистрации и совершенно бесплатно: https://www.kontrcad.ru/
Поддержать разработку можно на boosty и ВК. Спонсоры проекта сейчас первыми получают ключ доступа к облачным функциям.
Буду благодарен за медийную поддержку, обратную связь, сообщения об ошибках и предложения по развитию :)
Подскажите, пожалуйста, какие Вы читаете отраслевые журналы\интернет -порталы\форумы?
Обмен 3D-моделями между разными САПР почти всегда идёт через формат STEP. Геометрию он переносит отлично, а вот про структуру изделия не знает почти ничего.
Поэтому после импорта инженер открывает технически верную, но совершенно сырую сборку. Сотни компонентов со служебными именами вроде Solid1 и Part_42, ни обозначений, ни наименований, ни материалов, плюс дубли и разъехавшиеся разделы спецификации. Разгребать это вручную приходится часами, а на крупных узлах счёт идёт на дни, и к вечеру глаз замыливается так, что ошибки начинаешь делать сам.
Чтобы не заниматься этим руками, мы сделали утилиту, которая разбирает сборку сама.
Что умеет утилита
Утилита берёт сборку из STEP и приводит её к нужной структуре по таблице, которую инженер готовит заранее. Из таблицы она понимает, каким должен быть результат: обозначения, наименования, материалы, разделы спецификации, вложенность дерева.
Дальше она сопоставляет строки задания с реальными файлами, раскладывает детали и сборки по нужным папкам и проставляет свойства. Крепёж и повторяющиеся детали идут по отдельным правилам, иначе спецификация быстро разъезжается. После сохранения утилита заново связывает ссылки внутри сборки на новые файлы и собирает отчёты в двух видах: один для человека, второй для машины.
Сначала покажи, потом делай
Любая запись в реальные файлы необратима, поэтому сначала утилита всегда работает вхолостую, в режиме проверки (dry-run).
Она строит подробный план и показывает его отчётом, не трогая ни одного файла. Исходники в это время открыты только на чтение.
Оператор смотрит план и подтверждает его вручную. Только после этого запускается запись, причём ровно та, что была в плане. Результат пишется в отдельную папку, а от случайного второго запуска по той же папке стоит блокировка.
Как это выглядит на практике
1. Инженер кладёт рядом таблицу структуры и папку с импортом.
2. Запускает проверку. Утилита сканирует файлы, сопоставляет их с заданием и выдаёт план: какие детали уедут в какие папки и с какими обозначениями, какому крепежу проставиться единое обозначение, для какой строки задания файла не нашлось вовсе.
3. Инженер читает отчёт и убеждается, что всё размечено верно.
4. Запускает запись. Утилита сохраняет файлы, проставляет свойства и пересобирает корневую сборку так, чтобы она открывалась без окна «не удалось найти файл».
5. В конце отдельный проход перепроверяет результат и пишет итоговый отчёт.
Немного про устройство
Внутри это конвейер из независимых шагов: разбор таблицы, сканирование папки, связывание строк с файлами по набору правил, сборка плана. К самой сборке план применяется только в самом конце.
Логику разбора, сопоставления и планирования мы держим отдельно от САПР и покрываем тестами. Работа с КОМПАС вынесена в свой слой через COM/API, а самые тяжёлые по нагрузке операции отданы отдельному быстрому модулю.
Ограничения и открытые вопросы
Утилита заточена под согласованный формат таблицы, произвольные Excel она пока не понимает. Для реальной записи нужна Windows с установленным КОМПАС-3D и доступом к COM/API.
Часть операций API ведёт себя по-разному в зависимости от версии КОМПАС. Там, где операция не поддерживается, утилита честно пишет «пропущено» или «сделано частично», а не рисует зелёный статус поверх проблемы. Транзакционного отката после начала записи нет, и это ещё одна причина, по которой предварительный план так важен. Производительность упирается в размер сборки: самые дорогие шаги мы уже ускорили пакетной обработкой, но запас ещё остаётся.
Если проект кажется полезным, расскажите, чего вам не хватает в работе с КОМПАС и какую рутину хотелось бы свалить на программу. Идеи и пожелания пишите в комментариях или на почту: Vanamasorub@gmail.com
Попытки связать большие языковые модели с инженерным программным обеспечением обычно разбиваются о суровую реальность.
Системы уровня T-FLEX CAD работают через закрытые DLL-библиотеки, требуют жесткого контроля сессии и точного вызова методов API. В такой среде нейросети часто «галлюцинируют», выдавая код, который выглядит правдоподобно, но на практике приводит к падению процесса или зависанию лицензии. САПР не прощает ошибок в типах данных или абстрактных догадок.
Чтобы автоматизировать реальные конструкторские задачи и получать стабильный результат, нам пришлось отказаться от привычного формата чат-ботов. Мы разработали tflex_harness в котором агент состоит из языковой модели, из контура управления, локального поиска по API-документации, генерации C#-кода, компиляции и контролируемого запуска в T-FLEX CAD.
При интеграции с САПР часто возникает соблазн написать удобные обертки на Python (что-то вроде part.add_hole()). На практике это быстро заводит в тупик: при любом сбое нейросеть начинает пытаться исправить ошибки в самих обертках, полностью теряя из виду исходную инженерную задачу.
Мы пошли другим путем и разделили зоны ответственности. Python остался в контуре управления: он принимает задание, ищет сведения в локальной документации API, готовит рабочую папку и собирает результаты. Всё взаимодействие с ядром T-FLEX CAD выполняется через сгенерированный исходный C#-код, который компилируется вместе с вспомогательными классами и ссылками на библиотеки САПР. и жестко разделили логику. Python работает только в контуре управления, а взаимодействие с САПР происходит исключительно на чистом C#.
Python отвечает за маршрутизацию: принимает конфигурационные файлы, ищет информацию в локальной документации API и собирает результаты. А любые обращения к ядру T-FLEX происходят через генерацию открытого C#-кода, который компилируется с привязкой к нативным библиотекам САПР.
Языковые модели склонны выдумывать несуществующие методы. Модель может уверенно предложить условный вызов вроде ExportToStep(), даже если в текущей версии API такого метода нет или он называется иначе. Поэтому такой код нельзя сразу отправлять в сессию САПР: сначала его нужно проверить на уровне компиляции.
Поэтому мы добавили промежуточный этап, обязательную предварительную компиляцию.
Сначала система ищет точные названия методов в локальном справочнике API и формирует черновик программы. Затем сгенерированный код передается штатному компилятору csc.exe без запуска T-FLEX CAD. Этот этап отсекает значительную часть ошибок: несуществующие методы, несовпадение типов, неверные пространства имен и неправильные сигнатуры вызовов.
Как мы скормили API-справочник нейросети
Одной из главных проблем при работе с энтерпрайз-САПР является формат документации. Справочник API T-FLEX поставляется в виде классического скомпилированного файла .chm на 17 МБ и набора сырых .xml файлов с метаданными.
Закидывать мегабайты сырого XML в контекст современной языковой модели плохая идея. Модель съест огромное количество токенов, потеряет контекст (lost in the middle) и всё равно начнет выдумывать.
Мы пошли другим путем: написали парсер, который берет TFlexAPI.xml и разбивает его на тысячи атомарных Markdown-файлов (.md). Каждый такой файл описывает строго один класс, интерфейс или метод.
Как это работает в динамике:
Алгоритм осуществляет поиск по локальной базе .md файлов и находит только те классы, которые реально нужны для решения текущей задачи.
В контекст (промпт) нейросети отправляется не весь справочник, а только компактная и релевантная выжимка в понятном для ИИ формате Markdown.
Для реализации этого шага мы рекомендуем использовать deepwiki по нашему репозиторию t-flex_api (ссылка на него есть в конце статьи); Это дает наилучшие результаты при поиске связей между методами. Но в базовом варианте отлично работает и банальный текстовый поиск по .md файлам. Получая контекст в таком виде, модель перестает фантазировать и опирается только на жестко заданную спецификацию.
Писать с нуля шаблонный код для подключения к документу или настройки экспорта долго и неэффективно. Мы подготовили базовый набор вспомогательных классов на C#. Главное их отличие в том, что это не скрытые скомпилированные библиотеки. Это обычные текстовые файлы (например, EasySession.cs), которые копируются в рабочую папку и компилируются вместе с кодом, созданным алгоритмом.
Нейросеть видит эти файлы, использует их функции и самостоятельно пишет логику проверки своих же действий. Ниже показан фрагмент кода, который алгоритм создал для построения параметрического кронштейна.
var endSubtract = doc.EndChanges();
EasyDiagnostics.Print("subtract.endChanges", endSubtract);
if (endSubtract.ToString() != "OK") return 30; // Жесткий выход при ошибке построения
var box = EasyDiagnostics.PrintBodyBoxMm("final", finalBracket);
int operations = Document3D.GetOperations(doc).Count;
string outPath = sess.ArtifactPath("symmetric_clevis_bracket.grb");
bool saved = EasyExport.Grb(doc, outPath);
// Проверяем ключевые контрольные размеры модели
if (!box.Valid) return 40;
if (!Near(box.SpanX, 140.0, 0.5) || !Near(box.SpanY, 86.0, 0.5)) return 41;
if (operations < 16) return 42;
if (!saved || !File.Exists(outPath)) return 43;
return 0;
Алгоритм запрашивает у системы габаритный контейнер модели, замеряет размеры по осям, подсчитывает количество операций в дереве построений и только после прохождения этих контрольных проверок программа возвращает успешный код завершения.(проверки можно добавлять или изменять в любом виде)
Для каждой попытки создаётся отдельная директория, где сохраняются исходное задание, сгенерированный код, логи компиляции, консольный вывод, код завершения и готовые артефакты.
/artifacts/runs/20260529_120000_clevis_bracket/
├── request.json # Исходное техническое задание
├── snippet.cs # Сгенерированный алгоритмом код
├── helpers/ # Скопированные вспомогательные классы
├── build.log # Подтверждение успешной компиляции
├── stdout.txt # Консольный вывод и измерения
├── result.json # Код завершения
└── artifacts/
└── symmetric_clevis_bracket.grb # Готовая 3D-модель
Если сгенерированная программа успешно скомпилировалась, выполнилась в T-FLEX CAD и прошла встроенные проверки, её можно сохранить как проверенный «рецепт» переиспользуемый C#-сценарий для задач того же типа.
Проверенные рецепты переводят сценарий из режима эксперимента в режим пакетной обработки. На вход можно подать таблицу Excel или JSON с параметрами, а на выходе получить набор .grb/.step-файлов, сводный CSV-отчет или извлечённые атрибуты моделей.
Мы разработали этот подход для T-FLEX CAD, но сам принцип универсален. Искусственный интеллект пока не способен полностью заменить инженера-конструктора или разработать сложное изделие с нуля. И мы не пытаемся этого обещать.
Однако этот подход отлично работает для точечной автоматизации изолированных, рутинных участков. Массовое перестроение типовых моделей, выгрузка атрибутов и проверка спецификаций - это те процессы, на которые специалисты тратят десятки часов рабочего времени.
Для таких задач стандартные языковые модели в виде чат-ботов не подходят. Здесь требуется глубокая интеграция на уровне программного интерфейса и строгий контроль выполнения, применимый к любой корпоративной системе с открытым API (будь то T-FLEX, Компас-3D, SolidWorks или системы документооборота).
Репозитории:
t-flex harness: https://github.com/dwnmf/tflex_harness *любая обратная связь и PR приветствуются
t-flex api: https://github.com/dwnmf/tflex_api
Если у вас есть повторяемые инженерные или расчётные процессы, которые занимают слишком много ручного времени, напишите нам: vanamasorub@gmail.com.