что такое Revit для конструктора и стройки

             Все мы читали рекламные проспекты Autodesk , все мы читали про технологию BIM , все мы читали про то как все хорошо и удобно , главное приобрести подписки , пройти обучение и .......... все будет хорошо. Я в принципе то же так думал до момента пока не увидел это и в принципе все стало уже ясно, того чего я ожидал не увижу никогда. После этих статей :
http://revitconsalting.blogspot.ru/2016/01/revit-python.html
http://revitconsalting.blogspot.ru/2016/01/autodesk-bim.html
http://revitconsalting.blogspot.ru/2016/01/revit.html
на меня вылили много грязи  и чего только не говорили за спиной , и какие только теории не выдумывали. В этой статье я решил пойти по порядку, по пунктам и затронуть  все что касается Revit и конструкторской документации. Этой информации мало на просторах интернета так как не так уж и много людей которые  занимаются этим многие годы. Уж петь дифирамбы я точно не стану , этой информации хватает.

ОБНОВЛЕНО 26.07.17, кому интересно альтернативное решение Revit, смотри ссылку .


              Не так давно мне рассказали одну интересную историю, потом еще одну потом еще одну.   Но я передам текст одной. Не хочу очернять сообщество автодеск но тем не менее люди начинают делать ошибки которые влекут серьезные последствия. Есть такой славный город Тольятти. Когда то этот город был городом донором. Но в силу кризиса существующие промышленные площадки стали менее эффективнее чем ранее. И в силу развитой промышленности у города была нужда в интеллектуальных кадрах. Такими кадрами выступили отчасти проектные организации. И вот в одной из них руководство решило внедрить Revit. Наняли человека из сообщества. Кого наняли говорить не буду. Он пообещал что через пару месяцев все перейдут. Прошло 2 месяца , ничего не произошло, а стало намного хуже и все запутаннее. Прошло еще несколько месяцев , руководство поссорилось с человеком кто обучал и внедрял но при этом уволили почти всех кто "плохо" обучался за это время. И как итог внедрение не произошло. Люди кто обучают начинают делать большие ошибки вселяя уверенность людям в том чего нету в Revit.
              Большинство рассуждений о BIM в общей сложности теоретические , почему ? потому что мало кто реализует их на практике или мало у кого удается это сделать. А кто реализует у тех возникает очень много претензий, так как все тайное становиться явным. Теперь давайте разберемся так кто виноват , "не желание людей учится" или "хромой BIM от Autodesk" на конкретных нюансах работы конструкторов в Revit.

1. Армирование по площади

           До  2012 версии этот инструмент обладал только функцией подсчета объема арматуры и выделить разные диаметры из этого инструмента было невозможно. В 2013 версии нам дали такую возможность с помощью того что мы могли уже увидеть категорию несущей арматуры. Но в течении 3 лет позиция арматуры по площади и входящей в нее несущей арматуры не имеют ничего общего в итоге функциональность данного инструмента не используется по полной.

 

            Прошло 4 года но единой информационной моделью тут и не пахнет. Я конечно знаю как это исправить при помощи API но вот людям только севших за Revit нельзя с ходу объяснить почему этого решения нету из "коробки".

2. Пересечение арматуры

             Люди которые только берутся за освоение Revit , часто жалуются что нету логики при определении Revit-ом пересечения несущей арматуры друг с другом. Иногда (очень часто и намного чаще чем хотелось бы) даже несущая арматура не может быть сдвинута так как Revit определяет ,что это край несущей конструкции и далее расположен защитный слой , хотя до края конструкции еще метров 20, но оказывается что он видит защитный слой смежной конструкции которая расположена в другом краю здания на расстоянии 150 метров. Из за области видимости (точнее ее ограниченности в видимости) не видно этой конструкции и можно долго гадать что же сделать что бы сдвинуть арматуру на 20 мм. А при насыщенном армировании могут быть и такие моменты :

      И такие моменты встречаются сразу когда начинается многослойное армирование. Бороться с ними можно одним способом , переопределить основу арматуры:

      Но и тут грабли , при копировании арматуры Revit не находит основу и удаляет новые экземпляры несущей арматуры:

        В итоге приходится чертить арматуру опять в старой основе и опять переносить. Но тогда отпадает логика использовать данные параметры:

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

3. Производительность графики при работе с арматурой  

Давайте посмотрим что нам говорит справка по новым возможностям Revit 2016:

