Первая серия статей в режиме коллаборации начата!
Соавтор данного материала — Заур Дауров, мой коллега и друг.
Введение
Зачастую Заказчик прописывает в EIR только очевидные правила, влияющие на реализацию проектных решений в BIM, подсчёт объемов и т.д...а потом получает:
- Чай успевает остыть за время открытия модели;
- Скорость отклика на различные команды оставляет желать лучшего;
- Ошибки при запуске скриптов;
- Дублирование параметров и неспособность воспользоваться шаблонными спецификациями.
Для того чтобы не столкнуться с такими проблемами далее расскажу, что на что следует обращать при создании семейств, моделировании, параметризации и координации проекта, а также рассмотрим пару примеров.
Что проверяем?
- Отсутствие импортированной геометрии в проектах (импорт DWG) и семействах (например, из 3Ds Max);
- Корректность координат, в частности положения внутреннего начала;
- Вес файла и семейств;
- Отсутствие загружаемых семейств с назначенными системными категориями (стены/перекрытия);
- Соответствие параметров ФОП по EIR.
Далее на примерах более подробно разберем взаимосвязь между особыми методами моделирования, непротиворечащими EIR, и возможностью управлять данными из модели.
Проверки семейств
Зависимость категорий моделирования от бизнес-процессов
1) Чтобы элемент не только попадал в расчет, но и корректно производились вычисления, требуется прописать в EIR категории моделирования для каждого элемента в зависимости от того, как выстроен производственный процесс, формируются сметы, ведутся закупки и осуществляется поставка материалов на строительный объект.
Не всегда самый быстрый способ моделирования позволяет получить необходимые метрики. EIR должен однозначно указывать на способ моделирования, указывать исключения и допущения, если они влияют на получение точных показателей: шт, м2, м3, м.п….
Примером могут служить зашивки из вертикальных и горизонтальных листов гипрока на направляющих, реализованные одним семейством с назначенной категорией "Стены". Соответственно мы получаем загружаемое семейство с системной категорией Стены. И вроде бы всё логично и хорошо, пока мы не проверим сам расчет и площадь листов.
В таком случае важно проверять все системные параметры, например, площадь. Поскольку она рассчитывается, как сумма площадей всех поверхностей, в т.ч. боковых граней стен, что противоречит обычному пониманию площади поверхности стены...площадиплощадиплощади....Извиняюсь за повтор, зато доходчиво вышло).
Один из ярких примеров, показывающий, что должен ограничивать EIR- это использование несистемных стен и перекрытий.
Детализация семейств
2)Не только в проекте важно проверять отсутствие импортированной геометрии, но и в семействах.
Важно находить баланс между детализацией элементов и работоспособностью модели.
Например, семейство приточного оконного клапана. Графика и детализация данного элемента в модели роли не играет, мне, как Заказчику, важно:
- Посчитать их количество, отдельно от стеновых клапанов;
- Извлечь информацию о его производителе (не визуально, а из параметра);
- Делить окна по наличию фрезеровки в зависимости от того, замоделирован клапан или нет;
- Сохранить нормальную производительность модели.
В обоих вариантах (рис. 1,2) элемент замоделирован отдельным элементом в модели ОВ, на него отдельно назначается классификатор, указывается производитель, без проблем считается количество элементов.
Следствие: проблемы автоматизации
Разница заключается в последующей работе с моделью, когда требуется для смет из модели получить количество окон с фрезеровкой под клапан и без. Создавать новые типы окон для архитекторов нерационально, тк в проекте могут быть оба типа окон. Да и зачем это делать вручную по заданию из модели ОВ, когда можно автоматизировать процесс: добавить параметр экземпляра, который будет заполняться в зависимости от наличия пересечения окна (модель АР) и клапана (связь ОВ),при правильном его моделировании. Визуальная проверка неизбежна.
При запуске скрипта в модели, где семейство клапана содержит импортированную геометрию (рис.3 ) скрипт не отрабатывает, выдавая ошибку:
После замены импортированной геометрии семейства на примитивную прямоугольную форму скрипт отработал без ошибок.
Как правильно создать семейство?
3) Не только отсутствие импортированной графики помогает оптимизировать вес семейства, но множество других моментов. Перечислю основные:
- Уменьшение вложенности семейств, их графической детализации;
- Реализация УГО не через 3Д геометрию, а области маскировки и аннотационные 2д линии;
- Управляйте видимостью семейства: на плане лучше не отображать геометрию, а прочертить её символическими линиями и показывать только их;
- Чем меньше формул, массивов и полой геометрии, тем лучше;
- Используйте каталоги вместо создания большого количества типоразмеров внутри семейства;
- Удаляйте неиспользуемое: материалы, штриховки, типы и стили линий, параметры.
Как ни удивительно, это уже давно не секрет и прописано в официальном руководстве по созданию семейств, есть куча статей на эту тему…Но
Рекомендую в EIR ссылаться на данное руководство, как основной регламент по созданию семейств, если у вас нет собственного.
Помимо проверки отдельных компонентов, также следует анализировать саму модель в целом по схеме, описанной в следующей главе.
Проверки модели
Мини чек-лист
- В первую очередь в EIR требуется ограничить вес файла. Для жилья, на мой взгляд, оптимально 400 Мб.
- Во избежание захламления файла (переноса типов линий и штриховок из AutoCAD) все DWG загружаются в проект связью, а не через импорт сапр.
- Проверяем параметры на соответствие файлу общих параметров во избежание последующего их дублирования. Параметры должны совпадать не только по имени, но и по GUID. Ответ, как проверять.
И последний пункт, хотя именно это сподвигло к написанию статьи.
Координация моделей
- Проверка координат, которая включает в себя:
- Внутреннее начало, базовая точка файлов одной секции, но разных разделов должны совпадать;
- Координация производится по общим координатам;
- Базовая точка проекта должна совпадать с пересечением первых осей проекта (например, осей А и 1) и по высоте располагать в 0.000 чистого пола;
- Если не заданы координаты ГП точка съемка располагается в 0.000;
- Визуальная проверка сводной модели.
Последний пункт является недостаточным для того, чтобы утверждать, что координация выполнена верно. Даже если мы открываем Navisworks/Revit, где казалось бы все на своих местах, важно проверить в первую очередь 1 пункт.
Проблемы автоматизации из-за ошибок координации
Можно привести пример (рис. 4) пренебрежения пунктом 1, ориентируясь только на пункт 5 – используем для примера все те же воздушные клапана и фрезерованные окна, описанные ранее.
Разработанный скрипт для автоматической проверки воздушного клапана и окна с фрезеровкой строит для каждого из этих объектов по максимальной и минимальной точке геометрии пространственные кубики (BoundingBox). Строит он эти самые точки максимума и минимума относительно внутреннего начала [4] каждого из файлов моделей – АР и ОВ.
Следовательно, моделируя и ориентируя каждую из моделей по-своему относительно внутреннего начала и базовой точки, игнорируя требования EIR, мы получаем серьезную проблему в работе данного скрипта - пространственные кубики для клапанов и окон строятся в разных направлениях (рис. 5), следовательно, никакой корректной проверки на пересечения этих двух объектов не будет.
И как результат, он вроде есть, а смысла в нем мало. Рекомендую прописывать координаты БТ, ТС на старте моделирования и согласовывать с Заказчиком.
Резюмирую
Помимо того, что из модели должны корректно выгружаться объемы, нужно анализировать, что и как влияет на работоспособность модели, а также не игнорировать общепринятые правила моделирования, создания семейств.
Перечень ссылок
- Статья Дарьи Бабаевой про дублирование параметров