О нейросетях и геометрии / forpes.ru

Главная
О нейросетях и геометрии

О нейросетях и геометрии -2

22.01.2025 09:15

vsradkevich 1 351 Источник

Часть 1. Введение: почему геометрия и нейросети — это не фантастика?

Вспомните, как мы в школе раз за разом рисовали треугольники, строили высоты, искали точки пересечения прямых и пытались доказать, что «углы равны». Тогда казалось, что геометрические задачи — дело либо для одарённых умов, либо для супертерпеливых людей с линейкой и транспортиром.

Однако в реальном инженерном мире всё намного круче: чертежи могут занимать десятки и сотни листов, 3D-модели деталей становятся гигантскими (например, целый корабль или авиалайнер), а специалисты вынуждены держать в голове гору информации о материалах, допусках, обработках.

В последние годы мы все наблюдаем, как большие языковые модели (привет, GPT!) и глубокое обучение в целом перевернули многие сферы — от распознавания котиков на картинках до написания осмысленных (и порой пугающе убедительных) текстов. Так вот, а как же чертежи и 3D-модели? Почему бы и туда не «запустить» нейросети — не только для визуализации, но и для понимания? Именно об этом наша статья.

1.1. Короткая история — от «линейки и циркуля» до CAD

Когда люди только начали что-то чертить (а это ещё в античные времена), они делали это для себя. На листе бумаги (или на папирусе, если мы уходим далеко вглубь веков) рисовали план дома, схему механизма, и лишь в общих чертах объясняли: «Вот тут поддержка, тут ось, тут шестерёнка». Формальных правил было мало, каждая мастерская изобретала свои условные обозначения.

Появление стандартов и взрыв машин

Промышленная революция всё изменила: паровые машины, заводы, механизмы. Потребовались единые стандарты (например, ЕСКД, ANSI, ISO), которые точно описывают, как обозначать размеры, допуски, виды, разрезы. Это сильно облегчило жизнь инженеров: любой человек, зная условности, мог открыть чертёж и понять, что за деталь там нарисована, какой у неё диаметр, как она крепится к другой детали и т.д.

Ну а потом «в бой» пошли компьютеры. Появился AutoCAD (в 80-х), далее SolidWorks, CATIA, NX… так мы пришли в эру CAD-систем. Они не просто хранят картинку, но и могут отчасти понимать, что это модель с конкретными геометрическими элементами (линии, кривые, поверхности). Появились форматы, например:

DXF, DWG — для 2D-чертежей,
STEP, IGES, STL — для 3D-моделей,
IFC (в строительстве, BIM-модели).

Но даже тогда, в классических CAD, компьютер больше выступал как умный «инструмент», а не как «мыслящий помощник». Основную логику — почему модель так устроена, как выбрать толщину стенки, где именно сделать отверстие — всё это решал инженер, а не машина.

1.2. Зачем нужна «умная» обработка чертежей?

Попробуйте представить ситуацию. Есть большая компания, которая делает насосы или редукторы. У неё накопилось тысячи чертежей и 3D-моделей, часть с 1970-х (оцифрованные из бумажных архивов), часть свежая. Нередко случается: «Нам нужна деталь вот такого типа, где-то она уже проектировалась, но, увы, не помним под каким именем и где она лежит». Инженеры часами копаются в папках, открывают модели в CAD, пытаясь узнать, похоже ли это то самое, что нам нужно.

А если бы у нас был «поисковик», который умеет «читать» все эти 3D-модели и подсказывать: «Вот, смотри, почти идентичная деталь лежит в каталоге «Редуктор-старый», причём она весит 2,5 кг, а твоя чуть тяжелее». Или представляете, как круто было бы в одном «чат-окне» спросить: «Какие детали из этого набора были изготовлены из стали 40Х, и есть ли среди них те, что ломались при вибрации?» — и получить разумный ответ.

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

Нейросети везде, почему бы не в инженерии?

Мы видели, как нейросети уже пришли в распознавание лиц, машинный перевод, создание картинок по запросу («нарисуй кота в шляпе»). Почему бы не «прокачать» нейросети до уровня, когда они смотрят на 3D-данные (или на сериализованный чертёж) и отвечают, скажем, «Это корпус подшипника», «Диаметр отверстия 15 мм, и оно может быть маловато под заданную нагрузку»?

1.3. «Но можно ли просто смотреть на изображение чертежа?»

Одна из первых мыслей: «Ну берём же мы картинки котиков, и CNN их распознаёт. Значит, возьмём скан чертежа, обучим «нейронку» — пусть находит все линии, размеры…» И это работает для некоторых задач. Но в инженерии часто хочется сохранить точность: когда мы имеем файл DXF или STEP, там чётко прописаны координаты, радиусы, углы. При переходе к растровому изображению много теряется, и приходится «угадывать» геометрию обратно из пикселей.

Поэтому появляются идеи: «А давайте мы конвертируем структурные форматы (DXF, STEP, IFC) в более удобное представление, например JSON или XML, где всё ровно описано, и подадим это в трансформер?»

Да, GPT умеет потреблять текст (а JSON — это вид текста).
Если в этом JSON есть, скажем, "line": {"start": [0,0], "end": [10,0]}, модель будет знать, что у линии начальная точка (0,0), конечная (10,0).

По аналогии с человеком, который читает: «Отрезок AB длиной 10 мм», нейросеть тоже может «читать» эти записи. Правда, в её случае это будут «токены» в потоке, на основе которых строится вероятностная модель. Но всё же это проще, чем выдирать эти данные из пикселей.

1.4. Мощь трансформеров — и их пределы

Что хорошего в трансформерах?

Главная «фишка» современных больших языковых моделей (вроде GPT) — самовнимание (self-attention). Модель на каждом шаге может «посмотреть» на разные части входного текста и найти, что связано с чем. Это очень помогло в NLP: чтобы понять смысл предложения, нужно учитывать контекст.

Тут же, если мы подаём описание геометрии в виде последовательности («Vertex A: (0,0,0)», «Vertex B: (0,10,0)»…), модель может научиться «видеть» паттерны: если в датасете часто встречались детали с координатами XYZ примерно такой формы, то эта, вероятно, тоже «такая же» (классификация). Либо если у нас есть куча примеров с описанием, к чему приводила такая геометрия (усталостный излом, перегрев и т.д.), она может «угадывать» риск.

Но формальная логика?

Всякие школьные построения (высоты, медианы, теоремы) — это символическая область. Там требуется жёсткое определение: «перпендикуляр — это…», «параллельные прямые — …». Трансформеры — штука скорее статистическая: они выводят наиболее вероятный паттерн. Да, на большом корпусе примеров они могут иногда довольно точно воспроизводить шаги построений, но это не гарантированно будет идеально (любая нейросеть склонна к «галлюцинациям» и ошибкам, если контекст ей неизвестен).

Поэтому, когда речь о «доказательствах» и «жёсткой уверенности», лучше или делать гибрид (LLM + символическая система), или полагаться на классические CAD/CAE-алгоритмы, где всё жёстко вычисляется. Но в задачах «предварительной оценки», «классификации», «поиска сходства» нейросети могут дать колоссальное ускорение.

1.5. «А точно это нужно?» — и реальные выгоды

Мы уже упоминали поисковые задачи, аудит. Добавим ещё пару примеров, чтобы вдохновить вас:

Автоматическая генерация вариаций.
Представьте, что нейросеть может создавать несколько «вероятных» форм детали, удовлетворя заданным ограничениям (например, задана координата крепления, материал, примерная масса). Потом инженер выбирает самый удачный. Это экономит время на ручном переборе.
Упрощение рутинных операций.
Нерегулярно, но довольно часто в компаниях есть «новички», которые тратят уйму времени, пытаясь понять, что означает какая-то часть сборки. Нейросеть, обученная на документации + 3D, может быстро подсказывать: «Это типовой фланец под насос», «Это болтовое соединение М10», и т.д. То есть выступать «справочником с интеллектом».
Снижение «человеческого фактора».
Чертёж — вещь, написанная для человека, и там можно ошибиться: неправильно проставить размер, забыть указать толщину, перепутать миллиметры и дюймы. Нейросеть, обученная на тысячах подобных косяков, может предупредить: «Слушай, у тебя разные единицы измерения на одном листе. Уверен, что так и надо?»

1.6. Пара слов о форматах и данных

Прежде чем мы двинемся к обзору технических деталей (это будет в следующих частях), давайте хотя бы коротко вспомним, что у нас есть целое море форматов, созданных в инженерии. Пара примеров:

DXF (Drawing Exchange Format): векторный формат для 2D-чертежей. Там много объектов (линии, дуги, сплайны), все в координатах.
STEP (ISO 10303): стандартизованный обменник 3D-геометрией. Может содержать и топологию, и материалы, и сборки.
IFC (в строительстве): описывает стены, перекрытия, арматуру, иерархию здания.
STL: чаще в 3D-печати, описывает поверхность меша как треугольники.

Все они уже частично текстовые (например, STEP и IFC) или имеют текстовые секции. Т.е. потенциально можно «распарсить» их в JSON, а дальше «скармливать» в нейросеть. Единственное, объёмы бывают огромные (десятки тысяч строк), и надо аккуратно подходить к тому, как мы это будем «разбивать».

1.7. Текущее состояние: мы на пороге больших открытий

Сегодня, если говорить честно, «зрелых» универсальных моделей, которые с ходу понимают чертежи «как ChatGPT понимает язык», почти нет. Но исследования:

