Моделирование в КЖ арматуры и закладных деталей в 3D.
В BIM программах есть инструменты для автоматизации раскладки арматуры (армирование по площади или по линии), но по сравнению с традиционным черчением это более трудоемко. Так, например, чтобы указать армирование по площади в CAD, проектировщик размещал один блок "лужа" И подписывал марку. Сейчас же проектировщик размещает арматуру инструментом "армирование по площади", затем " взрывает" его и правит стержни вручную. Теперь проектировщик не может оставить арматуру как условную зону, она ведь появилась как элементы, и если раньше, то, с какой стороны начинать раскладку, а где разместить доборный стержень уходило на откуп строителю, то сейчас начинает об этом задумываться проектировщик (правда строитель все равно положит по-своему). К тому же в раскладке арматуры не учтены рабочие швы бетонирования, а в последнее время некоторые заказчики хотят и выполнять нахлест. В CADе массу фоновой арматуры считали от площади плиты (заливали штриховкой) и делили на шаг в каждом направлении. Все неточности такого подсчета нивелировались запасом, т.к. все понимали что на точные просчеты будет потрачено много ресурсов и времени и в итоге все равно по факту разложат по-другому, т.е. проектировщик не учел какой-то фактор.
Также в армировании в 3D приходится размещать узлы в каждое место, где он находится, тогда как прежде ставились условные кружки узлов и в случае если узел слегка отклоняется (например надо отогнуть один стержень по месту), то узел дополнительно не прорабатывали, а писали "по 21", или добавляли букву и непосредственно на одном узле указывали размер со звездочкой с примечанием, что справедливо для буквы или пунктиром чертили отогнутый стержень.
Т.е. существует проблема, что в 3D армировании надо проработать каждый элемент, да, не заново отрисовать, но как минимум прокликать, скопировать каркасы и узлы.
В армировании в 3D бывает такой подход, когда не армируют абсолютно все конструкции из однотипных, а по одному варианту и в стержнях указывают количество таких конструкций - это промежуточный вариант, между описанными выше, но он собирает и минусы и ошибки каждого (и заказчик, заказывая армирование в 3D, обычно не это хочет).
Устройство поддерживающих каркасов аналогично фоновой арматуре, тогда как прежде высчитывалось от площади, теперь - проектное решение проектировщика, на которое любой строитель скажет что " Я что буду каждую лягушку с линейкой по его чертежу расставлять? Дай мне шаг - я все расставлю как надо".
Таким образом появление дополнительной детализации привело к тому, что проектировщик выполняет дополнительные действия и задумывается о решениях, которые прежде ему не вменялись и которые строитель и не просит его принимать.
(продолжение следует)
В BIM программах есть инструменты для автоматизации раскладки арматуры (армирование по площади или по линии), но по сравнению с традиционным черчением это более трудоемко. Так, например, чтобы указать армирование по площади в CAD, проектировщик размещал один блок "лужа" И подписывал марку. Сейчас же проектировщик размещает арматуру инструментом "армирование по площади", затем " взрывает" его и правит стержни вручную. Теперь проектировщик не может оставить арматуру как условную зону, она ведь появилась как элементы, и если раньше, то, с какой стороны начинать раскладку, а где разместить доборный стержень уходило на откуп строителю, то сейчас начинает об этом задумываться проектировщик (правда строитель все равно положит по-своему). К тому же в раскладке арматуры не учтены рабочие швы бетонирования, а в последнее время некоторые заказчики хотят и выполнять нахлест. В CADе массу фоновой арматуры считали от площади плиты (заливали штриховкой) и делили на шаг в каждом направлении. Все неточности такого подсчета нивелировались запасом, т.к. все понимали что на точные просчеты будет потрачено много ресурсов и времени и в итоге все равно по факту разложат по-другому, т.е. проектировщик не учел какой-то фактор.
Также в армировании в 3D приходится размещать узлы в каждое место, где он находится, тогда как прежде ставились условные кружки узлов и в случае если узел слегка отклоняется (например надо отогнуть один стержень по месту), то узел дополнительно не прорабатывали, а писали "по 21", или добавляли букву и непосредственно на одном узле указывали размер со звездочкой с примечанием, что справедливо для буквы или пунктиром чертили отогнутый стержень.
Т.е. существует проблема, что в 3D армировании надо проработать каждый элемент, да, не заново отрисовать, но как минимум прокликать, скопировать каркасы и узлы.
В армировании в 3D бывает такой подход, когда не армируют абсолютно все конструкции из однотипных, а по одному варианту и в стержнях указывают количество таких конструкций - это промежуточный вариант, между описанными выше, но он собирает и минусы и ошибки каждого (и заказчик, заказывая армирование в 3D, обычно не это хочет).
Устройство поддерживающих каркасов аналогично фоновой арматуре, тогда как прежде высчитывалось от площади, теперь - проектное решение проектировщика, на которое любой строитель скажет что " Я что буду каждую лягушку с линейкой по его чертежу расставлять? Дай мне шаг - я все расставлю как надо".
Таким образом появление дополнительной детализации привело к тому, что проектировщик выполняет дополнительные действия и задумывается о решениях, которые прежде ему не вменялись и которые строитель и не просит его принимать.
(продолжение следует)
Вся эта точная раскладка арматуры обосновывается в первую очередь точными спецификациями. Но прежде считали от площади конструкции, количества узлов (сам в екселе сводил кол-во стержней на каждый узел на кол-во узлов), периметра отверстий и боковых граней. По стенам почти никто не делал развертки по каждой стене, а считали от длины стен умноженной на расчетную массу по узлу типовой раскладки на метр конструкции, либо отрисовывали один этаж, а дальше вычисленными коэффициентами от объема бетона.
Точная спецификация действительно обеспечивается с 3D арматурой и, возможно, вместо 3% запаса можно заложить 1%. И возможно в прежних подходах встречались случаи где отклонения по факту на одну конструкцию были больше, но - в одном больше, в другом меньше, и на крупном объекте все равно приходили в статистическую погрешность.
Но самое веселье с арматурой начинается тогда, когда надо что-то подправить, т.к. правится много элементов, параметрически завязанных друг на друга и по которым расставлены размеры на чертежах. Иногда проще всю арматуру в конструкции удалить и создать заново, переоформив чертеж. Т.е. трудоемкость и задержка сроков зачастую не разово встречается на проекте, а постоянно, т.к. проект постоянно меняется в большей или меньшей степени.
Сегодня появляется все больше инструментов для автоматической генерации арматуры, но пока они все не отработаны на практике, и иногда, правка сгенерированных элементов занимает больше времени, чем создание их с нуля. Т.е. в процессе работы встречается много случаев, не предусмотренных плагином, и на этих случаях приходится править или делать вручную. Но, со временем, плагины будут всё стабильнее работать и обрабатывать все больше случаев, таким образом повышая качество и ускорять работу по созданию 3D арматуры.
Точная спецификация действительно обеспечивается с 3D арматурой и, возможно, вместо 3% запаса можно заложить 1%. И возможно в прежних подходах встречались случаи где отклонения по факту на одну конструкцию были больше, но - в одном больше, в другом меньше, и на крупном объекте все равно приходили в статистическую погрешность.
Но самое веселье с арматурой начинается тогда, когда надо что-то подправить, т.к. правится много элементов, параметрически завязанных друг на друга и по которым расставлены размеры на чертежах. Иногда проще всю арматуру в конструкции удалить и создать заново, переоформив чертеж. Т.е. трудоемкость и задержка сроков зачастую не разово встречается на проекте, а постоянно, т.к. проект постоянно меняется в большей или меньшей степени.
Сегодня появляется все больше инструментов для автоматической генерации арматуры, но пока они все не отработаны на практике, и иногда, правка сгенерированных элементов занимает больше времени, чем создание их с нуля. Т.е. в процессе работы встречается много случаев, не предусмотренных плагином, и на этих случаях приходится править или делать вручную. Но, со временем, плагины будут всё стабильнее работать и обрабатывать все больше случаев, таким образом повышая качество и ускорять работу по созданию 3D арматуры.
Требуется ли моделировать подвесы для труб, воздуховодов и лотков?
Сперва опять вспомним, как их отображали в строительной документации последние 50 лет?
Типовое решение по подвесам отображалось лишь на отдельном чертеже узлов, их количество и расстановку нигде не отображали, а лишь высчитывали их общую массу от длины трубы и шага расстановки. Решения по расстановке подвесов оставалось за монтажником и принималось "по месту".
Сейчас же заказчик иногда хочет считать всё до копейки и хочет видеть все элементы которые входят в стоимость. Иногда к такой детализации приводит попытка привязать сметные расценки к модели, а чтобы привязать нужен элемент. Иногда за строительство крупного объекта берется тот, кто вчера себе делал ремонт в квартире, и он думает, что если он у себя крепежи считал, чтобы дважды в магазин не бегать и лишних не осталось, то и на стройке также (хотя понятно что там не одной поставкой делается и склады есть куда остатки можно отгрузить на другой объект, да и просто запасы заложены в стоимость и считать копейки себе дороже, т.к. теряешь на сроках и рисках ошибки. А монтажник все равно сделает по-своему - аргумент тот же что и с лягушками в КЖ).
Еще подвесы бывает нужны для таких руководителей проектов, кто напоролся на следующую ситуацию: проектировщики выполнили проект в паркинге "на пределе" по высоте просвета для проезда машины, но не учли, что замеряли высоту от грани трубы или воздуховода, а там еще есть выступающие части (стыки и подвесы) которые на 50мм уменьшили просвет. И на проекте возникли проблемы.
В такой ситуации надо не подвесы расставлять, а элемент на пересечение с которым проверяются системы (формообразующий, потолок, помещение или зона) делать на 50мм выше.
Трудоемкость расстановки подвесов вызвана тем же, что и другие описанные случаи: вручную долго кликать, плагином столько криво нагенерируется, что дольше править и проверять на задублированность. И самое затратное - не один раз создать, а постоянно править при корректировках (которые идут постоянно, и все думают, что: "ну вот эта точно последняя"), и проблем больше со сжатыми сроками, и подвесы править просто нет времени.
Сперва опять вспомним, как их отображали в строительной документации последние 50 лет?
Типовое решение по подвесам отображалось лишь на отдельном чертеже узлов, их количество и расстановку нигде не отображали, а лишь высчитывали их общую массу от длины трубы и шага расстановки. Решения по расстановке подвесов оставалось за монтажником и принималось "по месту".
Сейчас же заказчик иногда хочет считать всё до копейки и хочет видеть все элементы которые входят в стоимость. Иногда к такой детализации приводит попытка привязать сметные расценки к модели, а чтобы привязать нужен элемент. Иногда за строительство крупного объекта берется тот, кто вчера себе делал ремонт в квартире, и он думает, что если он у себя крепежи считал, чтобы дважды в магазин не бегать и лишних не осталось, то и на стройке также (хотя понятно что там не одной поставкой делается и склады есть куда остатки можно отгрузить на другой объект, да и просто запасы заложены в стоимость и считать копейки себе дороже, т.к. теряешь на сроках и рисках ошибки. А монтажник все равно сделает по-своему - аргумент тот же что и с лягушками в КЖ).
Еще подвесы бывает нужны для таких руководителей проектов, кто напоролся на следующую ситуацию: проектировщики выполнили проект в паркинге "на пределе" по высоте просвета для проезда машины, но не учли, что замеряли высоту от грани трубы или воздуховода, а там еще есть выступающие части (стыки и подвесы) которые на 50мм уменьшили просвет. И на проекте возникли проблемы.
В такой ситуации надо не подвесы расставлять, а элемент на пересечение с которым проверяются системы (формообразующий, потолок, помещение или зона) делать на 50мм выше.
Трудоемкость расстановки подвесов вызвана тем же, что и другие описанные случаи: вручную долго кликать, плагином столько криво нагенерируется, что дольше править и проверять на задублированность. И самое затратное - не один раз создать, а постоянно править при корректировках (которые идут постоянно, и все думают, что: "ну вот эта точно последняя"), и проблем больше со сжатыми сроками, и подвесы править просто нет времени.
Моделирование розеток, выключателей и светильников.
Посчитать количество приборов в каждом помещении удобнее по схемам. В сборняке размещение розеток, коробок и выключателей обязательно, т.к. выполняется на заводе. В наших проектах на стадии П нет планов с расстановкой розеток и выключателей, а только схемы.
Стоит отметить, что приборы ЭС и СС чаще монтируются в последнюю очередь и построенный проект по факту может сильно измениться. В то же время, перемещения электрики будут самыми долгими из всех инженерных систем если их двигать по каждому изменению в других разделах (т.к. они подстраиваются). И тут моделирование может загнать специалистов ЭС и СС в вечное рабство по правкам положения приборов.
Т.е. для экономии трудозатрат электриков следует понизить важность коллизий с их сетями, чтобы они не правили постоянно свои сети, а наносили в условном положении.
Таким образом, при обсуждении этого вопроса надо делить ситуации на стадии П и Р. А также по типу устройства - с закладными элементами и без.
На П не надо моделировать.
На Р в сборняке и где закладные под них - надо в точном положении.
На Р в других случаях - надо в условном положении.
Посчитать количество приборов в каждом помещении удобнее по схемам. В сборняке размещение розеток, коробок и выключателей обязательно, т.к. выполняется на заводе. В наших проектах на стадии П нет планов с расстановкой розеток и выключателей, а только схемы.
Стоит отметить, что приборы ЭС и СС чаще монтируются в последнюю очередь и построенный проект по факту может сильно измениться. В то же время, перемещения электрики будут самыми долгими из всех инженерных систем если их двигать по каждому изменению в других разделах (т.к. они подстраиваются). И тут моделирование может загнать специалистов ЭС и СС в вечное рабство по правкам положения приборов.
Т.е. для экономии трудозатрат электриков следует понизить важность коллизий с их сетями, чтобы они не правили постоянно свои сети, а наносили в условном положении.
Таким образом, при обсуждении этого вопроса надо делить ситуации на стадии П и Р. А также по типу устройства - с закладными элементами и без.
На П не надо моделировать.
На Р в сборняке и где закладные под них - надо в точном положении.
На Р в других случаях - надо в условном положении.
Поколения BIM
Считаю важным написать о лидерах, кто двигал BIM технологию в нашей стране в разное время. Напишу со своей колокольни и т.к. я все не видел, то могу ошибиться.
Я для себя выделяю 4 поколения BIM специалистов и BIM идеологов.
1 - Поколение САПРяжений. 2010-2014 года.
Когда BIM был еще не трендом и больше говорили про инструменты и холиварили ревит против архикад и против автокад.
Высоцкий, Макаров, Талапов, Чубрик, Борисов, Глуханюк, Бех, Осипов, Король, Канивец, Морозова, Новкович, Семин, Емельянов, Биктимиров, Зотов. Большинство открыли свои консалтинговые компании и зарабатывают на BIM-внедрениях деньги.
2 - Поколение BIM-стандарта. 2015-2017.Те, кто в компаниях учил массово сотрудников работе в BIM-программах и писал этот вечный BIM-стандарт, который никто не читал. Внедряли в работу проверки на коллизии, искали заказы для компании и вообще залезали во все внутренние процессы компании. Манин, Попов, Сумин, Зуев, Маркевич, Ерофеева, Яшанов, Лобанов, Землянская, Рогачев, Бойцов, Кураков, Дермейко, Бодрова, Веселов, Давыдов, Войтюк, Никитин, Сидоров, Цветков, Яременко, Бенклян, Мамаев.
3 - Поколение Dynamo. 2018-2019. Повсеместная автоматизация и программирование. Проектировать надо быстрее, быстрее. Кругом всех приходится убеждать что такая детализация нам не нужна, приходится всех притормаживать с их BIM-хотелками. BIM выходит на стройку, все учатся считать стоимости по модели и обсуждают когда уже экспертиза начнет принимать BIM-модели. Кривой, Канатов, Волков Сергей, Игнатович, Петрашев, Макаров Дмитрий, Агафонова, Косарев. Лапыгин, Бабинов, Лоцманов, Золотова, Трубина, Пулатова, Кушнир.
4 - Поколение Stepik. Я пока их не знаю.
В различные поколения раскидал по принципу кто оказывал на мой взгляд особое влияние на комьюнити в разное время. Т.е. никак не связано с возрастом или появлением на конференциях. Мог ошибиться, заходите поправляйте меня в @bimchat.
Считаю важным написать о лидерах, кто двигал BIM технологию в нашей стране в разное время. Напишу со своей колокольни и т.к. я все не видел, то могу ошибиться.
Я для себя выделяю 4 поколения BIM специалистов и BIM идеологов.
1 - Поколение САПРяжений. 2010-2014 года.
Когда BIM был еще не трендом и больше говорили про инструменты и холиварили ревит против архикад и против автокад.
Высоцкий, Макаров, Талапов, Чубрик, Борисов, Глуханюк, Бех, Осипов, Король, Канивец, Морозова, Новкович, Семин, Емельянов, Биктимиров, Зотов. Большинство открыли свои консалтинговые компании и зарабатывают на BIM-внедрениях деньги.
2 - Поколение BIM-стандарта. 2015-2017.Те, кто в компаниях учил массово сотрудников работе в BIM-программах и писал этот вечный BIM-стандарт, который никто не читал. Внедряли в работу проверки на коллизии, искали заказы для компании и вообще залезали во все внутренние процессы компании. Манин, Попов, Сумин, Зуев, Маркевич, Ерофеева, Яшанов, Лобанов, Землянская, Рогачев, Бойцов, Кураков, Дермейко, Бодрова, Веселов, Давыдов, Войтюк, Никитин, Сидоров, Цветков, Яременко, Бенклян, Мамаев.
3 - Поколение Dynamo. 2018-2019. Повсеместная автоматизация и программирование. Проектировать надо быстрее, быстрее. Кругом всех приходится убеждать что такая детализация нам не нужна, приходится всех притормаживать с их BIM-хотелками. BIM выходит на стройку, все учатся считать стоимости по модели и обсуждают когда уже экспертиза начнет принимать BIM-модели. Кривой, Канатов, Волков Сергей, Игнатович, Петрашев, Макаров Дмитрий, Агафонова, Косарев. Лапыгин, Бабинов, Лоцманов, Золотова, Трубина, Пулатова, Кушнир.
4 - Поколение Stepik. Я пока их не знаю.
В различные поколения раскидал по принципу кто оказывал на мой взгляд особое влияние на комьюнити в разное время. Т.е. никак не связано с возрастом или появлением на конференциях. Мог ошибиться, заходите поправляйте меня в @bimchat.
Моделирование фасадов.
Наружные стены в Revit можно моделировать несколькими способами: одной многослойной стеной, двумя стенами - несущий слой и пирог утеплителя с плиткой, тремя стенками - несущий, утеплитель и плитка с воздушным зазором. Многослойная стена удобна для быстрого редактирования, но когда появляются несущие конструкции из КР файла и лоджии, то приходится переходить на второй способ с 2 стенками. При таком подходе не совсем точно вычисляется объем утеплителя в углах, т.е. там происходит нахлест (на чертежах ревит объединяет штриховки, а в расчете объема нет) , примерно на 1-2% его получится больше в ведомости (в зависимости от сложности фасадов). Хотя, вспоминая как раньше считали (площадь штриховки умножить на толщину слоя), хочется сказать: кого это волнует?
При моделировании в два элемента, утеплитель тоже будет в нахлест. И тут добавляется проблема, что под окна надо проемы в газобетонных стенах предусматривать. Если наружные кладочные стены держать в одном файле с фасадами, то можно объединить стены, и с проемами будет попроще. Но чаще этот подход используется, когда фасад выносится в отдельный файл.
Заказчику модели может потребоваться создание тремя стенками для того, чтобы получить точный объем и иметь возможность визуализировать процесс устройства каждого из слоев. Проблем же добавляет такой подход прилично. Н-р по объединению фасадных стен в целях прорезания проемов, и по расстановке окон в правильный слой (обычно это утеплитель).
Подытожу:
На предпроекте и начале стадии П целесообразнее использовать подход с одной стеной.
На П, когда появляется конструктив, и фасад выносится в отдельный файл - двумя стенами.
На рабочке лучше использовать две стенки, но если заказчик требует три, и его не получается переубедить, то сразу делайте тремя. Потом много времени займет перемоделирование.
Наружные стены в Revit можно моделировать несколькими способами: одной многослойной стеной, двумя стенами - несущий слой и пирог утеплителя с плиткой, тремя стенками - несущий, утеплитель и плитка с воздушным зазором. Многослойная стена удобна для быстрого редактирования, но когда появляются несущие конструкции из КР файла и лоджии, то приходится переходить на второй способ с 2 стенками. При таком подходе не совсем точно вычисляется объем утеплителя в углах, т.е. там происходит нахлест (на чертежах ревит объединяет штриховки, а в расчете объема нет) , примерно на 1-2% его получится больше в ведомости (в зависимости от сложности фасадов). Хотя, вспоминая как раньше считали (площадь штриховки умножить на толщину слоя), хочется сказать: кого это волнует?
При моделировании в два элемента, утеплитель тоже будет в нахлест. И тут добавляется проблема, что под окна надо проемы в газобетонных стенах предусматривать. Если наружные кладочные стены держать в одном файле с фасадами, то можно объединить стены, и с проемами будет попроще. Но чаще этот подход используется, когда фасад выносится в отдельный файл.
Заказчику модели может потребоваться создание тремя стенками для того, чтобы получить точный объем и иметь возможность визуализировать процесс устройства каждого из слоев. Проблем же добавляет такой подход прилично. Н-р по объединению фасадных стен в целях прорезания проемов, и по расстановке окон в правильный слой (обычно это утеплитель).
Подытожу:
На предпроекте и начале стадии П целесообразнее использовать подход с одной стеной.
На П, когда появляется конструктив, и фасад выносится в отдельный файл - двумя стенами.
На рабочке лучше использовать две стенки, но если заказчик требует три, и его не получается переубедить, то сразу делайте тремя. Потом много времени займет перемоделирование.
В дополнение к моделированию фасадов.
Есть еще такая задачка, как отображение плитки на фасаде и подсчет количества.(речь пойдет о плитке менее 50х50см)
Есть несколько способов её отображения: витражами, частями, отдельными семействами, стенками с моделирующей штриховкой, 2D штриховками на фасадах, 2D семействами плиток на фасадах. Все эти способы позволяют и посчитать плитку, с большей или меньшей точностью (либо поштучно, либо: общая площадь деленная на площадь одной плитки).
Витражом получается достаточно тяжелая модель. Ее точно надо делать в отдельном файле и возможно сделать разве что один этаж 5 секционного жилого дома (больше - работать невозможно, все очень долго).
Частями и поэлементно - сложно наносить разрезку и расставлять, а при большом количестве элементов также виснет, как и витраж, т.ч. эти варианты хуже чем витраж.
2D элементами достаточно удобно, но не видно на модели (в Navisworks) и, на удивление, подвешивает файл при большом количестве элементов похлеще витражей (казалось бы с чего вдруг?).
Больше всего мне понравился вариант со стеночками с моделирующей штриховкой, т.е. чтобы отдельные зоны раскладки с одинаковой плиткой и направлением раскладки были одним элементом стены. Основная претензия к данному способу что плитка не штучно. На что я отвечаю: "50 лет от площади считали, а теперь не устраивает? От площади вычислите и запас накиньте". Т.е. я предлагаю относиться к плитке как к кирпичу и газобетону, которые мы не моделируем поштучно (как минимум на П и Р). Если производителям надо проработать детальнее, то пусть в своих отдельных файлах развлекаются.
Есть еще такая задачка, как отображение плитки на фасаде и подсчет количества.(речь пойдет о плитке менее 50х50см)
Есть несколько способов её отображения: витражами, частями, отдельными семействами, стенками с моделирующей штриховкой, 2D штриховками на фасадах, 2D семействами плиток на фасадах. Все эти способы позволяют и посчитать плитку, с большей или меньшей точностью (либо поштучно, либо: общая площадь деленная на площадь одной плитки).
Витражом получается достаточно тяжелая модель. Ее точно надо делать в отдельном файле и возможно сделать разве что один этаж 5 секционного жилого дома (больше - работать невозможно, все очень долго).
Частями и поэлементно - сложно наносить разрезку и расставлять, а при большом количестве элементов также виснет, как и витраж, т.ч. эти варианты хуже чем витраж.
2D элементами достаточно удобно, но не видно на модели (в Navisworks) и, на удивление, подвешивает файл при большом количестве элементов похлеще витражей (казалось бы с чего вдруг?).
Больше всего мне понравился вариант со стеночками с моделирующей штриховкой, т.е. чтобы отдельные зоны раскладки с одинаковой плиткой и направлением раскладки были одним элементом стены. Основная претензия к данному способу что плитка не штучно. На что я отвечаю: "50 лет от площади считали, а теперь не устраивает? От площади вычислите и запас накиньте". Т.е. я предлагаю относиться к плитке как к кирпичу и газобетону, которые мы не моделируем поштучно (как минимум на П и Р). Если производителям надо проработать детальнее, то пусть в своих отдельных файлах развлекаются.
На конференции Autodesk University 2019, которая пройдет 2 и 3 октября у нас будет Telegram BIM Community стенд! Подготовим конкурсы, призы, и интерактив с участием чатов. Будем держать вас в курсе и постить в каналы все самое интересное с мероприятия - интервью, фоточки. Поэтому добавляйтесь и не пропустите самое важное BIM-событие года.
@prostobim
@bimchat
@intlines_revit_chat
@bimwork
@bimsapr
@familyrevit
@PetrashevBIM
@Petrashev_API
@PetrashevBIM_HR
@stepik_bim
и самая главная группа мероприятия: @aurussia2019
@prostobim
@bimchat
@intlines_revit_chat
@bimwork
@bimsapr
@familyrevit
@PetrashevBIM
@Petrashev_API
@PetrashevBIM_HR
@stepik_bim
и самая главная группа мероприятия: @aurussia2019
LOD - уровень проработки модели. Набор требований, определяющий полноту проработки элемента информационной модели. Уровень проработки задает минимальный объем геометрических, пространственных и атрибутивных данных, необходимых для решения задач информационного моделирования.
Изначально появился, как уровень детализации, предназначенный для расчета стоимости проекта на разных этапах его реализации.
Описывает требования к различным LOD британский документ LOD Specification. bimforum.org/LOD
На русском есть статья Сергея Бенкляна: https://isicad.ru/ru/articles.php?article_num=17329
Термин также используется в BIM-стандарте Autodesk и СП333.1325800.2017 (п3.18 и прил. А). https://docs.cntd.ru/document/556793897
Если в двух словах, то основные LOD - это LOD300 и LOD400. LOD300 - это примерно проработка модели, которой достаточно, чтобы выпустить стадию П, LOD400 - это для Р.
Но само по себе вписывание этих букв в договор с проектировщиком не даст много результата, т.к. пока что не сформировалась единая практика трактования и понимания этих требований. Рекомендуется подготавливать Информационные требования заказчика, где более конкретно описывать что и как делать.
Проблема с трактовкой требований из СП заключается в том, что оттуда, для того, чтобы документ был вендоронезависимым, повычеркивали всю конкретику и требования стали "беззубыми", т.е. по ним не предъявить.
Изначально появился, как уровень детализации, предназначенный для расчета стоимости проекта на разных этапах его реализации.
Описывает требования к различным LOD британский документ LOD Specification. bimforum.org/LOD
На русском есть статья Сергея Бенкляна: https://isicad.ru/ru/articles.php?article_num=17329
Термин также используется в BIM-стандарте Autodesk и СП333.1325800.2017 (п3.18 и прил. А). https://docs.cntd.ru/document/556793897
Если в двух словах, то основные LOD - это LOD300 и LOD400. LOD300 - это примерно проработка модели, которой достаточно, чтобы выпустить стадию П, LOD400 - это для Р.
Но само по себе вписывание этих букв в договор с проектировщиком не даст много результата, т.к. пока что не сформировалась единая практика трактования и понимания этих требований. Рекомендуется подготавливать Информационные требования заказчика, где более конкретно описывать что и как делать.
Проблема с трактовкой требований из СП заключается в том, что оттуда, для того, чтобы документ был вендоронезависимым, повычеркивали всю конкретику и требования стали "беззубыми", т.е. по ним не предъявить.
С LOD300 все более менее понятно, но есть и один проблемный вопрос, что надо из модели иметь возможность получить объемы работ и материалов для расчета бюджета и проведения тендеров. Первоначальной концепцией графической части стадии П это не предусматривалось (она делалась для проверки экспертизой принципиальных решений). Соответственно прежде это не закладывалось в стоимость проектных работ. Прежде эту работу по калькуляции ВОР на бюджетных проектах выполнял сметчик, это даже описано в его обязанностях в методических рекомендациях по расчету стоимости проекта. Когда же с проектировщика начинают требовать объемы из модели, то он в лучшем случае выдает упрощенные спецификации со стадии Р или сформированные по ним в экселе (подобие ВОР). Но чаще всего он просто посылает, т.к. это не входит в договор и 87 постановление, но тут LOD пришел на помощь заказчику и он пытается через BIM-требования получить эти ВОРы, т.е. напрячь проектировщика на доп. работы (бесплатно конечно).
Для того чтобы этого не происходило, нужно всем однозначно понимать, чем вдруг BIM-проект стал отличаться от CAD-проекта. И еще раз повторюсь, что это психологическое изменение, т.е. чисто в восприятии, не обоснованное какими-то расчетами и научными выкладками - это происходит из-за того, что в BIM не все разбираются и появилась мутная вода, и все начали пытаться за счет нее перераспределить в свою пользу задачи и ответственность (а кто-то даже новую роль создает для зарабатывания денег).
Чтобы эту муть убрать, предлагаю смотреть на BIM-проект также, как и CAD, но лишь с условием, что та же информация должна быть получена из модели. Любая информация или виды отображения сверх - это доп. затраты.
К таким затратам на LOD300 можно отнести классификацию модели и нарезку ее на пакеты работ, создание сводной модели и проверка ее на коллизии (с устранением коллизий).
Для того чтобы этого не происходило, нужно всем однозначно понимать, чем вдруг BIM-проект стал отличаться от CAD-проекта. И еще раз повторюсь, что это психологическое изменение, т.е. чисто в восприятии, не обоснованное какими-то расчетами и научными выкладками - это происходит из-за того, что в BIM не все разбираются и появилась мутная вода, и все начали пытаться за счет нее перераспределить в свою пользу задачи и ответственность (а кто-то даже новую роль создает для зарабатывания денег).
Чтобы эту муть убрать, предлагаю смотреть на BIM-проект также, как и CAD, но лишь с условием, что та же информация должна быть получена из модели. Любая информация или виды отображения сверх - это доп. затраты.
К таким затратам на LOD300 можно отнести классификацию модели и нарезку ее на пакеты работ, создание сводной модели и проверка ее на коллизии (с устранением коллизий).
👍1
Здесь следует и проектировщику попытаться объяснить, почему заказчик по максимуму задач пытается скинуть на него, а сам ничего не может сделать.
В BIM появляется такой термин: держатель модели - это тот на чьей стороне сейчас редактируемая актуальная модель.
Для примера возьму ворд-документ. Если его правят одновременно два человека, то потом потребуется в один из них вносить правки другого. Но, если в ворде есть режим правки, который чуть упрощает задачу, то в BIM-программах пока нет такого режима.
В итоге, в определенный момент времени, есть лишь один пользователь, кто правит документ, потому все накидывают ему пожелания что подправить, также и с моделью - есть одна компания кто в данный момент на своем сервере правит актуальную модель, т.к. если заказчик параллельно поправит свою модель, то при получении новой версии модели (ИЗМов), ему придется повторять свои действия, а поправить ночью и передать на следующий день проектировщику - подменить рабочую модель, не получится, т.к. он не может гарантировать что не потеряет свою информацию (специалистов то много, и вдруг кто ночью работал, всех не опросишь так быстро) и будет опасаться, что заказчик что-то подправил, т.е. проектировщик не сможет отвечать за результат своей работы (что все решения реально его).
Все эти ограничения конечно связаны с устаревающей формой передачи данных - файлами, и так не будет вечно, скоро и в BIM появятся свои гугл-документы, которые будут позволять редактировать документы совместно online, с подробной записью истории действий каждого из участников.
В BIM появляется такой термин: держатель модели - это тот на чьей стороне сейчас редактируемая актуальная модель.
Для примера возьму ворд-документ. Если его правят одновременно два человека, то потом потребуется в один из них вносить правки другого. Но, если в ворде есть режим правки, который чуть упрощает задачу, то в BIM-программах пока нет такого режима.
В итоге, в определенный момент времени, есть лишь один пользователь, кто правит документ, потому все накидывают ему пожелания что подправить, также и с моделью - есть одна компания кто в данный момент на своем сервере правит актуальную модель, т.к. если заказчик параллельно поправит свою модель, то при получении новой версии модели (ИЗМов), ему придется повторять свои действия, а поправить ночью и передать на следующий день проектировщику - подменить рабочую модель, не получится, т.к. он не может гарантировать что не потеряет свою информацию (специалистов то много, и вдруг кто ночью работал, всех не опросишь так быстро) и будет опасаться, что заказчик что-то подправил, т.е. проектировщик не сможет отвечать за результат своей работы (что все решения реально его).
Все эти ограничения конечно связаны с устаревающей формой передачи данных - файлами, и так не будет вечно, скоро и в BIM появятся свои гугл-документы, которые будут позволять редактировать документы совместно online, с подробной записью истории действий каждого из участников.
В LOD400 основные вопросы заказчика касаются детализации. Заказчик хочет закладные, поддерживающие каркасы и арматуру в КЖ, болты и сварные швы в КМ, подвесы и крепления в ОВ и ВК, навесные фасадные системы и профиль в гипсокартоне в АР.
Все эти вещи раньше прорабатывались проектировщиком на чертеже типовых узлов и не расставлялись по объекту в проектное положение, в спецификации высчитывались удельно от количества мест или длины элемента основы.
Т.е. проектировщику требуется выполнять больше действий при создании информации и ее редактировании. Чисто теоретически BIM позволяет автоматизировать эти процессы для достижения прежней скорости выпуска документации, даже с такими лишними действиями, но пока эти инструменты не настолько автоматизированы и повышенная детализация занимает больше времени (процентов на 20).
Еще одна проблема повышенной детализации LOD400, что даже если дадут больше времени на нее, то не все специалисты умеют ее выполнять (н-р армировать в 3D). И тут мы сталкиваемся с немасштабируемостью технологии из-за ее сложности, как итог - срыв сроков и откат в автокад.
В результате длительных наблюдений могу сделать вывод, что строительная отрасль и проектировщики у нас в стране (подозреваю что и в мире) не готовы к разработке ИМ LOD400 с рабочей документацией (на более менее крупном объекте), в связи с чем рекомендовал бы пока не гнаться за идеалом, а попробовать реализовать менее детализированный BIM, но с которым могут справиться наши проектировщики, и даже больше - они хотели бы с ним работать. Назовем этот уровень - LOD350.
А уровень BIM можно назвать BIM Level 2.5 по диаграмме Бью и Ричардса. В этом уровне повышенная детализация по Информационным требованиям заказчика будет отменена и везде прописано требование к ИМ стадии Р - LOD350.
Данный уровень проработки экономически более целесообразен и позволяет применять модель на строительной площадке с минимальными для заказчика затратами и рисками.
Когда инструменты станут более автоматизированными и все проектировщики и строители научатся и отработают 2.5, то можно будет рассмотреть уровень 2.6, где будет и LOD400 (и арматура в 3D и фасадные системы).
Все эти вещи раньше прорабатывались проектировщиком на чертеже типовых узлов и не расставлялись по объекту в проектное положение, в спецификации высчитывались удельно от количества мест или длины элемента основы.
Т.е. проектировщику требуется выполнять больше действий при создании информации и ее редактировании. Чисто теоретически BIM позволяет автоматизировать эти процессы для достижения прежней скорости выпуска документации, даже с такими лишними действиями, но пока эти инструменты не настолько автоматизированы и повышенная детализация занимает больше времени (процентов на 20).
Еще одна проблема повышенной детализации LOD400, что даже если дадут больше времени на нее, то не все специалисты умеют ее выполнять (н-р армировать в 3D). И тут мы сталкиваемся с немасштабируемостью технологии из-за ее сложности, как итог - срыв сроков и откат в автокад.
В результате длительных наблюдений могу сделать вывод, что строительная отрасль и проектировщики у нас в стране (подозреваю что и в мире) не готовы к разработке ИМ LOD400 с рабочей документацией (на более менее крупном объекте), в связи с чем рекомендовал бы пока не гнаться за идеалом, а попробовать реализовать менее детализированный BIM, но с которым могут справиться наши проектировщики, и даже больше - они хотели бы с ним работать. Назовем этот уровень - LOD350.
А уровень BIM можно назвать BIM Level 2.5 по диаграмме Бью и Ричардса. В этом уровне повышенная детализация по Информационным требованиям заказчика будет отменена и везде прописано требование к ИМ стадии Р - LOD350.
Данный уровень проработки экономически более целесообразен и позволяет применять модель на строительной площадке с минимальными для заказчика затратами и рисками.
Когда инструменты станут более автоматизированными и все проектировщики и строители научатся и отработают 2.5, то можно будет рассмотреть уровень 2.6, где будет и LOD400 (и арматура в 3D и фасадные системы).
2 октября на стенде telegram bim community AUR2019 я буду проверять ваши модели и считать по ним объемы работ с помощью Navisworks.
Приносите свои модели на флэшке в формате NWD - лучшим будут призы и мои плагины на Navisworks.
Модели будут после проверки сразу при вас удаляться с компьютера.
Дополнительно напомню в день AU в @bimchat и @aurussia2019 т.ч. заходите к нам и ничего не пропустите.
Приносите свои модели на флэшке в формате NWD - лучшим будут призы и мои плагины на Navisworks.
Модели будут после проверки сразу при вас удаляться с компьютера.
Дополнительно напомню в день AU в @bimchat и @aurussia2019 т.ч. заходите к нам и ничего не пропустите.
Есть и более фундаментальная проблема моделирования в LOD400 - производительность программного обеспечения. Текущие мощности персональных компьютеров не позволяют в режиме онлайн пересчитывать положение всех элементов модели и проверять их на изменения от зависимых (хорошие примеры - инструменты ревит копирование/мониторинг, группы и армирование с extensions, которые напрочь грузят модель).
Я предполагаю, что после нескольких лет попыток аутодеском оптимизации ревита 15-16-17-18 (вспомните - каждый был более быстрым) и попытки реализации многопоточности через фоновые процессы, можно подвести итог, что в текущих технологиях, онлайн редактирование столь детализированных моделей, с таким большим количеством взаимосвязей, невозможно.
Если кто-то думает, что программисты - волшебники, и могут нарушить любые законы физики, мол "просто ревит на старом ядре, мол одноядерный", то посмотрите куда пропал запал в производительности своей программы у разработчиков ренги. Она уже виснет и трещит по швам, а не дошла и до 10% функционала ревита.
Тут требуется мощность облачных суперкомпьютеров или новых процессоров на квантовых вычислениях. И то и то с высокой долей вероятности будет браузерным.
На практике, проблемы производительности решаются дроблением модели на части, и работой с ними по отдельности (что также добавляет неудобств, особенно в местах на стыках частей)
Я предполагаю, что после нескольких лет попыток аутодеском оптимизации ревита 15-16-17-18 (вспомните - каждый был более быстрым) и попытки реализации многопоточности через фоновые процессы, можно подвести итог, что в текущих технологиях, онлайн редактирование столь детализированных моделей, с таким большим количеством взаимосвязей, невозможно.
Если кто-то думает, что программисты - волшебники, и могут нарушить любые законы физики, мол "просто ревит на старом ядре, мол одноядерный", то посмотрите куда пропал запал в производительности своей программы у разработчиков ренги. Она уже виснет и трещит по швам, а не дошла и до 10% функционала ревита.
Тут требуется мощность облачных суперкомпьютеров или новых процессоров на квантовых вычислениях. И то и то с высокой долей вероятности будет браузерным.
На практике, проблемы производительности решаются дроблением модели на части, и работой с ними по отдельности (что также добавляет неудобств, особенно в местах на стыках частей)
Forwarded from Ivan Zylev | INT LINES | BIMCORE
Друзья!
1-3 октября состоится Autodesk University 2019.
Если вы идете на конференцию, то я и другие основатели чатов будем вас ждать на нашем стенде Telegram bim community)
Будет приятно увидеть каждого пообщаться. Давайте сделаем наш стенд точной сбора участников конференции из этого и других чатов. Просто подходите как уведите плакат, который я прикрепил к этому сообщению) Можно будет пообщаться вживую с другими участниками чата, задать свои вопросы про Revit Bim и т.д.
Если вы участвуете в AU19 в качестве докладчика то можете рассказать о своем выступлении в чате.
1-3 октября состоится Autodesk University 2019.
Если вы идете на конференцию, то я и другие основатели чатов будем вас ждать на нашем стенде Telegram bim community)
Будет приятно увидеть каждого пообщаться. Давайте сделаем наш стенд точной сбора участников конференции из этого и других чатов. Просто подходите как уведите плакат, который я прикрепил к этому сообщению) Можно будет пообщаться вживую с другими участниками чата, задать свои вопросы про Revit Bim и т.д.
Если вы участвуете в AU19 в качестве докладчика то можете рассказать о своем выступлении в чате.
Краткая выжимка программы Autodesk University 2019.
1 октября - день проектировщика
2 зала - здания и инфраструктура. (Revit vs Civil3D)
В зданиях
10:00-11:30 - конструктив
12:00-13:30 - инженерка
14:00-15:30 - рабочие наборы, менеджер семейств и refinery
16:00-17:30 - плагин отделки, классификатор, Revit API.
В инфрастракче
10:00-11:30 - BIM-топосъемка и ЖД в Dynamo
12:00-13:30 - Civil3D для дорог и геологии
14:00-15:30 - Inventor, Infraworks и еще геологии
16:00-17:30 - Добавят Revit и реновации.
А подробнее: https://gems.autodesk.com/events/au-russia-2019/agenda-8fe749d76ab24225985fb212a161803b.aspx
1 октября - день проектировщика
2 зала - здания и инфраструктура. (Revit vs Civil3D)
В зданиях
10:00-11:30 - конструктив
12:00-13:30 - инженерка
14:00-15:30 - рабочие наборы, менеджер семейств и refinery
16:00-17:30 - плагин отделки, классификатор, Revit API.
В инфрастракче
10:00-11:30 - BIM-топосъемка и ЖД в Dynamo
12:00-13:30 - Civil3D для дорог и геологии
14:00-15:30 - Inventor, Infraworks и еще геологии
16:00-17:30 - Добавят Revit и реновации.
А подробнее: https://gems.autodesk.com/events/au-russia-2019/agenda-8fe749d76ab24225985fb212a161803b.aspx
Autodesk
AU Russia 2019
AU Russia 2019 — это мероприятие, совмещающее оффлайн-общение и широкие возможности онлайн. Трехдневная конференция пройдет в Московской Школе Управления СКОЛКОВО.
2 октября - много залов, везде не успеть, потому выбор Попова:
10:00-12:00 - Конгресс-холл - Шоу и главные доклады от Autodesk
13:00-14:30 - зал Москва - BIM-монитор, нейронка считает сметы и классификатор в Navisworks.
14:50-16:20 - зал Москва - проверка моделей и подсчет объемов
16:40-18:10 - зал Сингапур - лазерное сканирование и компьютерное зрение.
Из интересных:
14:00-14:30 - Сингапур - BIM-операторы
14:30-15:00 - Сингапур - КС2, КС3 из модели
15:20-15:50 - Сингапур - практика BIM с девелоперами
10:00-12:00 - Конгресс-холл - Шоу и главные доклады от Autodesk
13:00-14:30 - зал Москва - BIM-монитор, нейронка считает сметы и классификатор в Navisworks.
14:50-16:20 - зал Москва - проверка моделей и подсчет объемов
16:40-18:10 - зал Сингапур - лазерное сканирование и компьютерное зрение.
Из интересных:
14:00-14:30 - Сингапур - BIM-операторы
14:30-15:00 - Сингапур - КС2, КС3 из модели
15:20-15:50 - Сингапур - практика BIM с девелоперами
Более детальный анализ от Попова по приоритетам: https://docs.google.com/spreadsheets/d/1MYhgAJssErnDNg2p8uhSGgoqpmrZnPMZXS-uaqjfPXE/edit?usp=sharing
Опубликован отчет исследования по BIM проведенного Конкуратор и МГСУ. Полный отчет высылается по почте (бесплатно). А основные результаты я свел на одну картинку. https://concurator.ru/information/bim_report_2019/