• Rebar display performance: To improve performance so that views open and update faster, Revit regenerates reinforcement only for what is visible on the screen. In addition, if reinforcement appears very small on the screen, it is displayed as simplified lines, regardless of the detail level assigned to the view.

                    Что в переводе означает, повышение производительности графики при просмотре арматуры. По факту отличия 2009-2016 версии, в плане производительности при работе с армированием , нет и похоже не будет. Самое интересное что когда менеджеры Autodesk приходят и рассказывают как все хорошо то они так же , прочитав рекламный проспект, обманывают инженеров и архитекторов. А обновление модели при переключении видов стало (чуть чуть ) быстрее из за отмены ограничения на использования памяти RAM в 2015 версии. Причем представители Autodesk лично обещали что в 2016 версии мы увидим новое графическое ядро.

             В итоге работать с такими моделями в Revit на уровне рабочей документации не просто сложно, а почти невозможно и банально неудобно :

 

               На таких объектах просмотреть сразу хотя бы несколько уровней невозможно.

                Единственное где работает данное нововведение это конструкции с армированием без загибов, просто прямые стержни на виртуальных объектах для красивой картинки  :

           В таких конструкциях есть небольшой прирост производительности, но реальные объекты содержат сотни тысяч различных форм арматуры с загибами, без этого невозможно обойтись ни одной реальной стройке:










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











 

4. Сборный ЖБ

              Как бы не печально это звучало  но выполнить более менее автоматизированный труд в Revit в сборном ЖБ задача не просто сложная но и не реализуемая с точки зрения информационного моделирования. Сама концепция сборного ЖБ подразумевает три критерия:
1. Унификация
2. Стандартизация
3. Типизация
            Начнем с унификации - единообразия. Тут нареканий нету. Можно унифицировать любую линию производства ,любых изделий. Проблемы начнутся со стандартизацией. Стандартизация и унификация не реализована никак. Во всех более продвинутых аналогах Revit (TS или Precast) реализованная технология автонумеровния , определения типов , классов и тд. В Revit есть только одна , это "сборки":

 

                   

             Есть два способа выполнить сборный ЖБ:

1. Семейство

2. Разбиение системных семейств на детали 

             Первый способ может удовлетворить все три пункта , но трудоемкость создания семейств просто ставит крест на этом способе, создать свой стандарт и потом его проецировать на любые потребности невозможно , нету гибкости, нету концепции совместной работы и вообще это не BIM, а просто конструктор LEGO:

 

 

Ну и если выполнить сборку можно получить следующие виды:


Второй способ через детали :


               У этого способа есть как свои преимущества так и ровно то что его использовать из"коробки" невозможно в рабочем проектировании, те же изменения внести почти невозможно. Сама архитектура Revit не распознает узлы элементов (только аналитическая модель) а это основное когда мы говорим про сборный железобетон. По этому поводу будет отдельная статья и демонстрация возможностей моего приложения, BIM Killer не спит :).

              Есть еще третий способ но из-за того что у компании Autodesk нету BIM решений связка Revit-Inventor лежит мертвым грузом, так как даже банального единого стандарта информации так же нету (а это основа BIM ):

5. BIM стандарт для Revit

           Многие создают такого рода  документ для проектных организаций не понимая, что они делают. Я не кого не хочу учить жить, но увы это стоит озвучить. Это тяжелая тема для понимания новичков и очень спорная для профессионалов. 

          Что такое стандарт предприятия я думаю ни для кого, не секрет. Это свод правил работы в данной организации. Но когда мы говорим про Revit мы в первую очередь смотрим в рекламу от Autodesk где под Revit мы понимаем BIM технологии. Но как и ранее я уже говорил тут стоит провести жирную черту. Никакого BIM тут нету . Это обычное трехмерное проектирование не связанное со стройкой и каким либо жизненным циклом здания. Дело в том что в жизненном цикле участвуют следующие подразделения:

- дизайнеры

- архитекторы

-конструкторы

-инжиниринг

-сметчики
-авторский надзор

-экономический отдел

-плановый отдел

-снабжение

-производственно технический отдел

-департамент строительства 

-производство

