Привет, Хаб��! Меня зовут Артур Ишмаев, я руководитель отдела внедрения и развития нейросетей в дирекции цифровых инноваций и ИИ в ПИК. 

В первой части статьи я подробно разбирал работу Data-driven Interior Plan Generation for Residential Buildings (2019) — одного из первых проектов, пытающихся воспроизвести процесс проектирования дома с помощью нейронных сетей, а именно с помощью набора свёрточных моделей.

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

Начну я с инструмента WallPlan, который стал важным промежуточным этапом в эволюции генеративных планировочных систем.

Рис. 1. Режимы использования Wallplan.
Рис. 1. Режимы использования Wallplan.
Рис. 2. Поэтапная генерация планировки ансамблем моделей.
Рис. 2. Поэтапная генерация планировки ансамблем моделей.

Wallplan, July 2022: план как граф стен, а не пиксели

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

WallPlan предлагает принципиально иной подход: модель генерирует не картинку плана, а wall graph — граф, состоящий из стен и помещений. Это очень важный поворот: впервые план рассматривается как набор архитектурных сущностей. Разберём подробнее.

Как это работает

Архитектура WallPlan гибридная и состоит из трёх свёрточных нейронных сетей (CNN), каждая из которых решает свою подзадачу: WinNet предсказывает расположение окон, GraphNet итеративно генерирует граф стен, а LabelNet определяет семантику помещений. Они работают не одновременно, а по очереди в несколько шагов. 

Рис. 3. Генерация wall graph моделью WallPlan.
Рис. 3. Генерация wall graph моделью WallPlan.

На вход WallPlan может получить несколько типов информации:

  1. контур квартиры (обязательный параметр);

  2. позицию входной двери;

  3. опционально: заранее заданные окна, несущие стены и колонны, а также bubble diagram — схему помещений и их связей.

Все эти вещи кодируются как многоканальная карта (маски) + граф, так что модель «видит» и форму, и конструктив, и пожелания по функционалу.

Рис. 4. Варианты исходных данных. Слева направо: 1 – только контур и дверь, 2 – + окна, 3 – + несущие стены и колонны, 4 – + bubble diagram, 5 – разные сочетания исходных данных.
Рис. 4. Варианты исходных данных. Слева направо: 1 – только контур и дверь, 2 – + окна, 3 – + несущие стены и колонны, 4 – + bubble diagram, 5 – разные сочетания исходных данных.

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

  1. на вход WinNet идёт только контур квартиры;

  2. модель предсказывает расположение окон по периметру (маску окон);

  3. получаем «обогащённую» границу: контур + окна.

Рис. 5. Генерация окон WinNet.
Рис. 5. Генерация окон WinNet.

Зачем это нужно? Авторы трактуют окна как мягкое ограничение планировки: через них в квартиру заходит свет, а значит, они задают логичное расположение жилых помещений. Без этой подсказки комнаты получаются слишком случайными и часто нелепыми.

Если окна заданы пользователем, WinNet можно считать «пропущенным»: в WallPlan просто подаётся готовая маска окон.

Инициализация wall graph

Дальше моделью GraphNet создаётся начальный wall graph.

Рис. 6. Стартовая точка wall graph, сгенерированная GraphNet.
Рис. 6. Стартовая точка wall graph, сгенерированная GraphNet.

Этот нулевой граф wall graph (точка)​ — стартовое состояние, от которого WallPlan начинает ��обход» и дорисовывает стены итеративно. Что это значит? Пара моделей GraphNet + LabelNet по кругу начинают генерацию и помогают друг другу. Вся магия происходит в цикле: 

  1. LabelNet понимает, что за пространство мы сейчас строим;

  2. GraphNet решает, какую стену дорисовать дальше.

Цикл происходит несколько раз подряд.

Рис. 7. Циклическая генерация моделями GraphNet + LabelNet.
Рис. 7. Циклическая генерация моделями GraphNet + LabelNet.

На каждой итерации на вход LabelNet подаются:

  1. текущий граф стен;

  2. контур квартиры.

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