Point Transformer (и другие 3D-модели) — показывают, что attention неплохо справляется с облаками точек.
Graph Neural Networks уже давно в обиходе. Если представить каждую деталь как узел, а связи как рёбра, мы можем анализировать структуру сборки, находить важные узлы.
Мультимодальные LLM, где помимо текста есть и другие виды данных, уже в стадии экспериментов. Вероятно, в будущем появится что-то вроде «GPT-CAD», понимающего и геометрию, и аннотации.

У крупных вендоров (Autodesk, Siemens, Dassault) есть свои R&D, и, скорее всего, в течение ближайших лет мы увидим продукты, которые умеют «читать» большой набор CAD-файлов и давать осмысленные рекомендации. Но пока всё движется медленно (индустрия консервативна), и мы находимся как бы на старте этой новой волны.

1.8. О чём пойдёт речь в следующих частях

Чтобы нашу статью было удобно читать, мы решили разбить её на несколько больших блоков (при этом это одна цельная статья, просто очень большая). Далее мы:

Глубже погрузимся в то, как именно переводить чертёж или 3D-модель в текст/структуру. Поговорим о 2D (DXF) против 3D (STEP, STL), посмотрим, почему иногда лучше «топологический» граф, а не просто список координат.
Разберёмся с архитектурами: Vision Transformer для картинок, Point Transformer для точек, Graph Transformer для сборок, мультимодальные связки. Кратко расскажем, какие задачи каждая из них решает и как.
Поделимся практическими примерами (пусть даже простыми): как взять STL, выдернуть из него облако точек, засунуть в PyTorch Geometric или другую библиотеку. Как обучить базовую модель, которая отличает «шестерёнку» от «вала».
Поговорим о лимитациях: нейросети не умеют строго доказывать геометрические свойства. Если нам нужна точность для сертификации (авиация, атомная энергетика) — как делать гибрид «ML + проверка уравнений»?
Завершим обсуждением «куда идём дальше». Возможны ли универсальные «инженерные ассистенты», которые и моделируют, и анализируют, и обучаются у людей?

Наша цель — дать обзор, не убивая читателя стеной формул, но и не опуская все сложности. Если вы — студент, аспирант или просто любопытный человек, надеемся, это поможет вам взглянуть на чертежи под новым углом. Если вы — инженер со стажем, будет интересно узнать, что «машины уже учатся понимать» и могут в чём-то помочь.

Теперь пришло время углубиться в детали: как именно подать геометрические данные в нейросеть, что такое STEP или DXF, почему иногда лучше «граф» вместо «просто списка координат», и какими путями можно связать это всё с моделями типа GPT или Point Transformer. Постараемся сохранить наш «живой» стиль, но при этом дать достаточно материала для размышлений.

Часть 2. Представление данных: как «скормить» нейросети нашу геометрию?

2.1. Откуда берётся «текстовое» описание чертежа?

В первой части мы уже говорили, что «трансформеры любят текст», а чертёж (или 3D-модель) — это, по сути, набор геометрических данных. Возникает главный вопрос: «Как сделать, чтобы наша геометрия была представлена в виде (условно) текста?» Ведь если подать картинку чертежа — это всё-таки чистое «изображение». Можно, конечно, использовать компьютерное зрение, распознавать линии, и потом пытаться их интерпретировать. Но, как мы отметили, это теряет точность, а иногда и логику.

Но на счастье, в инженерном мире уже существуют форматы, которые частично или полностью являются «текстовыми» (ASCII). Причём не обязательно на «русском» или «английском» языке — это могут быть структурированные файлы с ключевыми словами и наборами цифр.

DXF (Drawing eXchange Format) — внутри, если открыть его в текстовом редакторе, вы увидите группы кодов и чисел, которые описывают линии, дуги, слои.
STEP (ISO 10303) — чаще предназначен для 3D; в текстовом виде там прописаны объекты (B_SPLINE_CURVE, ADVANCED_FACE, и прочие «магические» штуки).

Пример (упрощённый) «STEP»-подобной записи

#20 = CARTESIAN_POINT('Point A',(0.0, 0.0, 0.0));
#21 = CARTESIAN_POINT('Point B',(10.0, 0.0, 0.0));
#22 = LINE('',#20,#21);
...

Тут видно, что описание включает некие объекты (CARTESIAN_POINT, LINE) и их параметры. Конечно, настоящий STEP-файл будет гораздо длиннее и сложнее. Но важно: это уже «текст», а значит, можно (в теории) «скормить» его большому языковому модели (LLM). Правда, он будет далеко не таким читабельным, как обычная JSON-разметка, но при желании можно распарсить STEP в более удобную форму.

2.2. Переходим от «сырого» формата к удобному сериализованному виду