-эксплуатация

             И это не самый большой список. BIM стандарт должен отражать пожелания всех участников этого процесса. Но если столкнутся с этим процессом на прямую то сразу возникнут вопросы на первых уровнях данного списка. Первые люди кто работает с моделью это дизайнеры/архитекторы и экономисты и они оценивают примерную стоимость объекта. У экономистов и сметчиков фигурирует такое понятие как сборники ТЕР или ФЕР или ГЕСН и тд. Если мы говорим про частный капитал то такого рода сборники заменены на свой собственный аналог.Но везде примерно одна и та же структура данных. Она многоуровневая. Первый уровень это по аналогии название категории семейства. Второй уровень это название типа семейства , третий это экземпляр типа , четвертый это конкретный элемент экземпляра типа. Вроде бы все понятно и логично. Но вот тут и начинается проблема . Даже если только взять Revit то его структура не логична , она не может быть использована как база для базы данных других приложений.

               Начнем с того что в 2016 версии в Revit API  конструктор отвечающий за принадлежность типу семейства работает не во всех семействах. Мы можем найти только первый уровень и третий. Для того что бы найти тип семейства нам придется писать алгоритмы которые будут перебирать всю существующую информацию в модели. Но и тут Revit нам ставит подножку , у разных семейств не может называться один и тот же тип одинаково:

          То есть в Revit не может быть один и тот же тип в разных категориях семейств с одинаковым названием . Но при этом стандартная библиотека семейств оперирует большим количеством таких типов. Но как уже все догадались Autodesk ленятся что либо менять в лучшую сторону и они дописали ключевые слова в названии   :
-Двутавр АСТО 20-93 Колона
-Двутавр АСТО 20-93 Балка
           С первого взгляда ничего особенного но это концептуальная ошибка тянется многие годы и решать ее .........и на этой ошибке построить полноценный КМ или КМД почти невозможно.
           Из за этого проблемы со всеми задачами в шапке блога.
          Сама проблема отраслевого стандарта существует во всем мире. Только вот компания Autodesk занимается обманом глобального масштаба. Большинство конкурентов идут маленькими но уверенными шагами и пока что не замахиваются на такие громкие слова как совместная работа. Все идут так или иначе и метод проб и ошибок составляют и дополняют стандарт. И если взять основного конкурента  Tekla Structures то тут все вполне ясно , стандарт вшит в саму программу , вам дают лишь в "узких местах" добавлять свои параметры к модели. То же касается и Bentley то же касается и Allplan. В данный момент даже я на своем примере вижу что я не могу выложить ни одного приложения пока не создам всю цепочку данных от одной задачи в другую, все время переписываю параметры , переделываю связки ,переделываю семейства и каждая новая задача вносит свои корректировки и в шаблон самого проекта  Revit так и в BIM стандарт. И меня удивляет появление стандартов оторванных от реальности.Я лично уже понял что если все продумать то я получу Tekla или Precast только на базе Revit.
          Наверное все видели стр. 16 данного документа . Но кто задавался вопросом реализации данной схемы ? она ни где не реализована. И как можно верить в то что не реализовано ?
          Еще одна из основных проблем Revit это его сильная сторона. Его сильная сторона является и его слабой стороной. Вместо того чтобы разрабатывать связующие параметры между семействами и налаживать концепцию сквозной параметризации Autodesk увел revit в сторону отсутствия этих связей и параметризации только в рамках одного семейства. Без знания программирования невозможно передавать параметры от одного семейства другому.
           Вся линейка Autodesk которая касается BIM имеет свой собственный стандарт и набор переменных. В итоге нету единой логики между программным обеспечением. И по логике Autodesk эти все приложения свяжут пользователи посредством графического программирования и в частности Dynamo.
            Ну и как итог этого пункта моих мыслей и опыта, это формирование сводной спецификации на объект, ни одно из решений Autodesk не позволяет это сделать даже на процент.

6. Графическое программирование  

              Обрушившаяся на меня критика со стороны многих людей из сообщества Autodesk я думаю для меня пойдет на благо, а точнее каждый сам сделает вывод о адекватности суждений каждого участника. В следующих строках ни слова не скажу хороших или плохих сторон о графическом программировании, для этого процитирую людей из сообщества Python. А для этого я создал соответствующую тему на русско язычном и англоязычном форумах. В обсуждении приняло много людей из различных инженерных областей и не только . Вот основные цитаты:

Не знаю как сейчас, а во времена моей юности были популярны радиоконструкторы: наборы готовых радиокомпонентов, которые можно было легко соединять между собой и получать простые функционирующие цепи. Для школьников старших классов весьма занятная штука, для человека профессионально занимающегося радиоэлектроникой - просто игрушка, несмотря на то, что теоретически на элементах радиоконструктора можно собрать сколь угодно сложную схему. Это как бы аналогия. А если ближе к теме, то задумайтесь вот над каким вопросом: ну ладно, хорошо, нарисовали мы в каком-то специальном редакторе нашу программу - набор связанных какими-то отношениями блоков, что дальше то?
А дальше эту схему во-первых надо как-то сохранить на диск, а во-вторых как-то выполнить. В любом случае вы придете к какому-то формальному языку, который графически представляется этой схемой. То есть фактически вы получите своеобразную IDE. То есть можно взять любой язык программирования и сделать для него ИДЕ, которая будет транслировать блок-схемы в слова и операторы этого языка. Задача вообще-то не сложная, это гораздо проще, чем разобрать программу в синтаксическое дерево. Возвращаясь к нашей аналогии, внутри кубиков конструктора таки настоящие транзисторы и конденсаторы, и, разумеется, специалисту кубики как посредник не нужны.
Резюме: полезность сего околонулевая.


 Если ваша “платформа граффического программирования” позволит решать задачи той же сложности, что и язык программирования, то почему вы решили, что она в целом будет проще, чем язык программирования?
