понедельник, 15 февраля 2016 г.

что такое 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 уже не поддается никакой критике.

30 комментариев:

  1. Спасибо за наглядные аналогии из жизни.
    Критику, почему-то люди не любят. Но если не смотреть на мир критично - его не сделать лучше. Поэтому делайте. Просто делайте своё дело лучше других :) Это и будет вашим главным аргументом....
    -
    Что касается обсуждения Dynamo на форумах python'a. Это не совсем честно. Там конечно-же специалисты на порядок выше. И конечно-же развиваясь внутри динамы люди, возможно, однажды её покинут перейдя полностью на питон (а возможно и нет).
    -
    НО ведь среди питонщиков есть очень понимающие люди которые не ополчаясь, но грамотно сравненивают динамовцев с "кружком радиолюбителей". И ничего стыдного, на мой взгляд, в этом нет.
    -
    Ни один инженер в мире не является профи в программировании, они профи в других областях. Так почему же динама не может занять своё скромное место в таком разнообразном и пёстром мире став инструментом а не объектом критики или поклонения?

    ОтветитьУдалить
  2. Самый лучший способ критиковать - предлагать альтернативу. Иначе критика превращается в банальный спор с набором мнений но без набора решений. Очень жаль что говоря "ревит не может" вы не говорите например "текла может".. Ведь вы специалист.. Но если вы молчите - значит текла тоже "не может" и возможно софт вашей мечты только в ваших мечтах. Так как же вы его реализуете в реальность если будете воевать?
    -
    Между строк я прочел главное: Нужно знать как можно больше софта, чтобы можно было оппонировать без предвзятости.

    ОтветитьУдалить
  3. Дима я не критиковал ,а просто указал "недочеты", про них почему то никто не пишет как будто их и нету вовсе.

    По поводу альтернативных решений.....вот тебе пример....допустим я скажу что я изобрел машину времени.....другой человек сказал что я вру и у меня нету машины времени ...... какую альтернативу должен привести человек назвавший меня лжецом ? если что то работает плохо то это нужно озвучить что бы человек не питал иллюзий по этому поводу. Но даже если взять альтернативу то конструктив из крупных застройщиков в РФ никто похоже не использует и угадай почему :) а так ГК МОРТОН - Tekla, Allplan Precast, а тот же ГК ПИК - Briscad пишут дополнения на Autolisp, все наши конкуренты в альт софтах под ERP. Хотя нет, кто в монолите ,такие как Urban Group в Revit сидят. И я по большей части не критикую а пишу что не так работает, расценивать это как "побочные действия" у лекарств.

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

    ОтветитьУдалить
    Ответы
    1. Эти ребята с питона и ексель считают бесполезной безделушкой.

      МОРТОН ревит тоже использует, недавно писал на изикаде где-то в комментах главный конструктор.

      Удалить
    2. https://www.youtube.com/watch?v=BgbfUuXftGI

      Удалить
    3. Про ПИК, не совсем так. Там и revit и AutoCAD, и хорошие inhouse программы, как под revit, так и под cad. Просто там есть разделение задач, и нет стремления все реализовать на одной платформе. Служба САПР в ПИК - реалисты, и работают с тем что есть, выжимая максимум.

      Удалить
    4. мне кажется, Михаил, сползая на личности, уж точно проблемы не решить. и мне кажется нужно быть выше того кто и что о вас думает.
      -
      "по большей части не критикую а пишу что не так работает"
      Вас понял.. ну что ж... хотя бы так.. тоже своего рода исследование.. многие и на это не способны. спасибо.

      Удалить
    5. Михаил, сами же понимаете какая она замечательная эта текла, как там всё просто и идеально.

      Хотелось бы такие статьи видеть на форме автодеска, на английском) может и действительно было с пользой. А так...

      Удалить
  4. Этот комментарий был удален автором.

    ОтветитьУдалить
    Ответы
    1. Наверно Вы большой человек, чтобы взять все и «обобщить»:)

      Удалить
    2. Кажется, тут было что-то интересное, но я всё пропустил!

      Удалить
    3. Александр Попов высказал мнение:
      "А по поводу статьи... маленький человек громко пукнул"
      Я даже издеваться над этим не буду но человек с такой громкой фамилией и такой фразой вызывает улыбку )

      Удалить
  5. С озвученными организационными проблемами в основном согласен. По технической части:
    Маркой и обозначением арматуры по площади не пользуюсь - такую "зону раскладки" можно сделать через "Аннотацию для арматурных стержней" - будет и шаг, и стрелочки, и количество, и позиция арматуры.
    С ненужной параметризацией арматуры можно бороться, собирая арматуру в группы. "Редактор зависимостей" в 2016 стал куда более удобен и тоже помогает решить такие вопросы.
    "Метка основы", действительно, бесполезный инструмент (обычно указываю принадлежность вручную, это не так сложно).
    Производительность при работе с насыщенными моделями - спорный вопрос: почему-то на одном железе и с одним объектом нормально крутятся файлы по гигабайт с сотнями тысячи объектов, а в другой ситуации - тормозит уже что-то совсем простое. В любом случае, деление на связанные файлы никто не отменял.
    Графическое программирование позволяет мне решать простые задачи без погружения в API и прочее, если это тупиковый путь - пусть, я не собираюсь далеко в него погружаться.
    КМ - база узлов и соответствующий инструмент должны появиться в 2017 (правда, пока непонятно, насколько это будет смехотворно). Если не говорить о детальном моделировании узлов - в той же винтовой лестнице не вижу проблем.

    ОтветитьУдалить
  6. Я может устарел за месяц а что за за новые фишки с КМ ? можно ссылочку ?

    ОтветитьУдалить
  7. В revit 2016 R2 можно связать параметры в разных семействах между собой при помощи глобальных параметров.

    ОтветитьУдалить
  8. я знаю , это константа, она для других целей , а нужен сквозной параметр , например выбрали окно , набрали в марке ОК-1, а в несущей балке автоматически выскочило ОК-1, выбрали новое окно и набрали ОК-2 и в несущей колонне выскочило ОК-2. Если мы говорим про глобальные параметры то на каждый чих нужно создать параметр , их будут тысячи

    ОтветитьУдалить
  9. Сама идея визуального программирования (именно программирования) к настоящему времени, по моему мнению нанесла такой вред, что ее можно приравнять к патологическому пристрастию к компьютерным играм.

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

    ОтветитьУдалить
    Ответы
    1. А вы, Альберт, хоть одну пользу принесли в виде блога или видео своим неграфическим программированием?

      Удалить
    2. Нет конечно, люди вокруг поумнее меня, я только учусь. Если такие, как я, будут учить - вот это будет вред))

      Удалить
    3. мда... давно слежу за темой динамопитоноподобных навесок к ревиту. Что сказать, да, есть огромное желание уметь использовать динамо или питон, но... нет никакого желания их изучать, по крайней мере пока (когда это делать многодетному отцу?))). Большинство проектировщиков, кто сел за ревит, на сегодня пытаются переделать шаблон автокадовского мышления, ох и не просто это дается...
      Понятно одно - для полноценной работы проектировщик должен научиться двум вещам: освоить сам интерфейс программы, программировать... так? Зачем ПГСнику уметь программировать? С другой стороны, что теперь ждать "все в контейнере" в 2017 версии, не дождаться, затем понадеяться на 2018?

      Удалить
  10. По поводу плюсов и минусов, достоинств и недостатков Revita. Возможно дело в завышенных ожиданиях. Возможно дело в отсутствии понимания чего именно от него хотели на том предприятии в Тольятти. Я думаю, если бы ревит был так уж плох, а автодеск такие уж обманщики, то они бы не имели такого успеха.
    В силу обстоятельств, сейчас я смотрю на ревит не как конструктор, а как главный конструктор и по совместительству координатор. Пока что очень доволен и я, и коллектив.
    Идеального софта не видел. И не увижу. И всем не угодишь. И все задачи предусмотреть вряд ли возможно. Ревит хотя бы оставляет пути для решения незаурядных задач.

    ОтветитьУдалить
    Ответы
    1. И то верно. Да многие текловцы, получше познакомившись с ревитом, признают его плюсы в сравнении с теклой. Нет ничего идеального.

      Удалить
  11. А как вам появление комплекта с Revit, Advance Steel и Naviworks, который называют почему-то Fabrication?

    ОтветитьУдалить
  12. Этот комментарий был удален администратором блога.

    ОтветитьУдалить
  13. Работаю в Allplan (довольно уверенно как сам себя оцениваю) в Revit 2012 когда-то успел замоделировать здание, но заниматься им не получилось по независимым причинам. Рядом др. чел (с большим опытом работы в Allplan, я бы сказал знает и делал в нем все, что предлагают инструменты этой проги) работает в Precast.
    Что тут сказать и в Allplan и как ни странно в Precast есть огромные минусы :(
    Я бы даже сказал то, что в Revit реализовано с одним знаком (например с минусом), в Allplan тоже самое имеет противоположный знак. Например:
    1) Производительность. Allplan, в целом, шустрее (сравниваю с Revit 2012) возможно раза в 2-4 (если модель с армированием, то опять, возможно! еще больше). Даже на старом компе (Core-i2, 2011 г.в.) можно более менее работать и армировать. На компе с Core-i5, 6Гб оперативы, видюха самая обычная (не для 3D типа квадры): вполне терпимо можно подключать одновременно 5 этажей (40*40 м, архитектурная основа для Precast: стены разбиты на сбор. панели, без закладных, перекрытие цельное с отверстиями). Если сразу все 20 эт. (для фасада) - жду 10 мин., после загрузки модель спокойно крутиться вертится (практически без тормозов). Но любое редактирование (например, в плане редактирую: перемещаю, копирую, удаляю стены всех этажей) приводит к задержке иногда в 1 мин. Включенное армирование мало влияет на тормознутость (во вскяком случае, не на столько критично, как в Revit).
    2) «Умные объекты». Семействам Revit (большой плюс данной проги) в Allplan соответствуют смарт-объекты (смарты), создаются исключительно писанием текста. Т.е. создание семейства в 99% случаев происходит в 10-ки раз быстрее, чем создание аналогичного смарта (вам как удобней по сотовому общаться или смс-ки азбукой морзе писать?:). Логическая взаимосвязь объектов, такая как в Revit (геометрия одного влияет на геометрию и положение др.) в Allplan отсутствует в принципе как класс (если не считать армирование), что на сегодня считаю одним из главных бичей этой проги.
    3) Оформление рабочих чертежей все же удобней в Allplan (рядом с 3D-моделью здания можно, например, расположить несколько разрезов/видов, узлов, вставить непечат. рамку листа, а потом вынести на чертеж всю эту заранее оформленную кучу за одно движение). Вообще, в Allplan часто при создании 3D-модели, особенно сложной формы создаются/размещаются рядом с ней по 2-5 ее разрезов, в них модель редактируется (иногда редактирование хаотично, то в плане то в 3D, то в разрезе), после чего разрезы удаляются. Благо переключение из плана в 3D моментальное и вообще горячие клавиши в Allplan – это его большой плюс.
    4) Revit – самостоятельно (интернет в помощь) изучить во много раз проще, чем Allplan (по которому в 10-ки если не в 100-ни раз меньше видео, проч.). Главная трудность в освоении – непривычность, часто кажущаяся «не логичность» работы инструментов и самой логики проектирования в Allplan. Русскому человеку угадать логику Revit быстрее чем немецкую.
    5) 2016 и последующие версии Allplan для широкой общественности доступны только в виде демоверсий на 1 мес. Др. вариантов нет и не будет (с вероятностью 90%). Немецкая логика…

    ОтветитьУдалить
  14. у меня есть вопрос по СМИС - системам мониторинга инженерных систем. Какие сегодня ставят решения? Есть ли наработки в этой отрасли или применяют зарубежные аналоги СМИС: help-01.ru.

    ОтветитьУдалить

Поиск по этому блогу