Возможно, вы скажете: «Зачем париться, давайте прямо STEP-файл засунем в GPT!» В принципе, никто не запрещает. Однако такие файлы бывают оооочень большими и содержат массу избыточных вещей (типа #1000 = STYLED_ITEM(...), какие-то ссылки на сглаживание поверхностей, и т.д.). Модель может «утонуть» в этом хаотичном потоке. Поэтому часто делают промежуточный парсинг: пишут скрипт, который «вытаскивает» из STEP (или DXF) только ключевые данные:

Список основных геометрических объектов (точки, линии, плоскости, поверхности)
Параметры (длина, радиус, материал, толщина)
Иерархию (у сборки есть подузлы, у подузлов — детали…)
Может быть, связи (узел А соединён болтами с узлом Б).

После такого парсинга получается более компактный JSON, YAML или XML, который уже напоминает «упрощённую геометрию», и с ним легче работать. Пример (очень абстрактный, но для иллюстрации):

{
  "assembly_name": "SimpleBoxMechanism",
  "components": [
    {
      "id": 1,
      "type": "plate",
      "material": "steel",
      "geometry": {
        "length": 100.0,
        "width": 50.0,
        "thickness": 5.0
      }
    },
    {
      "id": 2,
      "type": "cylinder",
      "radius": 10.0,
      "height": 50.0
    }
  ],
  "connections": [
    {"source": 1, "target": 2, "type": "bolt", "count": 4}
  ]
}

Пусть это будет упрощённая модель: «Пластина (сталь) + цилиндр, крепящийся болтами». GPT уже может «прочесть» это как текст и, при наличии достаточного числа подобных примеров, научиться понимать логику сборки. Разумеется, всё зависит от количества данных и того, на каких задачах мы будем обучать (или дообучать) эту модель.

2.3. Когда геометрия становится «графом»

Допустим, у нас есть не просто деталь, а сложная сборка: десятки (а то и сотни) частей, каждая имеет свои свойства (размер, материал, метод обработки). Некоторые детали соединяются сваркой, другие — болтами, третьи вообще «вставлены» одна в другую. Традиционно, в CAD это всё описывается в иерархических деревьях сборок, где на верхнем уровне — узлы, внутри — подузлы, и так далее.

Иногда такое описание удобнее представить в виде графа:

Вершины: детали (или узлы),
Рёбра: типы соединений (болт, сварка, «вставка», контактная сварка),
Атрибуты вершин: материал, масса, геометрические размеры,
Атрибуты рёбер: тип крепления, прочность и т.д.

Почему это может помочь? Потому что уже существует целый класс Graph Neural Networks (GNN) и Graph Transformers (модификации механизма attention для графовых структур). С их помощью можно решать задачи вроде:

«Найди узлы, которые чаще всего выходят из строя» (типа центральные в смысле нагрузки).
«Разбей граф сборки на модули, чтобы упростить компоновку».
«Посоветуй оптимальные соединения, опираясь на статистику проектов с похожей топологией» (в обучающем датасете).

Конечно, это уже менее про «прямую геометрию» (где точки и координаты), а больше про высокоуровневую структуру. Но зачастую именно она и важна в инженерном проекте.

Пример «графового» описания в JSON

{
  "assembly": "Gearbox_v2",
  "nodes": [
    {"id": "Gear1", "type": "gear", "material": "steel"},
    {"id": "Gear2", "type": "gear", "material": "steel"},
    {"id": "Shaft", "type": "shaft", "material": "alloy"},
    {"id": "Housing", "type": "housing", "material": "aluminum"}
  ],
  "edges": [
    {"source": "Gear1", "target": "Shaft", "connection": "press-fit"},
    {"source": "Gear2", "target": "Shaft", "connection": "press-fit"},
    {"source": "Shaft", "target": "Housing", "connection": "bearing"},
    {"source": "Housing", "target": "Gear1", "connection": "enclosure"}
  ]
}

Это уже можно счесть графом (вершины — детали, рёбра — соединения). Нейросеть, которая умеет работать с таким представлением, может «видеть» связность, какие элементы являются ключевыми, какие материалы, и накапливать знания о том, как обычно устроены коробки передач.

2.4. А что, если у нас нет никакого STEP, а только STL (меш)?

Да, бывает и так: у нас «голый» STL-файл, который описывает модель как треугольную сетку (меш). Например, при 3D-печати. Там всё: вершины и треугольники (фейсы), без особой семантики (не написано «эта грань — цилиндр», «это — торец вала»).

В такой ситуации иногда идут путём Point Cloud: берут меш, «семплируют» его точки на поверхности (или преобразуют в облако точек), и кормят эти точки в модели вроде PointNet, Point Transformer или их новых аналогов. Там тоже используется механизм внимания, но уже по «точкам» (x, y, z). Это позволяет сети учиться распознавать форму.

Но минус: никакой «инженерной» инфы (про материалы, допуски) вы в STL не найдёте. Это чистая геометрия. Если цель — «распознать общую форму», то ок. Если хочется «узнать толщину стенки», придётся дополнительно вычислять это из меша или брать из других источников.

Да и к тому же STL-модель может быть гигантской (сотни тысяч или миллионы треугольников), а нейросетям тяжело переварить такой объём точек. Приходится «прореживать» (downsample) облако, теряя мелкие детали.

2.5. А если всё-таки хотим «прямое» изображение чертежа?

Иногда (особенно с старыми сканами) нет возможности достать «векторный» формат, и приходится работать с тем, что есть — растровым чертежом. Тут уже Vision Transformer (ViT) или обычные CNN могут решать задачу распознавания объектов (линий, окружностей, текстовых полей). Это что-то вроде OCR для чертежа, но сложнее: надо не просто распознать текст, но и «поймать» геометрические примитивы.

На практике:

Одни команды берут гибридный подход: сначала классический алгоритм (подобие Canny, Hough) «вытягивает» линии и окружности, потом CNN их классифицирует, а затем сборка логики (например, на Python) пытается понимать, какие элементы относятся к одному узлу.
Другие (более смелые) пытаются обучить end-to-end модель: на вход картинка, на выход список объектов (линия, дуга, текст, позиция). Но требует много размеченных данных.

Это полезно для перевода старых бумажных архивов в электронный вид, но проще и надёжнее (если есть возможность) достать «исходник» в DXF или другом векторном формате.

2.6. Итого: варианты представления чертежей и 3D-моделей

Суммируем основные пути, как можно «скормить» геометрию нейросети:

Текстовая сериализация (JSON / YAML / STEP / IFC / и пр.)
- Модель видит «последовательность токенов» и обучается находить связи.
- Может содержать как геометрию (координаты), так и семантику (материалы, назначения).
- Минус: может быть очень много строк, нужна стратегия разбиения, чтобы поместилось в контекст.
Граф (детали = узлы, связи = рёбра)
- Удобно для анализов сборок, когда важна топология (кто к чему крепится).
- Для глубокой геометрии (изгибы и точные формы) придётся отдельными атрибутами кодировать 3D-свойства.
- Можно использовать Graph Neural Networks / Graph Transformer.
Облако точек / меш (Point Transformer, GNN на мешах)
- Подходит, если главная задача — распознать форму, классифицировать её и т.п.
- Даёт «сырой» 3D, но без семантики (если меш не аннотирован).
- Нужно внимательно следить за размером, пробовать sampling.
Растровое изображение (ViT, CNN)
- Если имеем только скан чертежа.
- Теряем точность (надо извлекать координаты, размеры).
- Может работать при хорошем качестве рисунка.

Часто в реальном проекте используется комбинация: мы берём «векторные» данные (DXF, STEP) для точной геометрии и «сопроводительные» растровые изображения (например, если нужно распознать рукописные примечания на скане).

2.7. Как учить модель? Нужны ли «меченые» датасеты?

Любые нейросети требуют данных. Если ваша цель — делать «классификацию деталей», вам нужен набор чётко размеченных примеров: вот файлы, это «фланцы», это «валы», это «корпуса насосов» и т.д. Плюс-минус как в ImageNet, только для CAD.

Для 3D есть несколько публичных датасетов (мы вскользь упоминали в части 1):

ShapeNet (очень популярный, правда, там в основном «предметы быта», кресла, столы, и т.п.).
ModelNet (тоже набор 3D-объектов).
ABC Dataset (содержит много CAD-моделей с NURBS).

Однако для реальных промышленных деталей (какой-нибудь «редуктор-324_v2_final.step») таких общедоступных больших наборов мало, они часто закрыты. Поэтому компании либо собирают собственные датасеты (внутренние архивы), либо ищут какие-то партнёрские соглашения.

Самое сложное — размечать

Если хотим, чтобы нейросеть отвечала: «Это шестерёнка, у неё 20 зубьев, диаметр 50 мм», надо иметь примеры, где всё это указано как «ground truth». В противном случае модель может «научиться» лишь распознавать какие-то общие признаки, но не давать точных характеристик. Разметка — дело дорогое и муторное. Иногда пытаются генерировать синтетические примеры: например, случайные шестерёнки разного диаметра, выкидывают их в CAD-формат и автоматически подписывают метаданные. Но генератор должен быть достаточно реалистичным, чтобы модель реально училась.

2.8. Пример: «Небольшой пайплайн» — от STEP к JSON для GPT

Чтобы чуть конкретизировать, вообразим сценарий:

У вас есть папка с 500 STEP-файлами (3D-модели простых деталей).
Вы пишете скрипт на Python, который с помощью библиотеки (например, pythonocc или openCascade) открывает каждый STEP.
Оттуда извлекаете:
- Какое количество поверхностей (faces)?
- Примерные габариты (Bounding Box: x_min, x_max, и т.д.)
- Информацию о материалах, если она есть.
- Какие-то общие признаки (выпуклость, наличие отверстий, да хотя бы число граней!).

Всё это упаковываете в JSON (или XML):

{
  "file_name": "part007.step",
  "bounding_box": [0, 0, 0, 100, 50, 50],
  "num_faces": 12,
  "material": "Steel",
  "holes_count": 2
}

В итоге у вас получается 500 JSON-файлов с такими описаниями.
Теперь вы можете либо обучить «свою» модель (например, LLM с открытой архитектурой) или «подсунуть» эти файлы ChatGPT (с определёнными костылями, вроде chunk-инг), спрашивая: «Уважаемая модель, какие детали относятся к категории «заготовка-болванка»?»

Конечно, это всё очень упрощённый пример, но он показывает сам процесс: «распаковать» сложный геометрический файл —> «превратить в» более компактное описание —> передать в нейросеть, которая умеет обрабатывать текст или структуры.

2.9. «Скучно, хочу экшена!» — а как быть с реальной сложной моделью?

Если у вас реальная сборка на тысячи деталей, то прямое текстовое описание может превратиться в гигантский файл. Никакой GPT-4 не съест за раз 300 тысяч строк JSON — банально не влезет в контекст. Приходится:

Кусочно обрабатывать модель (например, делить сборку на подсборки).
Использовать механизмы «external knowledge» (вроде вложенного хранилища), а модель только «спрашивает» нужные блоки.
Или учить специализированные «Multimodal Transformers», которые могут пошагово читать данные, не пытаясь съесть всё сразу.

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

2.10. Практические сложности и «грабли»

Разнородность форматов: в одной компании могут быть и STEP, и IGES, и STL, и куча старых DWG. Каждый формат нужно по-своему парсить.
Недостаток метаданных: бывает, что в файле не указан материал или толщина, и мы получаем пустые поля. Модели не любят «пустоту», хотя можно указывать null.
Нет гарантии, что всё будет «чисто»: инженер мог проектировать деталь с ошибками (геометрические «дыры», некорректные поверхности), формат может быть кривым. Нейросети тоже «спотыкаются», если данные ужасные.
Конфиденциальность: реальные CAD-проекты — часто коммерческая тайна. Не всегда можно кормить их публичным моделям типа ChatGPT. Приходится внедрять он-премьер (on-premise) решения, поднимать свой сервер.

2.11. Маленький экскурс: IFC в строительстве

Чтобы не ограничиваться только машиностроением, добавим штрих про BIM (Building Information Modeling). Там есть формат IFC (Industry Foundation Classes), который описывает здание: где стены, окна, перекрытия, этажи, лестницы и проч. IFC — это тоже довольно текстовый формат (в основе EXPRESS-схемы). Его можно парсить и получать структуру здания (граф комнат и их свойств).

Если обучить GNN или Transformer работать с данными IFC, модель может:

Распознавать типовые конструкции (какой-то стандартный лестничный пролет).
Автоматически проверять, не забыли ли предусмотренные нормы для пожарных выходов.
Подсказывать дизайнерские ошибки («Слушайте, у вас окно внутри несущей стены, так нельзя!»).

Эти подходы очень напоминают те, что мы описываем для машинных деталей: всё сводится к тому, что есть сложная структура, и мы её описываем в более-менее дружелюбном формате, после чего запускаем трансформер или GNN.

2.12. Итоговая выжимка

Итак, во второй части мы сделали акцент на представлении данных:

Сырой формат (DXF, STEP, IFC) уже может быть текстовым, но часто очень громоздкий.
Парсинг: обычно мы делаем промежуточный слой, «выгружая» из CAD-файла геометрию и семантику в более удобный JSON/граф/облако точек.
Граф-ориентированное описание особенно хорош для сборок, когда важно понять, как узлы соединены между собой, какие материалы и т.д.
Меш / облако точек даёт чистую форму, но мало «инжиниринга». Можно использовать Point Transformer или аналог.
Растровое изображение — это вынужденный путь, если другого нет, но обычно теряем точность.
Выбор зависит от задачи: если хотим «читать» логику сборки, лучше граф/JSON. Если хотим «распознать форму», облако точек или ViT на проекциях. Если у нас старый бумажный чертёж — визионные методы или OCR.

Мы также упомянули, что для обучения нейросети (под конкретную задачу) требуются данные (примеры с метками), и часто это самая трудная часть: где их взять, как размечать, как не утонуть в разнообразии форматов.

2.13. Что дальше?

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

Vision Transformer (ViT) для изображений (даже 2D-чертежей),
Point Transformer (или близкие модели) для облаков точек,
Graph Transformer для сборок и топологических связей,
Мультимодальные штуки (текст + геометрия), где в одном пайплайне объединяется описание: «здесь сталь, там алюминий», и сама 3D-форма.

А ещё затронем тему, как люди пытаются «смешивать» классические CAE-расчёты с нейросетями: например, дать сети догадаться, где могут быть напряжения, а потом проверить это классической методикой конечных элементов (FEM). Или наоборот — прогонять FEM «спаренно» с ML-моделью, чтобы ускорить расчёт.

Если у вас уже возникает желание попробовать что-то подобное — не пугайтесь! Наша цель как раз в том, чтобы показать: хотя это и «неоднозначная» сфера (много нюансов, нет готовых универсальных решений), всё-таки реально построить пайплайн, где CAD-данные уходят в нейросеть и возвращают осмысленные результаты.

Спасибо, что дочитали вторую часть! Если есть вопросы или вам интересно, какой софт лучше использовать (OpenCascade, PythonOCC, PyTorch Geometric), — пишите, мы постараемся вставить больше подробностей в дальнейшем тексте. И да, если у вас есть свой опыт «парсинга» STEP или IFC, делитесь — всё это ещё молодая область, где каждый кейс может принести новые инсайты.

Далее часть 3, где, обещаем, наконец сделаем обзор трансформеров и других архитектур с конкретными примерами!

Теперь пришло время рассказать о самих трансформерных архитектурах (и не только о трансформерах), которые можно применить к инженерным задачам: Vision Transformer для 2D, Point/3D Transformers для объёмных данных, Graph Transformer для сборок, и мультимодальные варианты. Сохраняем наш лёгкий, дружеский стиль, но не забываем про суть!

Часть 3. Обзор архитектур: как «учить» нейросети понимать геометрию?

3.1. Идея базовая: трансформер vs «классические» CNN и MLP

Когда мы говорим о нейросетевых моделях для анализа данных, обычно вспоминают CNN (свёрточные сети) или MLP (обычная многослойная сеть). Но в последние годы именно трансформеры (со своим механизмом self-attention) захватили внимание исследователей. Почему?

Универсальность: их можно приспособить и к тексту, и к картинкам, и к аудио, и даже к облакам точек.
Масштабируемость: большие модели (десятки миллиардов параметров) уже стали «стандартом» в NLP, и похожие идеи применяют к Vision Transformer.
Гибкость: self-attention не завязан на фиксированное окно (как свёртки), а может «смотреть» на любые части входных данных. Правда, растёт вычислительная сложность, но железо развивается.

В инженерных задачах, где данные могут быть сложными (тысячи точек, множество связей), это свойство «глобального внимания» может очень пригодиться.

Однако отметим: свёрточные сети никуда не делись, особенно если у нас в руках просто 2D-чертёж в растровом виде. А Graph Neural Networks (GNN) без трансформера тоже популярны (например, GCN, GAT). Но всё чаще появляются именно Graph Transformer-подходы.

Давайте пройдёмся по основным «веткам» архитектур, которые могут пригодиться для чертежей и 3D.

3.2. Vision Transformer (ViT) для изображений и «проекций»

3.2.1. Классический подход ViT

Vision Transformer (ViT) — модель, где изображение разбивается на патчи (например, 16×16 пикселей), каждый патч считается «токеном», а дальше применяется self-attention. Это доказало свою эффективность на ImageNet и прочих задачах распознавания. Для инженерных нужд ViT может пригодиться, когда:

У нас есть 2D-чертёж в растровом формате (сгенерированный или отсканированный). Модель учится искать линии, окружности, надписи и выдавать заключение, что это за объект.
Мы используем Multi-View рендер 3D-модели: берём деталь, делаем несколько «видов» (спереди, сбоку, сверху, изометрия) — получается набор 2D-изображений. Складываем их как «пачку» и подаём в ViT (или в несколько ViT-голов). Модель учится по этим проекциям понимать форму.

Плюс ViT — он может «увидеть» и мелкие детали, и крупные, если у него хватает внимания и мы правильно выбрали размер патчей.

3.2.2. Пример: «Определи класс детали по её проекциям»

Допустим, у нас есть датасет 3D-моделей — всякие шестерёнки, валы, корпуса. Мы можем автоматически (скриптом) сделать по 6 видов (Front, Back, Left, Right, Top, Bottom), получить 6 картинок. Дальше на вход ViT даём эти 6 картинок (или объединяем их в коллаж), а на выходе просим «какой это класс?». Так учим сетку распознавать категорию детали «как бы по картинкам». Работает, хотя иногда теряется точность, если деталь внутри полая (из виду не всегда ясно, есть ли внутренние полости).

3.2.3. Ограничения

Для сложных, громоздких чертежей (или 3D-моделей) может не хватать производительности.
Не умеем напрямую оперировать точными размерами — всё-таки пиксели это лишь «приблизительное» представление.

3.3. Point Cloud Transformers: когда данные — это «облако точек»

3.3.1. От PointNet к Point Transformer

Долгое время самой известной архитектурой для 3D-облаков точек была PointNet и её последователи (PointNet++, DGCNN). Они основаны на идее, что мы берём N точек (x, y, z), и пытаемся обучить сетку понимать форму, «не обращая внимания» на порядок точек (вспомним, в облаке нет очевидной топологии, как в изображении). Но потом исследователи придумали, что attention также может применяться к набору точек: каждая точка — «токен», у неё есть координаты, возможно, нормаль, цвет, и сеть учится «смотреть», какие точки друг с другом связаны.

Примеры:

Point Transformer,
PCT (Point Cloud Transformer),
Point-BERT.

Все они используют self-attention, чтобы извлекать глобальные и локальные признаки 3D-формы.

3.3.2. Задачи, которые решают Point Transformers

Классификация: «Это шестерёнка или винт? Это корпус подшипника или кронштейн?»
Сегментация: «Какие части этого облака принадлежат отверстию, а какие — основному корпусу?»
Object detection (в строительстве: «где колонна, где окно»).

Когда мы имеем STL или другой меш, мы можем «превратить» его в облако точек (sampling) и подать в Point Transformer. Минусы: мы теряем «идеальные» описания (например, что поверхность цилиндрическая), всё сводится к набору дискретных точек. Плюс, если модель слишком детализированная (миллионы точек), нужно агрессивно сэмплировать (иначе память GPU кончится).

3.3.3. Особенности и ограничения

Проблема чувствительности к порядку. Хотя attention вроде бы «перестановочно-инвариантный», реализация всё равно может зависеть от того, как мы выбрали «пакеты точек».
Вычислительная сложность: O(N²) для N точек, если делаем полный self-attention.
Приходится придумывать уловки типа смешивания локальных групп (clustering), чтобы сократить нагрузку.

3.4. Graph Transformers: когда сборка похожа на «сеть узлов и связей»

3.4.1. Почему граф для инженерии?

Многие серьёзные объекты (станки, механизмы, даже здания) состоят из множества деталей, соединённых разными способами. Это напоминает граф: вершины = детали, рёбра = соединения. Вершины могут иметь свои атрибуты (материал, масса, геометрические параметры), а рёбра — тип крепления, допустимую нагрузку.

Раньше люди использовали классические Graph Neural Networks (GNN): Graph Convolutional Network, Graph Attention Network (GAT). А сейчас популярны Graph Transformer — идея та же, что и в тексте, но attention «пробегается» по вершинам и учитывает рёбра. Под капотом много вариантов (нужно ведь отразить структуру графа).

3.4.2. Задачи, где это реально полезно

Анализ сборок: «Какие детали считаются ключевыми?» (топологическая центральность). «Где потенциальные узлы поломки?» (если знаем статистику разрушений).
Автоматическая группировка: «Разбей сборку на модули, которые логично вместе заказать или изготовить».
Оптимизация: «Убери избыточные связи, но сохрани жёсткость конструкции». Или «Найди наиболее похожую сборку в библиотеке проектов».

3.4.3. Пример JSON для Graph Transformer

Мы в прошлой части показывали пример, где assembly — это вершины. Условно, можно превратить это в список edges и nodes:

{
  "nodes": [
    {"id": 0, "type": "gear", "material": "steel"},
    {"id": 1, "type": "shaft", "material": "alloy"},
    ...
  ],
  "edges": [
    {"src": 0, "dst": 1, "connection": "press-fit"},
    ...
  ]
}

После этого мы прогоняем через сериализацию-токенизацию, и модель Graph Transformer строит эмбеддинг узлов/рёбер, применяя механизм внимания к графу, а не к линейной последовательности. Есть библиотеки вроде PyTorch Geometric или DGL, где всё это уже «полуподготовлено».

3.5. Мультимодальные модели: текст + геометрия, и даже другие данные

3.5.1. Зачем смешивать текст и 3D/чертёж?

В инженерии «просто форма» — это лишь половина картины. Часто важны спецификации, документы, пояснения. Представьте, у нас есть описание узла («Корпус выполнен из алюминиевого сплава 6061, рассчитан на давление 10 бар…») и модель (где мы видим форму, толщину стенок). Было бы круто иметь одну модель, которая читает и текст, и геометрию, и выдаёт связные ответы: «Да, эта форма соответствует описанию, но если давление 10 бар, надо увеличить толщину до 5 мм, иначе опасно».

3.5.2. Как устроить мультимодальный трансформер?

Есть несколько общих схем:

Два (или более) энкодера:
- Один энкодер обрабатывает текст (классический GPT/BERT).
- Второй энкодер обрабатывает геометрию (ViT, Point Transformer, Graph Transformer).
- Затем их выходные embeddings «соединяются» на уровне cross-attention или объединяются в общий скрытый слой.
CLIP-подобная модель (Contrastive Learning)
- Применяется к картинке и тексту, но может быть и к 3D. Мы обучаем модель, что описания (текст) и геометрия должны «соответствовать» друг другу, получаем общее пространство эмбеддингов.

3.5.3. Примеры задач

«Чат-бот для инженера»: загружаем модель детали, плюс весь текст об ограничениях, и спрашиваем: «Подойдёт ли этот узел для температуры 200°C?» Сеть видит форму и знает из описаний, что алюминий при 200°C теряет прочность, — и выдаёт совет (не гарантированно, но если обучена на подобных случаях).
Поиск: «Найди в библиотеке все детали, которые похожи на эту деталь по форме, и у которых в текстовом описании указано ‘сталь 40Х’». Мультимодальная модель может обрабатывать совместно форму (3D) и текст (описания).

3.6. Генеративные трансформеры: создание новых 3D-объектов

3.6.1. Diffusion и прочие новинки

Мы слышали об Stable Diffusion (рисует картинки), ChatGPT (генерирует тексты). Есть и ветка исследований, которая пытается генерировать 3D-объекты на основе «Diffusion»-подходов. Примеры: DreamFusion, 3D-Diffusion, Point-E (от OpenAI). Они пока ориентированы больше на мир 3D-графики (сгенерировать стул, вазу). Но в будущем это может эволюционировать в «Генеративные модели для инженерных форм».

3.6.2. Инженерные ограничения

В отличие от просто «сгенерировать красивую 3D-фигурку», в инженерии мы заботимся о:

Прочности,
Допустимой массе,
Технологичности изготовления,
Соответствии стандартам.

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

3.7. Как выбрать архитектуру под задачу?

3.7.1. Классификация 3D-деталей по форме

Point Transformer или ViT на мульти-проекциях — хороший выбор.
Если при этом есть сборка (и нужны связи), возможно, Graph Transformer.

3.7.2. Анализ сборки

Graph Transformer (или традиционные GNN). Тут важнее топология «какая деталь к какой крепится», чем мельчайшая форма.

3.7.3. Мультимодальный поиск (текст + чертёж)

Два энкодера (текст + геометрия) и общий latent space. Можно что-то CLIP-подобное или специальные фреймворки.

3.7.4. Генерация новых форм

Посмотреть на Diffusion-модели для 3D + «CAE-проверка». Или использовать условный Point-VAE/GAN и как-то контролировать параметры (толщину, число отверстий).

3.8. Практические проблемы при обучении

Объём данных. Трансформеры требуют много примеров. В текстовом мире у нас весь интернет, а в CAD-мире большие датасеты не всегда доступны (корпоративные данные закрыты). Приходится собирать «маленький» датасет или генерировать синтетику.
Вычислительные ресурсы. Attention на 3D-точках может быть дорого. Graph Transformer на сборке из 10 тысяч деталей тоже не шутка. Нужно оптимизировать (сэмплинг, батчи).
Интерпретируемость. Как понять, почему модель решила, что «этот узел слабый»? Attention map может помочь, но всё же это black box.

3.9. Итого: трансформеры — это круто, но не панацея

Мы перечислили кучу вариантов, как можно адаптировать «трансформерные» идеи к 2D-чертежам, 3D-облакам точек, сборкам в виде графа. Плюс, смотрим в сторону мультимодальных моделей и генеративных сетей. Однако в инженерных задачах часто нужно не только «распознать», но и «гарантировать» (прочность, точность). Трансформеры не дают формальных доказательств, они статистические. Поэтому в реальности:

Их используют для предварительного анализа: классификация, поиск, предположения о проблемных местах.
Затем всё это проверяют классическими методами (CAE-расчёт, символьная геометрия).
Или строят гибрид (LLM даёт советы, CAE-движок проверяет).

Но потенциал огромен. Уже сейчас есть случаи, где нейросети реально ускоряют рутинные задачи в машиностроении, BIM, архитектуре, избавляя людей от ручного поиска и сортировки 3D-моделей.

3.10. Что дальше?

На этом мы завершаем обзор основных архитектур. В следующей части (ещё одном блоке нашей объединённой статьи) мы планируем показать «практические кейсы и примеры». Например, как взять маленький датасет STL-моделей, прогнать через Point Transformer или Graph Transformer, и получить работающую (пусть и упрощённую) систему классификации. Попробуем поделиться реальными кодовыми отрывками, библиотеками и советами, чтобы вы могли повторить опыт.

Спасибо за внимание! Надеемся, что теперь вы видите, что трансформеры — это не какой-то «абсолютно уникальный» инструмент, а одна из мощных нейросетевых концепций, которую можно приспособить к геометрии. У каждого подхода есть свои «плюсы и минусы». В реальных проектах нередко используют гибрид: часть данных обрабатывается ViT (или Point Transformer), часть — Graph Transformer, а потом всё это «схлопывается» вместе с текстом или табличной инфой.

Оставайтесь с нами, дальше — практическая сторона вопроса (код, примеры, лайфхаки), а затем подведём общий итог и обсудим «будущее» этой сферы!

Часть 3. Обзор архитектур: как «учить» нейросети понимать геометрию?

3.1. Идея базовая: трансформер vs «классические» CNN и MLP

Универсальность: их можно приспособить и к тексту, и к картинкам, и к аудио, и даже к облакам точек.
Масштабируемость: большие модели (десятки миллиардов параметров) уже стали «стандартом» в NLP, и похожие идеи применяют к Vision Transformer.
Гибкость: self-attention не завязан на фиксированное окно (как свёртки), а может «смотреть» на любые части входных данных. Правда, растёт вычислительная сложность, но железо развивается.

Давайте пройдёмся по основным «веткам» архитектур, которые могут пригодиться для чертежей и 3D.

3.2. Vision Transformer (ViT) для изображений и «проекций»

3.2.1. Классический подход ViT

У нас есть 2D-чертёж в растровом формате (сгенерированный или отсканированный). Модель учится искать линии, окружности, надписи и выдавать заключение, что это за объект.
Мы используем Multi-View рендер 3D-модели: берём деталь, делаем несколько «видов» (спереди, сбоку, сверху, изометрия) — получается набор 2D-изображений. Складываем их как «пачку» и подаём в ViT (или в несколько ViT-голов). Модель учится по этим проекциям понимать форму.

3.2.2. Пример: «Определи класс детали по её проекциям»

3.2.3. Ограничения

Для сложных, громоздких чертежей (или 3D-моделей) может не хватать производительности.
Не умеем напрямую оперировать точными размерами — всё-таки пиксели это лишь «приблизительное» представление.

3.3. Point Cloud Transformers: когда данные — это «облако точек»

3.3.1. От PointNet к Point Transformer

Примеры:

Point Transformer,
PCT (Point Cloud Transformer),
Point-BERT.

Все они используют self-attention, чтобы извлекать глобальные и локальные признаки 3D-формы.

3.3.2. Задачи, которые решают Point Transformers

Классификация: «Это шестерёнка или винт? Это корпус подшипника или кронштейн?»
Сегментация: «Какие части этого облака принадлежат отверстию, а какие — основному корпусу?»
Object detection (в строительстве: «где колонна, где окно»).

3.3.3. Особенности и ограничения

Проблема чувствительности к порядку. Хотя attention вроде бы «перестановочно-инвариантный», реализация всё равно может зависеть от того, как мы выбрали «пакеты точек».
Вычислительная сложность: O(N²) для N точек, если делаем полный self-attention.
Приходится придумывать уловки типа смешивания локальных групп (clustering), чтобы сократить нагрузку.

3.4. Graph Transformers: когда сборка похожа на «сеть узлов и связей»

3.4.1. Почему граф для инженерии?

3.4.2. Задачи, где это реально полезно

Анализ сборок: «Какие детали считаются ключевыми?» (топологическая центральность). «Где потенциальные узлы поломки?» (если знаем статистику разрушений).
Автоматическая группировка: «Разбей сборку на модули, которые логично вместе заказать или изготовить».
Оптимизация: «Убери избыточные связи, но сохрани жёсткость конструкции». Или «Найди наиболее похожую сборку в библиотеке проектов».

3.4.3. Пример JSON для Graph Transformer

Мы в прошлой части показывали пример, где assembly — это вершины. Условно, можно превратить это в список edges и nodes:

{
  "nodes": [
    {"id": 0, "type": "gear", "material": "steel"},
    {"id": 1, "type": "shaft", "material": "alloy"},
    ...
  ],
  "edges": [
    {"src": 0, "dst": 1, "connection": "press-fit"},
    ...
  ]
}

3.5. Мультимодальные модели: текст + геометрия, и даже другие данные

3.5.1. Зачем смешивать текст и 3D/чертёж?

3.5.2. Как устроить мультимодальный трансформер?

Есть несколько общих схем:

Два (или более) энкодера:
- Один энкодер обрабатывает текст (классический GPT/BERT).
- Второй энкодер обрабатывает геометрию (ViT, Point Transformer, Graph Transformer).
- Затем их выходные embeddings «соединяются» на уровне cross-attention или объединяются в общий скрытый слой.
CLIP-подобная модель (Contrastive Learning)
- Применяется к картинке и тексту, но может быть и к 3D. Мы обучаем модель, что описания (текст) и геометрия должны «соответствовать» друг другу, получаем общее пространство эмбеддингов.

3.5.3. Примеры задач

«Чат-бот для инженера»: загружаем модель детали, плюс весь текст об ограничениях, и спрашиваем: «Подойдёт ли этот узел для температуры 200°C?» Сеть видит форму и знает из описаний, что алюминий при 200°C теряет прочность, — и выдаёт совет (не гарантированно, но если обучена на подобных случаях).
Поиск: «Найди в библиотеке все детали, которые похожи на эту деталь по форме, и у которых в текстовом описании указано ‘сталь 40Х’». Мультимодальная модель может обрабатывать совместно форму (3D) и текст (описания).

3.6. Генеративные трансформеры: создание новых 3D-объектов

3.6.1. Diffusion и прочие новинки

3.6.2. Инженерные ограничения

В отличие от просто «сгенерировать красивую 3D-фигурку», в инженерии мы заботимся о:

Прочности,
Допустимой массе,
Технологичности изготовления,
Соответствии стандартам.

3.7. Как выбрать архитектуру под задачу?

3.7.1. Классификация 3D-деталей по форме

Point Transformer или ViT на мульти-проекциях — хороший выбор.
Если при этом есть сборка (и нужны связи), возможно, Graph Transformer.

3.7.2. Анализ сборки

Graph Transformer (или традиционные GNN). Тут важнее топология «какая деталь к какой крепится», чем мельчайшая форма.

3.7.3. Мультимодальный поиск (текст + чертёж)

Два энкодера (текст + геометрия) и общий latent space. Можно что-то CLIP-подобное или специальные фреймворки.

3.7.4. Генерация новых форм

Посмотреть на Diffusion-модели для 3D + «CAE-проверка». Или использовать условный Point-VAE/GAN и как-то контролировать параметры (толщину, число отверстий).

3.8. Практические проблемы при обучении

Объём данных. Трансформеры требуют много примеров. В текстовом мире у нас весь интернет, а в CAD-мире большие датасеты не всегда доступны (корпоративные данные закрыты). Приходится собирать «маленький» датасет или генерировать синтетику.
Вычислительные ресурсы. Attention на 3D-точках может быть дорого. Graph Transformer на сборке из 10 тысяч деталей тоже не шутка. Нужно оптимизировать (сэмплинг, батчи).
Интерпретируемость. Как понять, почему модель решила, что «этот узел слабый»? Attention map может помочь, но всё же это black box.

3.9. Итого: трансформеры — это круто, но не панацея

Их используют для предварительного анализа: классификация, поиск, предположения о проблемных местах.
Затем всё это проверяют классическими методами (CAE-расчёт, символьная геометрия).
Или строят гибрид (LLM даёт советы, CAE-движок проверяет).

3.10. Что дальше?

Надеемся, что теперь вы видите, что трансформеры — это не какой-то «абсолютно уникальный» инструмент, а одна из мощных нейросетевых концепций, которую можно приспособить к геометрии. У каждого подхода есть свои «плюсы и минусы». В реальных проектах нередко используют гибрид: часть данных обрабатывается ViT (или Point Transformer), часть — Graph Transformer, а потом всё это «схлопывается» вместе с текстом или табличной инфой.

Теперь пора перейти к практике: мы покажем, как выглядят реальные (хотя и упрощённые) кейсы, приведём кодовые куски, затронем инструменты вроде PyTorch Geometric, Open3D и т.д. Надеемся, это поможет вам ощутить, что всё не так уж сложно, если идти маленькими шагами.

Часть 4. Практические кейсы и примеры: как «приручить» геометрию на практике

4.1. Маленький пример: берём STL-модели и делаем классификацию

Начнём с простейшего сценария — у нас есть несколько 3D-моделей (скажем, деталей) в формате STL. Каждая модель содержит сетку (меш) из треугольников. Мы хотим обучить сеть (условно, Point Transformer или аналог) различать типы деталей, например:

«Это шестерёнка» (gear),
«Это вал» (shaft),
«Это пластина» (plate),
и т.д.

4.1.1. Готовим набор данных

Собираем или скачиваем несколько STL-моделей. Для начала можно просто набрать в интернете «стл gear» или «стл shaft» — есть сайты с бесплатными моделями, либо использовать ShapeNet (правда, там форматы .obj, придётся конвертить).
Кладём их в папку: data/gears, data/shafts, data/plates — по папкам соответствующим классам.
Пишем скрипт, который их будет читать, превращать в облако точек, и записывать где-нибудь в удобном формате (например, .npz или .ply).

Для чтения STL и получения точек можно использовать библиотеку Open3D (Python). Пример (упрощённый):

import open3d as o3d
import numpy as np
import os

def mesh_to_pointcloud(stl_path, num_points=1024):
    # Читаем STL как триангулярную меш-сетку
    mesh = o3d.io.read_triangle_mesh(stl_path)
    
    # Превращаем меш в облако точек (sample_points_uniformly или Poisson disk)
    pcd = mesh.sample_points_uniformly(number_of_points=num_points)
    points = np.asarray(pcd.points)
    
    return points

# Пример использования
root_dir = "data"
classes = ["gears", "shafts", "plates"]
all_points = []
all_labels = []

for label, cls_name in enumerate(classes):
    cls_dir = os.path.join(root_dir, cls_name)
    stl_files = [f for f in os.listdir(cls_dir) if f.endswith(".stl")]
    
    for stl_file in stl_files:
        stl_path = os.path.join(cls_dir, stl_file)
        pts = mesh_to_pointcloud(stl_path, num_points=1024)
        all_points.append(pts)
        all_labels.append(label)

all_points = np.array(all_points)  # shape: (N, 1024, 3)
all_labels = np.array(all_labels)

Теперь у нас есть all_points (массив размера N × 1024 × 3, где N — число моделей, 1024 — число сэмплированных точек, 3 — xyz-координаты). А all_labels содержит индексы классов (0, 1, 2).

4.1.2. Обучение Point Transformer (или аналог) в PyTorch

Сейчас есть несколько реализаций Point Transformer. Одна из них — в рамках PyTorch Geometric (PyG), другая — в GitHub-репо открытых разработчиков. Для краткости не будем копировать всё, что нужно, но общая идея такая:

import torch
import torch.nn as nn
import torch.optim as optim
from torch.utils.data import Dataset, DataLoader

# Допустим, у нас есть простая Dataset-обёртка:
class PointCloudDataset(Dataset):
    def __init__(self, points, labels):
        self.points = points
        self.labels = labels
    
    def __len__(self):
        return len(self.points)
    
    def __getitem__(self, idx):
        ptcloud = self.points[idx]       # shape (1024, 3)
        label = self.labels[idx]
        return torch.tensor(ptcloud, dtype=torch.float32), label

dataset = PointCloudDataset(all_points, all_labels)
dataloader = DataLoader(dataset, batch_size=8, shuffle=True)

# Здесь мы подключаем Point Transformer (упрощённая версия)
# Можно взять готовую реализацию из PyTorch Geometric или посмотреть репы
# Для примера возьмём выдуманный класс MySimplePointTransformer

class MySimplePointTransformer(nn.Module):
    def __init__(self, num_classes=3):
        super().__init__()
        # ... (какие-то слои attention + MLP)
        self.fc_out = nn.Linear(64, num_classes)  # допустим, 64 это размер эмбеддинга
        
    def forward(self, x):
        # x shape: (batch_size, 1024, 3)
        # Реально нужно аккуратно, обычно добавляют positional encodings, local grouping...
        
        # Имитация: просто загоняем в MLP (не настоящий transformer!)
        # (только чтобы показать пример кода)
        # (в реальной жизни возьмите нормальную реализацию)
        x = x.mean(dim=1)   # берем среднее по точкам (примитив!)
        out = self.fc_out(x)
        return out

model = MySimplePointTransformer(num_classes=len(classes))
optimizer = optim.Adam(model.parameters(), lr=1e-3)
criterion = nn.CrossEntropyLoss()

for epoch in range(20):
    for batch_points, batch_labels in dataloader:
        optimizer.zero_grad()
        logits = model(batch_points)  # shape (batch_size, num_classes)
        loss = criterion(logits, batch_labels)
        loss.backward()
        optimizer.step()
    
    print(f"Epoch {epoch}, loss={loss.item():.4f}")

В реальном проекте, конечно, вы возьмёте настоящую реализацию Point Transformer (где есть много нюансов: внимательные слои, построение графа соседей и т.д.), но этот код иллюстрирует подход:

Сэмплируем точки,
Создаём датасет,
Прогоняем через модель (Transformer/GNN/MLP),
Оптимизируем.

По итогу (при достаточном количестве данных и корректной модели) у вас может получиться классификатор, который по 3D-облаку точки определяет тип детали.

4.2. А если у нас сборка? Графовый пример

Теперь представим более сложный случай: у нас не просто одиночные детали, а сборки (assembly), где есть 5–10 деталей, соединённых друг с другом. Мы хотим научить модель предсказывать, скажем, «есть ли в этой сборке слабое место?» (на основе данных, где слабые места уже обнаружены).

4.2.1. Структурируем данные как граф

Допустим, каждая сборка описана в виде JSON, где:

{
  "assembly_name": "BoxAssembly",
  "nodes": [
    {"id": 0, "material": "steel", "mass": 1.2, "some_feat": 0.3},
    {"id": 1, "material": "steel", "mass": 2.5, "some_feat": 0.1},
    ...
  ],
  "edges": [
    {"src": 0, "dst": 1, "conn_type": "bolt", "strength": 1000},
    ...
  ],
  "label": 1  // 1 means "weak assembly", 0 means "strong"
}

Мы собираем несколько десятков (или сотен) таких сборок. Для каждой у нас есть label (слабая/неслабая). Далее переводим это в формат, понятный PyTorch Geometric (где Graph — это набор вершин + рёбер + опционально глобальные атрибуты).

4.2.2. Используем PyTorch Geometric

Пример (очень схематичный):

from torch_geometric.data import Data
import torch

def assembly_to_data(assembly_json):
    # Преобразуем JSON в объект Data (PyG)
    node_attrs = []
    edges = []
    edge_attrs = []
    
    for node in assembly_json["nodes"]:
        # допустим, переводим material в число (0=steel, 1=aluminum, etc.)
        mat_num = 0 if node["material"] == "steel" else 1
        node_attrs.append([node["mass"], node["some_feat"], mat_num])
    
    for e in assembly_json["edges"]:
        edges.append([e["src"], e["dst"]])
        # conn_type -> numeric
        ctype_num = 0 if e["conn_type"] == "bolt" else 1
        edge_attrs.append([e["strength"], ctype_num])
    
    x = torch.tensor(node_attrs, dtype=torch.float)     # shape [num_nodes, node_features]
    edge_index = torch.tensor(edges, dtype=torch.long).t().contiguous()  # shape [2, E]
    edge_attr = torch.tensor(edge_attrs, dtype=torch.float)
    y = torch.tensor([assembly_json["label"]], dtype=torch.long)
    
    data = Data(x=x, edge_index=edge_index, edge_attr=edge_attr, y=y)
    return data

Затем вы можете собрать все Data-объекты в один InMemoryDataset или ListDataset, и обучить Graph Transformer (в PyTorch Geometric уже есть реализации, например, TransformerConv или GraphAttentionConv).

Пример (псевдо):

from torch_geometric.loader import DataLoader

dataset = []
for asm_json in your_assemblies_list:
    data_obj = assembly_to_data(asm_json)
    dataset.append(data_obj)

loader = DataLoader(dataset, batch_size=4, shuffle=True)

# Допустим, у вас есть GraphTransformerModel ...
model = GraphTransformerModel(...)  # некий класс из PyG
optimizer = torch.optim.Adam(model.parameters(), lr=1e-3)

for epoch in range(20):
    for batch in loader:
        optimizer.zero_grad()
        output = model(batch.x, batch.edge_index, batch.edge_attr, batch.batch)
        loss = F.cross_entropy(output, batch.y)
        loss.backward()
        optimizer.step()

Если всё сделано правильно, сеть будет учиться по графам предсказывать метку (слабая/не слабая). Конечно, в реальности нужны гораздо большие датасеты, осмысленные признаки (не просто mass и material), и т.д.

4.3. Ещё пара «живых» советов

4.3.1. Генерация синтетических данных

В индустрии часто мало готовых размеченных сборок «слабых» и «сильных». Поэтому люди идут на хитрость: создают скрипты, которые генерируют простые сборки (пластины, балки, болты), искусственно помечают некоторые как «слабые» (например, делаем тоньше или нарушаем связи), и так набирают несколько тысяч примеров. Сеть «учится» на синтетике, а потом дообучается на реальных примерах (transfer learning).

4.3.2. Не забывайте про классические алгоритмы

Помимо трансформеров, есть обычные GNN (GCN, GAT) или методы «local adjacency». Для точек (3D) есть PointNet, DGCNN и т.д. Иногда они проще в настройке, требуют меньше данных и работают шустрее. Трансформер может быть «тяжелее». Всё зависит от конкретной задачи.

4.3.3. Целевое применение

Когда вы сделаете демо-классификатор (или анализ сборки), подумайте, как это встроить в рабочий процесс. Часто в индустрии нужно «переубедить» коллег, что ML-модель поможет. Показать маленькую PoC (proof of concept) на реальных данных — лучший путь.

4.4. Мультимодальный пример: «Чертёж + документация»

Вспомним, что иногда у нас есть две составляющие:

Геометрия (например, 2D-чертёж или 3D-модель),
Текст (описание, технические требования).

В таком случае можно взять:

ViT или Point Transformer (для геометрии),
BERT/GPT (для текста),
Наверху какой-то общий слой cross-attention или simple fusion.

На практике есть готовые фреймворки (например, CLIP, BLIP, FLAVA), но они, как правило, заточены под «изображение + текст». Если нужно «3D + текст», придётся искать специализированные исследования или экспериментировать самим.

Идея: вы обучаете оба энкодера так, чтобы они в итоге давали похожие эмбеддинги для «соответствующих» пар (документ о детали — сама деталь) и разные эмбеддинги для «несоответствующих». Это позволяет потом искать по тексту: «покажи мне все детали, где упоминается материал 40Х», — и сеть выдаёт геометрические объекты из базы, у которых в описании фигурирует 40Х.

4.5. Небольшой реальный кейс (псевдо-история)

Допустим, вы — студент-инженер, у вас есть доступ к локальной базе моделей простых деталей (штук 300). Вы делаете мини-проект:

Собираете .STL, .STEP файлы, пишете скрипт для parsing (при наличии).
Получаете от преподавателя или наставника метки («это кронштейн», «это вал», «это фланец»).
Превращаете всё либо в облака точек (для 3D-форм), либо в JSON-описание.
Берёте PyTorch (или TensorFlow), поднимаете простейшую модель (PointNet++ или GraphNet).
Обучаете, проверяете точность на валидации.
Если всё ок, делаете мини-приложение (например, на Flask), где можно «загрузить STL», и оно выдаёт предположение о классе детали.

Защищаете этот мини-проект как курсовую или дипломную. И уже это — шаг к тому, чтобы показать, что ML и нейросети могут работать с инженерными данными. В реальном мире, конечно, масштаб другой (тысячи деталей, сборки, специфичные атрибуты), и там вылезает много нюансов, но принципы похожи.

4.6. Подводим итоги практики

Даже простой пайплайн (прочитать модель → сэмплировать точки → обучить классификатор) вполне реален на Python с Open3D + PyTorch Geometric.
Graph-ориентированный» подход лучше для сборок, когда важна структура связей между деталями.
Мультимодальные решения позволяют объединять текст (техтребования, описания) с геометрией. Сложнее в реализации, но даёт большую «умность».
Синтетика бывает нужна, когда не хватает реальных данных.
В индустриальных задачах почти всегда нужна «доводка» — учесть материалы, технологичность, реальные допуски. Трансформеры сами по себе не решат вопрос, но ускорят рутинные проверки и поиски.

4.7. Что дальше?

В следующей (заключительной) части нашей большой статьи мы поговорим о будущем:

Где лежат главные ограничения (логические доказательства, точные расчёты, сертификация)?
Какие перспективы (можем ли мы ожидать «EngineeringGPT», который не только «болтает», но и «черчит» корректно)?
Как внедрять всё это в реальные рабочие процессы?

Но прежде чем двигаться далее, предлагаем вам, если есть время, попробовать сделать маленький прототип. Возьмите пару STL-моделек, попробуйте описанный код (или похожий), и, возможно, вы сами увидите, что «о, сеть уже кое-что умеет различать!» Это воодушевляет и даёт понимание, куда копать дальше.

Если вы уже имеете опыт подобных проектов — делитесь своими кейсами, особенно если они касаются графовых сборок или мультимодального анализа. Сообщество инженерных ML-инструментов пока ещё не такое большое, но вместе мы можем ускорить развитие «умных CAD-систем».

Спасибо, что дочитали четвёртую часть! До встречи в финале, где мы подведём глобальные итоги и посмотрим в будущее.

Часть 5. Будущее и выводы: куда приведут нас «умные» нейросети в инженерии

5.1. Основные итоги: что мы уже умеем?

Давайте коротко повторим, что мы узнали:

Нейросети и трансформеры стали невероятно популярны в тексте и изображениях. Идея «посадить» трансформеры на геометрию — логичное продолжение Data-Driven подхода.
Представление чертежей (или 3D) в виде сериализованных форматов (JSON, графы, облака точек) даёт машинам доступ к точным координатам, материалам, связям — всё это дороже, чем просто пиксели.
Архитектуры:
- Vision Transformer (ViT) годится для 2D-чертежей или проекций 3D;
- Point Transformer и аналоги — для облаков точек (сырая 3D-форма);
- Graph Transformer — для сборок, где важна топология деталей и связей;
- Мультимодальные модели совмещают текст + геометрию. И каждая из этих концепций уже проверена на практике (пусть и в относительно небольших пилотах).
Практические кейсы: классификация деталей, поиск похожих узлов, анализ сборок на уязвимости, генерация форм (под контролем классических CAE). Всё это уже реализовывается в научных проектах и стартапах.

Главный посыл — ничего принципиально невозможного в том, чтобы «учить» нейросети распознавать и даже частично интерпретировать инженерную геометрию, нет. Но есть и масса сложностей.

5.2. Основные проблемы и ограничения

5.2.1. Формальная точность и гарантии

Как мы многократно подчёркивали, статистические модели (GPT, Point Transformer и т.п.) не дают строгих доказательств и не могут «гарантировать» соответствие нормативам. Если нам надо быть уверенными, что «эта балка выдержит 2 тонны нагрузки», по-прежнему придётся использовать CAE-инструменты (например, метод конечных элементов). Нейросеть может лишь «предположить» (на основе опыта), что может быть «слабое место», но не докажет это формально.

5.2.2. Доступ к большим датасетам

В тексте и картинках мы привыкли, что есть огромные общие наборы (Wikipedia, Common Crawl, ImageNet). В инженерии же реальная геометрия часто лежит в частных корпоративных архивах и не общедоступна. Да и стандарты, ГОСТы, нормоконтроль — всё это сильно варьируется. Значит, создать «общий» датасет на сотни миллионов деталей гораздо сложнее. Отсюда:

Меньше open-source решений,
Преобладание внутренних корпоративных проектов,
Затруднённое «коллаборативное» развитие.

5.2.3. Вычислительные ресурсы

Обработка больших 3D-моделей (или сборок) требует много памяти. Трансформер с вниманием на 100k точек — это чудовищно дорого. Приходится делать сэмплинг, иерархическую обработку, либо обходиться графами с ограниченным числом узлов. Это сужает возможности «в лоб» анализировать огромные структуры.

5.2.4. Консервативность отраслей

Машиностроение, стройка, авиакосмос — сферы, где ценятся надёжность и проверенные методики. Новые методы (ML) внедряются осторожно. Люди понимают: «Ошибёшься — выйдет из строя самолёт или мост, это недопустимо». Значит, сертификация любых «автоматических» решений — длительный процесс.

5.3. Гибрид «символических» и «коннекционистских» подходов: путь к формальной инженерной логике?

Один из самых перспективных направлений — гибридные системы, где нейросеть (например, LLM) генерирует предположения, шаги решения, а отдельный «геометрический движок» или CAE-программа проверяет результат. Примерно так, как в математических теоремах: LLM предлагает идеи доказательства, а формальный проверяльщик (proof assistant) говорит «ОК» или «ошибка».

В инженерии можно представить, что в будущем появятся ассистенты, которые:

Анализируют ваш чертёж/3D-модель,
Выдают совет: «Добавьте ребро жёсткости здесь — у меня есть подозрение на изгиб»,
Автоматически запускают FEM-сети (либо CAE), чтобы проверить, действительно ли напряжения снижаются,
Возвращают согласованный результат: «Да, это улучшило конструкцию».

Это позволило бы соединить «креативность» ML (она может находить нестандартные решения, если видела похожее где-то) и жёсткость классических расчётов.

5.4. Возможные сценарии будущего

5.4.1. «EngineeringGPT» в CAD-системе

Представьте, что в новом поколении SolidWorks, NX или CATIA появляется встроенный чат, куда вы пишете:

«Спроектируй мне кронштейн для крепления этого вала, чтобы выдерживал 500 Н и весил не более 300 г, учти материал 6061-T6, желательно без лишней сложности».

Система «в реальном времени»:

Генерирует несколько вариантов (3D-модели),
Прогоняет их через быстрый FEA-расчёт,
Выдаёт инженеру «рекомендованный» вариант и пару альтернатив.
При необходимости дорабатывает форму по замечаниям инженера.

Это уже не чистая фантастика: похожие «Generative Design» модули существуют (Autodesk Fusion 360, Ansys Discovery), но пока они не настолько дружелюбны, как ChatGPT, и всё же требуют специализированных настроек. Если это объединить с LLM, получится более гибкий интерфейс и более интеллектуальные предложения.

5.4.2. Автоматизированный аудит BIM-проектов

В строительстве (BIM-модели, IFC) уже есть зачатки автоматических проверок: «Есть ли в проекте противопожарная лестница на каждом этаже? Соответствует ли ширина коридора нормативам?» Мультимодальная нейросеть, «читая» IFC (или сериализованный формат) + локальные нормативные документы, может выполнять часть проверок. Потом человек-эксперт подтверждает или опровергает. Со временем, при обучении на массиве проектов, ассимилируется всё больше правил.

5.4.3. «Корпоративный Copilot для инженеров»

Многие компании хотят «копилот»-систему: «Вот все наши внутренние чертежи, спецификации, отчёты, ГОСТы. Пусть нейросеть станет быстрым справочником и советчиком». Интегрируем туда механику работы с 3D-моделями, и в итоге получаем возможность:

«Показать мне все детали, которые ломались в прошлом году»,
«Что меняли в этом редукторе в версии v3?»,
«Посоветуй, как улучшить тепловой отвод в этом узле, учитывая опыт прошлых проектов».

Плюс, всё это в формате дружелюбного чата или визуальной консоли, что ускоряет работу команды.

5.5. Риски, этика и «подводные камни»

Разумеется, подобно любым ML-системам, «умные» чертёжно-инженерные модели могут ошибаться, «галлюцинировать» несуществующие детали, путать стандарты. Опасно безоглядно доверять им серьёзные решения, особенно где ставка — человеческая жизнь. Поэтому нужно:

Всегда держать «человека в петле» (human-in-the-loop).
Обеспечивать проверку (или верификацию) критических рекомендаций.
Понимать, что «жадное» внедрение без тестирования может привести к браку или авариям.
Соблюдать коммерческие и авторские права: если модель обучена на секретных чертежах, нельзя давать ей публичный доступ.

5.6. Практические советы для тех, кто хочет внедрять

Начинайте с пилотного проекта: возьмите простую задачу (классификация деталей, поиск похожих чертежей). Убедитесь, что ML даёт пользу.
Выбирайте правильное представление: если задача — анализ структуры сборки, лучше граф; если надо вытащить особенности формы, лучше Point/ViT.
Соберите максимально возможный датасет (даже если это 100–200 примеров). При сильном дефиците данных — генерируйте синтетику, делайте аугментации.
Не забывайте про ручную проверку: то, что выдаёт модель, может содержать промахи.
Документируйте процесс: как именно вы сериализовали данные, какие фичи добавили. Инженерная сфера дорожит повторяемостью и прозрачностью.

5.7. Заключительные мысли: роботы не заменят инженеров, но помогут им

Главная мысль, с которой хочется уйти после нашей серии: ML-модели не отменяют «инженерный разум», они дополняют его. Компьютер (ещё с эпохи CAD) давно выступает «инструментом» для чертёжников и проектировщиков. Сейчас мы переходим на следующий уровень — инструмент начинает «подсказывать» и «изучать» паттерны, собранные из многих предыдущих проектов. Это может ускорить проектирование, выявить скрытые ошибки, сэкономить деньги и ресурсы.

Но окончательное решение: какую толщину делать, где ставить ребро, какой материал выбрать, — всё ещё лучше принимает живой инженер (или совместно с «гибридной» системой проверок). В обозримом будущем это не изменится: мы точно не ждём, что «сеточка» сама будет подписывать ответственную документацию и нести юридическую ответственность. Инженер — всё равно ключевая фигура, но теперь с более «умными» инструментами.

5.8. Спасибо за внимание! Полезные ссылки и напутствия

Мы рады, что вы прошли с нами этот путь от идеи (зачем нужны нейросети для чертежей?) до практики (примерный код, архитектуры) и перспектив (будущее систем EngineeringGPT). Надеемся, это вдохновит вас попробовать что-то самостоятельно или хотя бы просветит по теме. В качестве финального штриха — небольшой список ссылок и ресурсов, где можно продолжить чтение:

ShapeNet / ModelNet / ABC Dataset: для 3D-моделей (мы упоминали их в предыдущих частях). Отличный старт, если нужна «игрушечная» база данных.
Open3D (Python) — удобная библиотека для работы с 3D (загрузка/сохранение мешей, облака точек, визуализация).
PyTorch Geometric — набор инструментов для графовых и 3D-задач (есть и PointNet, и Graph Transformers).
Будущее ChatGPT-подобных моделей в инженерии — следите за новостями крупных CAE/CAD-вендоров (Ansys, Autodesk, Siemens, Dassault). Они уже публично показывают кое-какие «интеллектуальные» модули.

И на последок: экспериментируйте. Может, ваша компания (или университет) хранит кучу «мертвых» чертежей в архивах. Попробуйте взять пару десятков, вытащить ключевые признаки, покормить их нейросети. Даже если вы столкнётесь с кривыми форматами и шумными данными, вы уже сделаете шаг вперёд — к «умной» инженерии, где машина действительно помогает, а не просто рисует.

Спасибо, что были с нами до конца. Успехов в ваших будущих исследованиях и проектах на стыке ML и инженерной геометрии. Будем рады, если наши материалы помогут кому-то сделать первые (или более уверенные) шаги в этой захватывающей сфере!

Примечание: немного полезных ссылок:

ShapeNet: крупный датасет 3D-моделей (https://github.com/topics/shapenet-dataset), часто используемый в исследованиях по 3D-ML.
ModelNet: ещё один набор CAD-моделей, «Hello World» для классификации 3D-объектов (сайт Принстонского университета).
ABC Dataset: содержит параметрические CAD-модели (NURBS, STEP и т.д.) для глубокого обучения (GitHub).
PyTorch Geometric: фреймворк для графовых нейросетей, куда можно «притулить» Graph Transformer или GNN (docs).
Point Transformer: семейство статей/репо, где описан подход attention для облаков точек (например, пример).

Комментарии (1)

e_u_g
22.01.2025 11:20
#27817536
Отлично написано!