Если сложность двух подходов сопоставима, то разумно выбирать более универсальный вариант. Программу на питоне я могу прям сейчас написать используя штатные средства операционной системы, например редактор vim.

Будучи радиолюбителем - могу присоединиться к метафоре и добавить от себя
Полезность - не нулевая! Она отрицательная.
Да можно открыть програмку и натыкать мышкой по картинкам…
Натыкал а оно не заработало - как? Почему? Как найти причину? По цвету кубиков или названию?
Чему научится человек играя с кубиками?
Давайте абстрагируемся от сложной аналогии и перейдем к азам - сначала ребенка учат алфавиту и правилам работы с буквами по непревзойденному мануалу “Букварь”.
Почле чего дабы развивать процесс игровым стилем дают придурковатые кубики из которых ребенок строит домик по форме а не по буквам…
Тут точно также
Подобные темы неоднократно обсудались на форуме радиолюбителей по программированию микроконтроллеров. Я сам даже создал видеокурс по программированию АВР для чайников… так вот приходили люди которые писали в студии где уже были кубики… через две недели кидали ето УГ - садились за обычную IDE и через 2 недели достигали уровня осознания того что кубики х//ня

1 Как правильно заметили граф язык тоже язык. Т.Е. язык нужен в любом случае. Кто говорит что его нет просто шарлатан.
2. Граф язык декларируют как более простой по сравнению с классическими. Это так, но за счет снижения его возможностей. Если в обычных ЯП оставить только арифметические действия его тоже будет просто изучить.
Важна адекватность языка и предметной области. Возьмите Симулинк, или систему моделирования электрических схем. Перерисовать схему с листочка проще чем написать программу. Тыкать виртуальным осциллографом также как реальным проще чем сделать в питоне import pylab as plt;plt.plot(x,y,“+-” );plt.show(). Если надо сравнить пару цифр, то тогда есть смысл делать это в граф оболочке.
Однако у меня не выжила ни одна графическая модель. После отрисовки надо подобрать рабочую точку, проверить устойчивость, оптимизировать режимы, из субд элементов подобрать наиболее дешевые, но позволяющие решить задачу и т.п. Граф язык в виде блок схем либо не позволяет выразить такие абстракции либо это намного сложнее чем на питоне или другом ЯП. Однако это другая задача, для нее возьмите Wolfram Mathematica. Эти задачи там решаются легко. Причем интерфейс практически тоже графический - можно “рисовать” красивые дифференциальные уравнения, работать с формулами, НО он адекватен другой предметной области.
По факту сейчас студенты мучаются. В симулинке рисуют модель управляемого объекта (6-8 дифуров). Дальше цепляют транслятор, который из этого делает код для заливки в stm32. Цепляют к регулятору, проверяют качество регулирования (в железе). Работают полтора месяца. Тот-же код на гольном C был бы 10 строчек для модели и 30 строчек для регулятора, максимум пару часов работы. Но ответ прост, мы на C не умеем писать :) Про оптимизацию вообще говорить не приходится.
Т.е. знать граф языки полезно, но знать ЯП общего назначения еще полезнее. Будущее не за граф языками, а за языками приспособленными для предметной области. Сомневаюсь что граф языки смогут заметно потеснить классические языки в ближайшие 10 лет. Нужно и то и то.

Когда я еще только начинал изучать UML, а это было очень и очень давно ему пророчили альтернативу всем языкам. Причем пророчили в “ближайшем обозримом будущем”. Что, мол, используя UML вы вскоре сможете наяривать полноценные программные продукты. Но вот только “воз и ныне там”. Ничего хорошего из этого, естественно, не вышло. Потому как описать все языковые абстракции просто иногда слишком сложно. Мало того, много случаев, когда это не сопоставимо по трудовым затратам. Поэтому ни о каких “заменах” речи быть не может. Только как альтернатива для совсем уже простых проектов.
P.S. Основными задачами UML все же стали проектирование и описание, но никак не замена. Поэтому про “будущее графических языков” мы слышали и не раз