Рис. 8. Процесс работы LabelNet.
Рис. 8. Процесс работы LabelNet.

Это глобальное «предчувствие» того, что за план у нас должен получиться в итоге.

Дальше в дело вступает GraphNet. На вход GraphNet идут:

  1. текущий граф стен;

  2. контур;

  3. семантика;

  4. закодированные ограничения (окна, несущие, bubble diagram, если есть).

На выходе мы получаем приращение графа:

  1. новые узлы (стеновые точки);

  2. новые рёбра (стеновые сегменты).

Рис. 9. Процесс работы GraphNet.
Рис. 9. Процесс работы GraphNet.

GraphNet имитирует обход графа: как будто мы идём по уже построенным стенам и решаем, откуда и куда провести следующую. За счёт семантики от LabelNet модель не просто рисует случайные перегородки, а пытается разумно поделить пространство на комнаты. После этого граф не обновляется, а повторяется: снова LabelNet, снова GraphNet.

Рис. 10. Результаты работы GraphNet + LabelNet шаг за шагом.
Рис. 10. Результаты работы GraphNet + LabelNet шаг за шагом.

Остановка и результат

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

На выходе WallPlan генерирует:

  1. Связный wall graph (узлы – это стыки стен, рёбра – это стеновые сегменты).

  2. Room labels в виде пятен из LabelNet, где какая комната расположена.

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

Варианты использования (режимы работы)

За счёт гибридности подхода и многоканального входа WallPlan предполагает несколько вариантов и режимов использования.

Рис. 11. Режимы использования Wallplan.
Рис. 11. Режимы использования Wallplan.

Только контур

Это базовый сценарий, когда на вход идёт только форма квартиры. WinNet сам расставляет окна. Дальше GraphNet и LabelNet строят план с нуля с учётом формы и окна.

Контур + заданные окна

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

Контур + несущие стены и колонны

Рис. 12. Генерация на основе контура и несущих элементов.
Рис. 12. Генерация на основе контура и несущих элементов.

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

Контур + bubble diagram

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

Гибридные ограничения

Можно одновременно использовать в качестве исходных данных подать и контур, и окна, и несущие, и bubble diagram. Всё это просто добавляется в разные каналы входа, архитектуру менять не нужно.

Рис. 13. Результаты генераций с разными исходными данными на входе.
Рис. 13. Результаты генераций с разными исходными данными на входе.

Ограничения WallPlan: что модель не умеет и где начинаются проблемы

Несмотря на то, что WallPlan делает важный шаг от пиксельной генерации к структурной, у этого подхода есть несколько фундаментальных ограничений. Именно они в итоге привели к появлению более продвинутых моделей вроде BubbleFormer. Рассмотрим ключевые слабые места.

Во-первых, модель не генерирует функциональную структуру планировки. WallPlan работает только со стенами и предполагает, что информация о назначении помещений и их связях задана извне. Без bubble diagram или других подсказок модель фактически «угадывает» эту логику по геометрии.

Во-вторых, качество результата зависит от входных данных. Некорректно заданные окна, вход или конструктив напрямую приводят к ошибкам в планировке. Модель не умеет критически переосмысливать ввод и не обладает архитектурным «здравым смыслом».

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

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

Рис. 14. Результаты генераций с разными исходными данными на входе.
Рис. 14. Результаты генераций с разными исходными данными на входе.

Выводы по WallPlan

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

Однако по своей сути WallPlan решает вторую половину задачи, а именно — геометрию стен. Он не формирует планировочное решение и не отвечает на вопрос, какие помещения должны появиться и как они должны быть связаны. 

Что дальше?

Чтобы двигаться дальше, необходима модель, которая сначала генерирует функциональную структуру, а уже затем передаёт её на этап построения стен. Именно таким шагом стало появление BubbleFormer — модели, которая работает с планом как с набором помещений и связей между ними. О ней я расскажу в следующей части.

Подписывайтесь на телеграм-канал нашей команды Лаборатория ИИ — в нём делимся собственными наработками и полезными новостями.