Небольшое вступление
Всем добрый день, работаю в маленькой компании на должности bim-manager и по совместительству ведущим архитектором. Увлекаюсь, изучаю программирование. И чем больше разбираюсь, тем больше завидую.
Архитектура как отрасль очень сильно отстает от IT в плане инстурментов и методов разработки проектов. В IT давно есть среды разработки, а мы по прежнему создаем отдельные файлы и затем долго и нудно собираем их в один проект; ретроспективу после проекта некоторые основатели платных курсов называют своей уникальной методологией которую они придумали; и самое главное нету паттернов. Каждый раз в каждом проекте приходится подолгу объяснять одни и те же решения одних и тех же задач. И вот постепенно такая ситуация привела к решению, что пора сформировать/сформулировать эти самые паттерны для архитектурного проектирования. Прежде всего описанные ниже паттерны применимы к разработке в программе Archicad.
Перечень паттернов
По аналогии с программированием показалось не лишним структурировать их в зависимости от типа решаемых задач
Сборочные (или структурные)
Определяют структуру как будет разбит и собран проект или части крупного проекта. Выбор зависит от высоты здания, количества и конфигурации групп типовых элементов
Горизонтальная типовость
Вертикальная типовость
Компоновщик (или древовидная типовость)
Сам себе режисер
Преобразования элементов
Отвечают за решение локальных задач с геометрией. Не влияют на структуру проекта, но в некоторых случаях могут помочь ее упростить
Подмена (или заменитель)
Проводник
Тянущая привязка
Лосины (или натягивание на рельеф)
Единственный экземпляр
Координационные
Отвечают за способы взаимодействия проектировщиков или файлов с разными ключевыми задачами
Наблюдатель
Главный файл
Фантом
Вариантные
Определяют каким образом внутри проекта будут создаваться варианты
MODный вариант
Вариант через фильтр реконструкции (не придумал пока как короче назвать)
Подробное описание каждого
Горизонтальная типовость
Ссылка на файлы с примером реализации
Основной принцип - определение этажа как типа целиком
Задача: разбить по типовости большой многоэтажный комплекс. При этом часть элементов может повторяться с 5 по 24 этаж, часть только с 7 по 22, еще часть с 8 по 20.
Решение: распределяем типы буквально как идет повторение по этажам тип1 -> для 3-6, 23-24 этажей, тип2 -> 7,21-22 и тип3 -> 8-20
Плюсы: самая простая для понимания структура сборки. Минимум типовых этажей.
Минусы: будет много повторений элементов (ctrl+c, ctrl+v) и много лишней работы. В чистом виде дальше стадии ПП данный паттерн применять нецелесообразно, т.к. одно малейшее отличие и надо создавать другой тип с вытекающим дублированием огромного количества элементов. И каждый раз добавляя, изменяя элементы на одном типе - нужно будет повторить для идентичных элементов в другом типе
Схема:
Spoiler
Вертикальная типовость
Ссылка на файлы с примером реализации
Основной принцип - определение как типы отдельные группы повторяющихся элементов
Задача: такая же как и у предыдущего - разбить по типовости большой многоэтажный комплекс. При этом часть элементов может повторяться с 5 по 24 этаж, часть только с 7 по 22, еще часть с 8 по 20.
Решение: распределяем, дробим по повторяющимся группам элементов типы как тип1 -> для 3-24 этажей, тип2 -> 7-22 и тип3 -> 8-20, координация типов осуществляется через фоновую ссылку
Плюсы: нету повторяемости элементов. Относительно простая для понимания модель
Минусы: сложно редактировать в местах, где типовые части этажей граничат друг с другом. Очень много частей, и нужно внимательно, кратко и очень четко называть, чтоб понятно было содержимое по названию
Схема:
Spoiler
Компоновщик
Ссылка на файлы с примером реализации
Основной принцип - выделение как типы только отдельные группы повторяющихся элементов, и выстраивание древовидной структуры. Из мелких групп собираются и дополняются более крупные типовые группы элементов
Задача: такая же как и у предыдущего - разбить по типовости большой многоэтажный комплекс. При этом часть элементов может повторяться с 5 по 24 этаж, часть только с 7 по 22, еще часть с 8 по 20.
Решение: дробим по аналогии с Вертикальной типовостью. Создаем тип1 для частей, которые повторяются на 3-24, создаем тип2 для 7-22 и в него подгружаем уже готовый тип1, создаем тип3 для 8-20 и в него подгружаем уже готовый тип2
Плюсы: нету повторяемости элементов, очень легко редактировать т.к. по мере компоновки в более крупные типовые части видна вся модель этажа, тем самым сокращается гадание на кофейной гуще высматривание элементов через фоновую ссылку как в вертикальной типовости
Минусы: очень тяжелая для первого понимания модель, долго обновляются связи в основной модели (в сборке)
Схема:
Spoiler
Сам себе режиссер
Ссылка на файлы с примером реализации
Один самодостаточный файл, в котором содержатся как типовые группы элементов, так и основная сборка бим модели. Актуален для небольших проектов, стадии ПП
Задача: собрать простую бим модель. Для упрощения архитектор сразу старается закладывать какую-нибудь типовость. Групп типовых элементов не так много, что бы создавать и выстраивать структуру из отдельных файлов.
Решение: создаем все в одном файле. У нас есть этажи основной модели (например с -1 по 5). Делаем небольшой отступ ниже ( -2, -3, -4) и начиная с -5го принимаем как этажи на которых будут располагаться типовые группы элементов. Затем эти типовые подгружаем в пространство основной модели. Таким образом получается, что файл вкладывается сам в себя. Сам себе служит .mod-ом
Схема:
Spoiler
Подмена
Ссылка на файлы с примером реализации
Использование базовых функций программы по автоматическому взаимодействию геометрии, чтобы локально заменить одну часть геометрии на другую.
Задача: Например в элементе модели нужно сделать локальные вставки, или не хочется дробить и нарушать типовость в модах из-за нескольких отличающихся неключевых элементов.
Решение: Ставим колонну, или перекрытие как автоматически вычитающий элемент (можно балку и стену но не рекомендуется из-за возможных сложностей с привязками).
Настроить необходимо так: у элемента, которым собираемся вычитать - материал с максимальным приоритетом, вспомогательный слой, который будет скрыт (у нас для этого есть слой "Элементы выдавливания.ВСП"), уровень слоя выдавливания должен совпадать со слоями, на которых лежат целевые элементы в которых собрались делать подмену. Затем моделим то, чем хотим подменить. Эти элементы уже должны использовать слой с другим уровнем, чтобы их так же не вычло по приоритету материалов. В примере подмена реализована как отдельный мод.
Минусы: подходит только для декоративных элементов, инженерии и для локальной пробы вариантов на ранних стадиях проекта.
Схема:
Spoiler
Проводник
Ссылка на файлы с примером реализации
Проводник - файл, в котором происходят минимальные изменения или дополнения группы элементов для дальнейшего использования в проекте
Задача: Есть собранная база юнитов (юнит - группа элементов, которые отстраиваются и специфицируются как один объект), например, перемычки или вентблоки. И нужно их затянуть в разные проекты. Глобально в базе, если жестко замаркировать, то в проектах в ведомостях могут получиться разбежности типа ВБ-01 ВБ-04. В каждом проекте используется разный набор вентблоков. Дублировать файл, чтобы перебить на свои, тоже не имеет смысла, т. к. в случае глобальных корректировок, дополнения или детализирования - нужно будет повторить всю работу.
Решение: В исходном файле, основном, в котором собраны все - типы не индексируем, а подгружаем его как связь в мод юнитов самого проекта. Маркировку будем обозначать и снимать с ID. Назначаем ID через "ID связи"(Master ID)
Схема:
Spoiler
Тянущая привязка
Ссылка на файлы с примером реализации
Тянущая привязка - использование особенностей программы по построению геометрии на основе линий привязок для минимизирования дробления на разные типы, т. е. для унификации проекта.
Задача: Например надизайнировали такую архитектуру, что внешние стены по фасаду немного гуляют вперед-назад, то выступают, то заглубляются. При этом планировка внутри здания остаётся та же. Усложнять проект и долепливать на каждом этаже стены или новый типовой этаж - традиционное и не очень эффективное решение
Решение: Стены пляшущего фасада конфигурируем таким образом, чтобы привязка всегда располагалась в одном месте. Стены внутренние на каждом этаже будут ловить привязку и автоматически заполнять меняющееся пространство. Зоны так же корректно обновляются
Минусы: Мы больше не можем использовать линию привязки как объективный параметр (напр. "длина линии привязки")
Схема:
Spoiler
Лосины
Ссылка на файлы с примером реализации
Натягивание на ральеф - набор последовательных действий для быстрого эскизного отстроения благоустройства (дорожек, площадок) по рельефу.
Задача: Быстро (не для Р), концептуально, но красиво отстроить все дороги, дорожки, площадки на рельефе. Вылепливать вершинами 3д сетки - долго.
Решение: В плане отмоделиваем все элементы генплана, которые нужно натянуть на рельеф. Назначяем им всем низ - ниже, чем самая низкая точка на рельефе (можно 1м, но лучше брать с запасом около 5м), высота - выше, чем самая верхняя точка на рельефе. Заходим в "операции твердотельного моделирования", все элементы благоустройства определяем как "целевые элементы", рельеф как "элементы оператора", Если рельеф имеет толщину (тело), то в операциях твердотельного моделирования выбираем параметр "пересечение", иначе параметр "вычитание с выталкиванием вверх", жмем "Выполнить", преобразовываем элементы в морф. Далее у нас есть 2 варианта. 1- поднимаем морфы на 20+мм над рельефом. 2- с помощью того же инстурмента вычитаем морфы из земли. Элементы благоустройства получаются как бы натянуты тонким слоем ровно по рельефу.
Примечание: Заметно только с ближних статичных ракурсов. Люмион и твинмоушен может некорректно понимать, что есть верх в такой натянутой дороге и машины/люди могут пойти по самому рельефу, как бы проваливаясь на несколько сантиметров в текстуры.
Spoiler
Единственный экземпляр
Ссылка на файлы с примером реализации
Нацелен на упрощение структуры и облегчение основных сборных файлов, путем отстраивания групп вертикальных элементов в полную высоту с релевантным отображением.
Задача: Отстроить типовые элементы колонн/пилонов, диафрагм жесткости, в которых нету проемов в многоэтажном ЖК (18+ этажей). Традиционный способ не очень эффективен с точки зрения использования ресурсов компа - колонна в высоту этажа и поехали по 10+ этажей тиражировать одинаковые модули.
Решение: Создаем и размещаем типовые вертикальные элементы один раз. Настройки следующие: привязка верха - к этажу на 1 выше от того, где должен элемент отображаться, отображение на этажах - релевантный. Для отображения на типовых этажах в файлах с отдельными типами - можно размещать элементы на вспомогательных этажах ниже, которые не используются для подгрузки в сборку. (подробнее можно увидеть в файлах с примерами сборочных паттернов)
Spoiler
Наблюдатель
Ссылка на файлы с примером реализации
Наблюдатель - файл в котором не происходит сбор/редактирование/создание основной бим модели, но имеет конфигурации и инструменты для аналитики модели или выпуска
Задача: Крупный проект, модель здания необходимо анализировать, сопоставлять с другими моделями от инженеров, конструкторов, производить расчёты, а ещё оформлять и выводить всё это кучей разных способов. Если делать всё в одном файле с моделью, то не найдётся в мире настолько мощного компьютера, который смог бы такой файл потянуть.
Решение: Отделяем все сопутствующие задачи от модели в отдельные файлы. Модель собираем и редактируем конкретно в одном файле. В остальные подгружаем целиком как связь и проводим там все нужные операции. Например так можно отделить в файл задачу по анализу инсоляции. Грассхоппер будет связываться со специальным для этой задачи файлом, а не моделью над, которой работают архитекторы. Можно отделить подсчет объемов материалов, оформление заданий и выпуска и т д. В конечном итоге заведем шаблоны с уникальными для каждой задачи пресетами вместо того, чтобы утежелять основной шаблон.
Spoiler
Главный файл
Ссылка на файлы с примером реализации
Главный файл - основной файл, в котором собирается бим модель, пригоден для выпуска, и с которого возвращается как подложки PMK
Задача: Проектировщики параллельно создают варианты планировок, варианты фасадов. Их надо между собой как-то координировать, чтобы после без длительной подгонки выпустить все необходимые чертежи, визы, и тп.
Решение: выделяем в структуре проекта главный файл в котором будет собираться конечная модель из модели с планами + модели с фасадами. Для обратной связи выгружаем из главного файла PMK и затягиваем как подложки в модели планов и фасадов. Таким же образом главным файлом может быть объявлен файл модели планов или фасадов
Spoiler
Фантом
Ссылка на файлы с примером реализации
Фантом - способ координации двух моделей, при котором подложенные модели не существуют на тех этажах, на которых отображаются.
Задача: Такая же как и в предыдущем. Проектировщики параллельно создают варианты планировок, варианты фасадов. Их надо между собой как-то координировать, чтобы после без длительной подгонки выпустить все необходимые чертежи, визы, и тп.
Решение: Отстраиваем модель фасада с параметрами отображение элементов "все релевантные этажи". Отстраиваем модель планов этажей с отображением элементов "все релевантные этажи". В одном файле (напр с фасадами) ниже этажей основной модели +несколько этажей для отступа набиваем структуру этажей идентичную основной модели, подгружаем на доп этажи все планы и вручную в 3д стягиваем на отметки в область основной модели. В другом файле проворачиваем то же самое с фасадами, но на этажах выше основной модели + несколько этажей для отступа.
Плюсы: будут подгружены все элементы модели, включая вложенные модули. Будет осуществлятся взаимодействие с самой моделью, а не фоновой ссылкой или 2д чертежами. Каждый владеет полной бим моделью.
Минусы: Не подходит для невнимательных, т.к. можно запустить тяжелейшую рекурсию. Не подходит для слабых компьютеров
Spoiler
MODный вариант
Ссылка на файлы с примером реализации
MODный вариант - способ создания вариантов путем вычленения изменяемой геометрии в отдельные .mod файлы, а затем подгрузки как связь.
Задача: В процессе разработки стадии П или ПП вам подкидывают идею/задание: "а давай это место попробуем сделать вот так". Получается, надо локально и быстро сделать другой вариант, при этом не запороть собранную модель и не перелопачивать всю структуру проекта.
Решение: Те части, которые необходимо заменить - выделяем, вырезаем и сохраняем как мод из буфера обмена, это будет исходный. Дублируем мод, называем как вариант и в нем уже его разрабатываем. В основную модель подгружаем/переключаем моды с вариантами
Плюсы: Легко для редактирования и понимания, т.к. используются самые простые базовые инструменты. Не утяжеляется модель. А после принятия какого-либо варианта можно просто взорвать мод и вернуть все элементы на место. Можно совмещать и комбинировать варианты разных частей проекта
Минусы: На переключение между вариантами уходит время
Spoiler
Вариант через фильтр реконструкции
Ссылка на файлы с примером реализации
Вариант в фильтре реконструкции - способ создания вариантов путем прикрепления элементов к конкретному фильтру реконструкции и отображения только в нем.
Задача: Такая же как в предыдущем. В процессе разработки стадии П или ПП вам подкидывают идею/задание "а давай это место попробуем сделать вот так". Получается надо локально и быстро сделать другой вариант, при этом не запороть собранную модель и не перелопачивать всю структуру проекта.
Решение: создаем фильтр реконстуркции "исходный вариант" и "вариант №…", скидываем все элементы, которые надо заменить на фильтр реконструкции "исходный вариант" или базовый, в котором разрабатывается основная модель. Для этого дела нам может пригодиться панель "Фильтры реконструкции". Варианты делаем с привязкой к фильтру конструкции "вариант №…."
Плюсы: быстрое переключение между вариантами; всё в одной модели
Минусы: утяжеление модели; невозможно комбинировать варианты разных частей проекта; сложно чистить, если в Teamwork и вариантов много; сложно архивировать варианты, т.к. надо сгружать модель полностью. Сложность также состоит в том, что если файл с вариантами нужно куда-то подгрузить как связь - то все фильтры реконструкции необходимо импортировать тоже
Spoiler
Ссылка на папку со всеми файлами с примерами на всякий случай
artem_larin
Это точно. Недавно познакомился с одним архитектором (который дома проектирует, а не ПО), и перед встречей прям предвкушал, как узнаю у него, до каких вершин развился язык паттернов, выявленный Кристофером Александером в современной архитектурной отрасли (краткая справка: его работы явились побудительным мотивом для создания софтверных паттернов GoF), но с удивлением узнал, что ни о каких паттернах и ни о каком Кристофере Александере в их бюро и не слыхивали.