Как вы будете пользователю показывать различие версий и редактировать конфликты? Вы же понимаете, что три строки кода могут изменить блок-схему до неузнаваемости. 


На самом деле при разработке систем автоматики и теплогидравлических сетей задание данных в виде схем очень распространено. Более того, кодогенерация из схемы кода на c/asm рекомендуется всякими ИСО-МЭК.
Изнутри графическая работа выглядит так.
Десятки человеко-лет тратятся на разработку всяких diff и граф редакторов. Непрерывно многие десятки людей ведут работы преобразованию отработанных решений из одного проекта в другой. Люди перерисовывают схемы в новом стиле, переобозначают коннекторы и т.п. В рамках одного проекта генерация новых версий идет с темпом обновление раз в две недели - месяц. Это требует сравнения десятков тысяч чертежей. git, diff и прочее практически не используется, поскольку часть данных в схемах часть в оракле часть исполнитель даст только за деньги. Поэтому на сравнение все забивают, поскольку это неподъемная задача. Зачастую это приводит к тому что ошибки проекта гуляют кругами между организациями несколько лет.
Отдельная отрасль - распознавание схем и конвертация их в вид пригодный для других систем. Это работает, но оставляет за собой тоже кучу ручной работы.
Особенно абсурдно выглядят автоматчики. Современная элементная база в корне изменилась. Однако люди все равно рисуют регуляторы и управляющие системы на аналоговых элементах, которых и близко нет в реальной аппаратуре. Потом привлекают сложнейшую математику, и программное обеспечение, чтобы перевести это в код (например С), который будет выполняться микроконтроллерами. Потом борятся с эффектами дискретизации. И вся эта свистопляска вместо того чтобы в несколько строчек кода получить цифровые данные, решив пару уравнений получить оптимальное воздействие, и спокойно его выдать.
Из статьи про дракон “Это обстоятельство ставит непреодолимый барьер для непрограммистов, то есть специалистов, работа которых связана с алгоритмами, но которые не имеют резерва времени, чтобы научиться выражать свои профессиональные знания в форме алгоритмов и программ”. Это абсурд. Профи в алгоритмах не может найти пару недель на то чтобы выучить язык? Может и матанализ надо перестать изучать на первом кусрсе, а то сложно больно?
Сама идея визуального программирования (именно программирования) к настоящему времени, по моему мнению нанесла такой вред, что ее можно приравнять к патологическому пристрастию к компьютерным играм. В вузах пора читать лекции о вреде визуального программирования, а компании которые рекламируют этот подход возможно надо преследовать в законодательном порядке, за распространение технологий противоречащих научной организации труда.

           Со всей темой обсуждения можно ознакомится по ссылке там много чего интересного обсуждалось. Каждый сам делает для себя вывод. Но я думаю не стоит вестись на рекламные проспекты.

7. Металлические конструкции 

          Если размышлять сугубо в рамках КМ то в принципе все возможно , без особых проблем. Но как только немного в сторону детализации узлов то тут все печально. Например если сложная реконструкция с металлом и кучей различных незамысловатых узлов. Автоматизировать узлы почти невозможно , каждый узел новое семейство.

          Например один из моих проектов (так как очень старый могу сказать что и где) , реконструкция 2013 года ЖК "Имперский дом":

 

Опять же этот объект :

  

            Выполнить такого рода сложную конструкцию в металле в Revit можно сказать невозможно, окончательную схему собрал в специализированном ПО для КМД:

 

 

     
               Если говорить про простой металл и несложные реконструкции, то тут все осуществляется обычными семействами как в конструкторе LEGO:

 

              Но даже если взять обычные каркасники то и тут особо Revit ни чем не выигрывает, проще и быстрее делать их в спец ПО (Tekla или AS), так как все же металл это не только КМ для проектировщика это и информация для всех звеньев в цепи :

или такие не типовые вещи :

 

           P.S. Довелось видеть картину как академику из области авиаконструирования объясняли что такое BIM , картина маслом , разговор был закончен фразой "долго объясняете". Любая задача должна иметь явное решение, большое количество неявных решений пользы не несет. Очень наглядным пособием по технологии BIM является тестовый пример при первом запуске Revit. Я без слез на это смотреть не могу. Но не стоит думать что я против Revit, напротив , во многих задачах у него есть свои преимущества , поэтому следует внимательно читать между строк при выборе ПО решая конкретные задачи. Большинство разработчиков приукрашивают картину но то что делает Autodesk уже не поддается никакой критике.