Давайте порассуждаем? Статья для тех, кто только начинает знакомиться с дивным и новым BIM-миром, и тот, кто давно уже набил шишки. А вот и наши темы:
- Потребности пользователей при проверке на коллизии. Требования к ПО
- Декомпозиция матрицы коллизий. Все за и против
- +100500 коллизий. Как не уйти в депрессию или в другую сферу, например, IT :)
- Допущения, стоит ли их учитывать, когда и какие?
Кстати, за мной замечено раздвоение личности, поэтому буду говорить, как от лица Проектировщика, так и Заказчика. Ой, всё страшнее: ещё и комменты от лица разработчика ПО.
LET'S GO!
Наши потребности
И тут, конечно же, мне вспоминается пирамида Маслоу, я тоже выделила для себя выделила пять ступенек к дзену.
А какие тезисы можно выделить в рамках нашего контекста?
Гарантированный поиск всех коллизий
Начнем сначала. Что же фундамент всего?
Неоспоримый базовый, жизненно необходимый пункт - каждый из нас должен быть уверен, что найдены все коллизии, ну или хотя бы геометрические. А вообще ещё бывают нормативные, но об этом в следующей статье.
В чем проблема, если есть ПО, в котором настраиваешь проверки, а оно само находит всё. А вот есть нюансы, всё не так-то просто, и, как всегда, без человека не обойтись.
Если вы работали в Navisworks, вам известны два типа проверок:
- по пересечению
- по пересечению (консервативно)
В чем разница? Первая проверка учитывает только те элементы, которые пересекаются гранями. А если элемент полностью находится внутри другого (но не дублируется), то она не подходит, и как раз-таки для этого и нужна консервативная проверка. Хоть и название ассоциируется со стабильностью, порядком.. казалось бы, можно выбирать её всегда и не париться, но как всегда есть "но". Данная проверка находит большое количество ложных пересечений, поэтому применяем только там, где это актуально, если говорим в контексте Nаvisworks или ищем ПО, в котором не нужно об этом думать. XD
Что ещё служит гарантией?
Обязательно нужно проверять перед каждой (хотя даже я так не делаю, а вы?) корректно ли собраны наборы, все элементы учтены
Как говорится, сколько людей столько и мнений, столько и реализаций моделей, наименований, категорий моделирования. Поэтому если вы работает в службе Заказчика не мечтайте, что вы один раз поработали, создав EIR, шаблоны проверок и дальше можно забыть про этот пункт. На каждом проекте всегда всплывает что-то новенькое.
Например, у меня однажды в проверке полы-стены вылезли полотенцесушители, т.к. набор фильтровался по: Имя содержит "Пол". Ну так-то да. Да, на количество коллизий может и не влияет, но явно разные приоритеты коллизий.
Соответственно, требование, возникающее, как must have, в функционале ПО: визуализация именно финального фильтра для набора А и Б, с учетом допущений, исключений. А чтобы проще проверять наборы, должна быть матричная структура создания проверок на коллизии: меняем итоговый фильтр для одного набора, меняется везде, где он есть.
Прервем тему по потребностям, остановимся подробнее на матрице и перейдем ко второму пункту моей пирамиды.
Матрица коллизий
Я уже упоминала приоритеты при отработке коллизий, так вот это основная причина, зачем делать декомпозицию матрицы. Вторая- простота аналитики на начальном этапе, хоть и строчек с проверками больше, зато коллизий в каждой разумное (если повезет) число.
Проверяем не модель на модель, а делаем выборки
Например, проверка стены ж/б с окнами и дверьми сразу говорит о несоответствии проемов АР и КР и явно относится к высокому приоритету. А проверка стены АР- перекрытия КР, ну явно ниже: тут либо высота этажа поменялась, а привязки были некорректные, либо просто локальная коллизия, да влияет на объемы, но можно поправить попозже, когда, например, точно утвердят отметки чистого пола.
Ещё одна причина декомпозиции: учет всех допущений, чтобы лишнее не вылезало, как коллизия, и проще было анализировать, а то получится, как список желаний у Марфушеньки- душеньки, а хотелось бы, как у Настеньки)
Допущения
Тоже сложно подойти к вопросу универсально. Но вот мои топ-5 для жилья. Пишите ваши допущения в комменты. Интересно послушать на кейсы для линейных объектов.
Требования МГЭ
А теперь вопрос на дискуссию: в требованиях МГЭ (актуальная ссылочка на них тут) проверяется проверка модель на модель. И как её пройти?)
К слову о допущениях, они там есть:
- Линейный допуск 80 мм (щедро)
- Не учитывать изоляцию для труб менее 50 мм
Ну, на самом деле, мой 3 пункт спорный, вы исключаете или нет?) Решение МГЭ в общем-то неплохое. Но требует, опять же, доп. функционала в ПО для проверок: возможности группировать коллизии по диаметру трубопроводов, участвующих в пересечках.
Да, в Navisworks, есть, но больно, не правда ли?
А теперь плавно перетекаю во вторую ступень наших потребностей после слов "вроде есть, а вроде нет".
Размер коллизии
На картинке выше про консервативную проверку и обычную подсвечена проблема привычного нам ПО.
Важно получать точный размер коллизии и, в идеале, считать объем коллизии, чтобы:
- Настраивать допуски
- Приоритезировать по объему (от большего к меньшему), получать инфо по объемам
Например, если есть такая метрика, моно проверить объемы земляных масс за счет просмотра объема пересечений собственно
- Проверять просвет между сетями, например
На самом деле, возможность проверять соблюдение минимальных расстояний -это великая автоматизация. Согласитесь, чтобы проверить это визуально даже в 3д, уйдет уйма времени.
Группировка коллизий
Как решить кейс: исключить пересечки с трубами диаметром менее 50 мм?
ПО должно обладать функционалом группировок коллизий, позволяющие назначить фиктивный статус и ен выгружать такие коллизии в отчет.
А дальше вопрос:
А если там пучок труб маленького диаметра? Тогда так просто и нельзя исключить коллизии с трубами D< 50 мм, требуется визуальный анализ
Двунаправленная связь окна визуализации и перечня пересечений
Сказ от NastenkaBimCake
Николай Гаврилович - почетный проектировщик, гений инженерной мысли, но вот отработка коллизий огорчает его. Давайте представим ситуацию, когда Николай Гаврилович получил список +100500 коллизий и встал вопрос: ЧТО ДЕЛАТЬ?
Несмотря на то, что мы разделили модель на модель, учли допущения, все равно коллизий много, чтобы работать с плоским списком пересечек. Я, когда работала в Navisworks, всегда группировала все конфликту в одку папку, чтобы посмотреть общую картину, а потом уже делала пользовательские группировки.
Согласитесь, работать в 3д намного удобнее. Поэтому ПО всё-таки должно обладать связкой с перечнем, чтобы назначать статусы, комментарии на коллизии прямо в окне визуализации.
Например, найти пучки из труб малого диаметра и поменять у них статус с фиктивной коллизии на высокий приоритет.
Промежуточные итоги
И так, мы молодцы, потому что
- Декомпозировали матрицу коллизий, выбрали приоритеты
- Убедились, что наборы собраны корректно
- Проверили модель и нашли все коллизии
- Проанализировали коллизии
- Отсеяли то, что допускается
- Выгрузили удобный отчет с нужными параметрами
И передали эту прелесть Проектировщику. Всё равно грустно, согласитесь? Искать по ID уже не модно!
Новый тренд Larix+Citrus [BIM]
Данные разработчики сделали палочку-выручалочку, которая позволяет выгрузить отчет о коллизиях (как геометрических, так и нормативных) в эксель из Larix.Manager, открыть его в интерфейсе Revit и подрезать вид под коллизию.
Ну какова красота!
PS Если вы пишете плагины на отечественный софт, напишите, пожалуйста
То есть последняя ступень: быстро найти коллизию в модели.
Главные итоги
Да, это всего 5 потребностей, их гораздо больше. Но надо ведь с чего-то начинать.
Давайте будем внимательны и осуществлять предварительный контроль наборов
Давайте будем проверять не только геометрические, но и нормативные коллизии
Давайте уменьшать (законно) список коллизий за счет допущений и предварительной аналики
Давайте экономить время друг друга!
А чтобы потестировать все вышеописанное в Larix.Manager, пиши мне в тг @NastenkaBimCake