18 Kwi 2013

Martijn de Riet „Myth Buster: Revit & IFC”

W dzisiejszym odcinku bloga zamieszczamy tłumaczenie artykułu

18 Kwi 2013

W dzisiejszym odcinku bloga zamieszczamy tłumaczenie artykułu Martijna de Riet zamieszczonego na portalu www.augi.com . Jest to ciekawa analiza funkcjonowania w programie Revit formatu IFC zrobiona przez doświadczonego użytkownika bez nachalnego marketingu tak typowego dla firmy Autodesk. Jak to przy tłumaczeniu języka technicznego mogą się znaleźć sformułowania, które nie mają jeszcze odpowiedników w języku polskim. Staraliśmy się aby było ich jak najmniej.

 

Martijn de Riet „Myth Buster: Revit & IFC”

 

Odważna deklaracja

Autodesk ® Revit ® jest w pełni zdolny do eksportowania każdego typu geometrii do Industry Foundation Classes (IFC) bez utraty jakichkolwiek danych.
Revit jest całkowicie zdolny do importowania i implementacji modelu IFC na rodzimy format programu Revit.
Przy tych założeniach cała debata pomiędzy zwolennikami OpenBIM, a Closed BIM nie ma racji bytu.

Zarys sytuacji

Mamy dwóch głównych graczy na scenie oprogramowania BIM: Revit i ArchiCAD. Jednym z głównych punktów dyskusji dla każdego przedsiębiorstwa przy wyborze oprogramowania jest (niby) brak kompatybilności Revit z IFC.

Wiem, że IFC nie odgrywa (jeszcze) istotnej roli w ojczystym kraju firmy Autodesk czyli USA. Ale w innych częściach świata tak jest. Za przykładem innych krajów holenderska Dutch Governmental Building Agency wydała rozporządzenie na wykorzystywanie IFC jako sposobu wymiany informacji dla projektów BIM w niektórych kategoriach. Chociaż obowiązkowe stosowanie IFC jest teraz ograniczone głównie do projektów typu  „Zaprojektuj i zbuduj” oczekuje się, że będzie następować dalsze rozszerzenie tego zakresu w szybkim tempie na pozostałe kategorie projektów. Sytuacja ta sprawia, że pojawia się pytanie: Gdzie w tym wszystkim znajduje się Revit?

Gdy słucham przedstawicieli OpenBIM, to ich zdaniem obsługa formatu IFC przez Revit zawsze była i będzie dramatyczna. Najczęściej powtarzanym powodem takiej opinii jest to że : „Autodesk chce zdominować światowy rynek oprogramowania formatem rvt , tak samo jak zrobili to z  formatem dwg.”

Nie jestem pewien dlaczego uważają oni to za coś złego. Czy to nie jest standardowa sytuacja w dziedzinie  nowych technologii? Spójrzcie na Office, PDF, Java, Photoshop, iOS, Facebook Like i inne. Wszyscy starali się zdominować świat na swoim własnym rynku i wyszli na tym całkiem dobrze. Więc w czym tkwi problem? Przecież powstają nowe firmy, korzystają z istniejących pomysłów i starają się zrobić to samo tylko lepiej lub taniej. Albo wymyślają całkowicie nową rewolucyjną koncepcje, która z kolei im pozwoli na dominację na świecie. W taki właśnie sposób działają innowacje w mojej teorii.

Równocześnie jest to kompletnie nie związane z tematem oprogramowania. Każda firma powinna w swoich planach dążyć do dominacji na rynku w którym działa. To jest ich celem istnienia. I dążenie do tego nie jest bynajmniej powodem tego, że Autodesk nie wspiera formatu IFC w dostatecznym stopniu.

Podobnie nie jestem pewien czy format IFC jest „przyszłością” czy nie. Myślę, że to zależy od sposobu w jaki chcemy go wykorzystywać. W przypadku zastosowania IFC tak jak chce tego nasz rząd, czyli jako zbiór danych dotyczących geometrii i najważniejszych parametrów to myślę, że to już w Revicie działa przyzwoicie.

Natomiast jeśli chcesz przesyłać za pomocą IFC informacje do wykorzystania w obliczeniach i analizach to moim skromnym zdaniem nie zda to egzaminu. Dlaczego? Zasadniczo można to porównać z Google Translate. Format IFC ma podobną ścieżkę rozwoju.

Kilka lat wstecz Revit tworzył plik IFC ze strasznymi błędami, dziwnymi  pomyłkami itp. , dokładnie tak jak robił to Google Translate .

W miarę rozwoju aplikacji Google Translate stał się lepszy. Teraz jest całkiem przyzwoity w tłumaczeniu podstawowych języków jeśli używamy prostych zdań i gramatyki. Nie wszystkie języki działają równie dobrze (holenderski, na przykład, wydaje się być dość zawiły), ale przynajmniej można zrozumieć sens tłumaczenia i jest on dostateczny do tego stopnia, żeby wyróżnić błędy i je skorygować. Myślę, że aktualne wersje wszystkich programów do modelowania 3D doszły właśnie do tego punktu.

Ale wszyscy rozumiemy jaka jest różnica między językiem ojczystym i programowym tłumaczeniem w oparciu o zestaw reguł. Nie ma sposobu, aby Google Translate lub IFC kiedykolwiek zdołały uchwycić wszystkie zawiłości złożonego języka, nieważne czy ludzkiego czy komputerowego.

Podczas sesji z jednym z moich klientów, miałem wreszcie dość toczącej się debaty na temat tego czy jest możliwe zrobienie przyzwoitego eksportu lub importu w Revicie więc postanowiłem spędzić kilka dni by spojrzeć na to samodzielnie. Wysłałem zapytanie w tym temacie i dostałem listę kilku najbardziej irytujących pułapek przy korzystaniu z IFC w  Revicie.

  1. Revit nie posiada parametrów IFC
  2. IFC Eksport: połowa geometrii zostaje utracona lub zostaje zastąpiona (IFC jest stracone i ląduje w koszu)
  3. IFC Eksport: nie ma mowy o nadpisaniu ogólnych ustawień
  4. IFC Eksport: nie ma sposobu na eksport modeli cząstkowych
  5. IFC Import: wszystko po prostu zostaje wrzucone do kategorii Generic Model
  6. IFC Import: brak parametrów obiektów po imporcie.

Revit nie posiada parametrów IFC

Ten temat zajął mnie przez dłuższy czas. Dlaczego nie ma połączenia między parametrami i właściwościami Revita a parametrami IFC? Okazuje się, że jest i to na wielu poziomach.
Po pierwsze jest połączenie w kodzie oprogramowania (np. wybierz narzędzie wall, gdzie każdy zakodowany parametr jest parametrem IFC). Działa wspaniale przy eksporcie, niestety przy imporcie już nie.
Po drugie, istnieje udostępniony przez Autodesk plik parametryczny: http://tinyurl.com/c5r8ha2 . Jest to plik szablon do użytku w czasie pracy z IFC zawierający wszystkie jego parametry. Umożliwia nam on użycie wszystkich parametrów IFC przy tworzeniu modelu w Revicie.

Nie mogę tylko zrozumieć dlaczego w Autodesku nie doszli do wniosku, że warto wbudować ten plik od razu do programu.

IFC Eksport: połowa geometrii zostaje utracona lub zostaje zastąpiona.

Stworzyłem prosty model z elementami, które są znane z tego że generują błędy :

–        Wall sweeps and fascias

–        Krawędzie płyt

–        Istniejący budynek zamodelowany jako bryła (masa)

Eksport do IFC (Revit> IFC> Export) przy użyciu standardowych ustawień Revita kończy się następującym wynikiem :

–        Bryła znika z modelu

–        Sweeps, fascias, i krawędzie płyt są eksportowane jako elementy zastępcze

–        Wszystkie materiały zostają utracone

Jak to jest przetwarzane w Revicie?

W opcjach eksportu (Revit > Export > Export Options > IFC Options)  jest mapa definiujaca jak eksportować różne kategorie z Revita do IFC. Na OBRAZKU 3 pokazana jest, że  standardowa opcja eksportu dla mas ustawiona „Not Exported”. Nic dziwnego więc, że masa nie jest obecna w pliku IFC. Na szczęście Revit pozwala nam zdefiniować własne mapowanie i zapisać je jako oddzielny plik. Wszystko co musisz zrobić, to uważnie przejrzeć wszystkie swoje kategorie i dodać je do konkretnej kategorii IFC.

Dla tych którzy chcą się dowiedzieć jakie kategorie można użyć jest pełna lista na stronie Revit WikiHelp : http://tinyurl.com/d95g9gd

IFC Eksport: nie ma mowy o nadpisaniu ogólnych ustawień

Częściowo prawda. Element Wall w Revicie zawsze będzie ifcWall. Nie ma sposobu aby to zmienić, ale też nie ma powodu żeby to robić. Jeśli jest to ściana to należy ją modelować jako ścianę i powinno być eksportowane jako ściana.

Istnieje jednak sposób, aby zastąpić standardowy eksport elementów przez ustawienie dwóch parametrów współdzielonych w pliku Autodesk IFC Shared Parameter :

IfcExportAs> Określa żądaną klasę IFC do nadpisania. Można nawet użyć opcji „DontExport” dla klasy której nie chcemy eksportować do IFC.

IfcExportType> Określ żądany typ IFC do nadpisania.

Przy okazji istnieje kilka przykrych niespodzianek:

  • Opcja ta działa tylko dla komponentów lub rodzin użytkownika, a nie na rodzinach systemowych. Jest to zarówno dobre (dlaczego ktoś chciałby eksportować Wall jako coś innego) jak i złe (na przykład : Sweep Wall może być mnóstwem różnych rzeczy).
  • To działa tylko dla typów rodzin, a nie poszczególnych przypadków.
  • Trzeba dodać Shared Parameters do samych rodzin. Zwykłe dodanie do projektu nie wystarczy. Należy otworzyć rodzinę, dodać  udostępnione parametry i przeładować. Wtedy można je ustawić na żądaną wartość w projekcie.

IFC Import: wszystko po prostu zostaje wrzucone do kategorii Generic Model

Tym razem krótko. Tak jak w przypadku eksportu do IFC przy imporcie znajduje się mapa, która określa gdzie wędruje konkretna kategoria IFC. To prawda, że standardowa mapa importu umieszcza wszystko oprócz ścian, podłóg, dachów, stropów, drzwi i okien w kategorii Generic Model.

Ale tak samo jak z mapą do eksportu możemy mapę importu dopasować do własnych potrzeb. Można znaleźć mapę w Revit > Open > IFC Options

 

IFC Import: brak parametrów obiektów po imporcie

Cóż, nie, nie ma. I szczerze mówiąc myślę, że nie powinno być ponieważ IFC nie jest przeznaczony do pracy w taki sposób. Podczas przesyłania modeli z IFC, dostajesz model kogoś innego, czyjąś pracę. Nie potrzeba go przerabiać ani dopasowywać żadnych parametrów. Jeśli chcesz to robić to nie pracuj przy użyciu IFC, tylko tego samego oprogramowania.

Mimo to uważam, że konwersja na import powinna być znacznie lepsza. Wartości podstawowych parametrów takich jak wysokość i szerokość powinny być pobierane przy imporcie z IFC. Ostatecznie znamy te wymiary z pliku IFC (rys. 5), ale nie są one przesyłane do odpowiednich parametrów Revita (rys. 6). Mogę zrozumieć, że parametry nie są już związane z geometrią, ale teraz nie jest nawet możliwe, aby rozplanować całkowite gabaryty obiektu.

Wnioski

Więc Revit i IFC pasują do siebie jak ulał? Nic z tych rzeczy! Jest jeszcze wiele do zrobienia. Wiele elementów po prostu nie działa, zwłaszcza, jeśli chodzi o import plików IFC. Zasadniczo, Revit pozwala zaimportować model IFC i używać go jako zlinkowanego pliku. Inny sposób korzystania jest praktycznie bezużyteczny. Także znacznie więcej parametrów powinno być zmapowane m.in. całkowite wymiary opisane w tym artykule, zwłaszcza gdy uświadomimy sobie, że jest już to robione: np. po wstawieniu do modelu ściany robimy eksport do IFC. Po tym otwieramy IFC w programie Revit, i okazuje się, że konkretny parametr Revita (struktural wall) nadal jest idealnie dopasowany. Tak samo powinno być z pozostałymi istotnymi parametrami.

Importowanie działa nieco lepiej, kiedy używamy jako szablonu pliku parametrów predefiniowanych zwłaszcza jeśli chodzi o pracę z oprogramowaniem innym niż Revit. Ale nadal jest to konieczne, aby zastąpić wszystkie niesystemowe rodziny jeśli chcesz faktycznie coś zrobić z importowanym modelem.

Eksportowanie to zupełnie inna historia. Ogólnie rzecz biorąc eksport do IFC można w znaczny sposób dostosować do swoich potrzeb i działa to dość dobrze. Ale także i w tym przypadku znajdziemy usterki. Na przykład trzeba być bardzo ostrożnym z definiowaniem współrzędnych projektu. Elementy modelu po eksporcie mogą magicznie przenieść się w zupełnie przypadkowe miejsca. Ponadto IFC nie działa dobrze z niektórymi funkcjami takimi jak „attached walls” i „edited profiles”.

Jednak są to problemy, na które można natknąć się także na innych platformach, nawet tych wyspecjalizowanych w IFC i OpenBIM. Więc domyślam się, że jest to ogólny problem formatu IFC, a nie tylko Revita. Poprosiłem kilka z głównych wiodących holenderskich firm architektonicznych o szczere opinie na temat ArchiCADa i IFC. Czy wysyłają do swoich klientów model IFC jako część dokumentacji bez gruntownego sprawdzenia? Odpowiedź od  wszystkich firm była zdecydowana: „Czyś ty oszalał? Oczywiście, że nie! Tylko niezbędne dokumenty są wysyłane”.

Dla mnie prawdziwą solą w oku jest sytuacja kiedy dochodzi do współpracy w ramach BIM przy użyciu formatu IFC . Nie ma bowiem gwarancji (jeszcze), że model jest w 100 % poprawny, nieważne jakiego oprogramowania będziemy używać. Ale jak na razie jesteśmy tutaj, taka jest nasza rzeczywistość, nasz obowiązek (czasami) i z miejsca, w którym teraz jestem Revit radzi sobie z IFC w całkiem przyzwoity sposób.

Martijn de Riet jest samodzielnym konsultantem BIM z Holandii, pracuje na Revicie od wersji 5,1. Martijn posiada stopień licencjata z budownictwa. Po studiach założył własną firmę inżynierską pracującą dla wykonawców, architektów oraz inwestorów. Od 2007 jego firma przekształciła się całkowicie na usługi doradcze BIM. W tej chwili klientami Martijna są różne firmy : od średnich firm architektonicznych do największego holenderskiego generalnego wykonawcy oraz firm instalacyjnych (MEP), dla których wykonuje specyficzne rozwiązania korporacyjne, projektowanie i wdrożenia Revit oraz BIM. Martijn jest członkiem Dutch Revit User Group  i obecnie pracuje nad stworzeniem szablonu głównego i biblioteki. Prowadzi regularne wykłady dla firm, uczelni technicznych i seminariów.

 

Kilka słów od MAD

Nie zgadzamy się kompletnie z porównaniem IFC do Google Translate. Podstawy IFC to linijka kodu odpowiedzialna za materiał (czyli tekst) i  druga odpowiedzialna za geometrie (czyli współrzędne obiektu). Więc mamy do czynienia z czystą matematyką i nie widzimy tu żadnego problemu aby IFC był czytelny w 100% dla wszystkich programów. Trzeba tylko ruszyć przysłowiowe cztery litery i zabrać się do poprawiania implementacji tego formatu! Chociaż jak widać po tym co piszemy na blogu w kategorii „Projekt BIM w praktyce” praca w IFC jest możliwa choć mogłaby być lepsza.

Osobiście mieliśmy do czynienia z instalacjami z Revit MEP i tam dla nas istotna była geometria i lokalizacja według punktu 0 projektu. Geometria była bez zastrzeżeń, a współrzędne punktu 0 tak jak pisał wyżej Martijn były czasami w innym miejscu… więc była wymagana odrębna koordynacja modelu do osi głównych projektu. Co przy znajomości problemu było lekko uciążliwe ale nie że niewykonalne .

I co ważne nasz model IFC konstrukcji przy projekcie ASP Warszawa został dołączony do dokumentacji jako jej integralna część. Na każdym z rysunków wykonawczych jest uwaga „Analizować łącznie z modelem IFC konstrukcji”. Więc da się 🙂

Kolejna rzecz to taka o której już wspominaliśmy na blogu, że Autodesk udostępnił kody źródłowe exportu do IFC i dzięki temu powstał alternatywny projekt typu OPEN SOURCE (o czym niewiele osób wie) a dostępny jest tutaj: http://sourceforge.net/p/ifcexporter/home/Home/

enjoy!

ps. orginał tekstu tutaj: http://www.augi.com/library/myth-buster-revit-ifc

 Andrzej Inglot
Zespół M.A.D.

 

Leave a comment
More Posts
Comments
  1. Andreas Październik 14th, 2013 11:03AM

    Analogia Martijna de Rieta jest nietrafna także dlatego, że IFC jest strukturą sztuczną i sformalizowaną (swego rodzaju językiem) podczas gdy języki żywe nie. Język żywy ma mnóstwo idiomów które same w sobie tworzą reguły. Jak little bim przetłumaczy translator? jako „trochę bim” co oczywiście nie oddaje myśli autora książki „BIG BIM little bim” ale kto wie czy nie jest przypadkiem słuszne. IFC z natury jest w pewnym zakresie uboższy w informacje niż to co używają poszczególne aplikacje, ale kolejne wersje są coraz bogatsze. Spróbujmy odpowiedzieć sobie na pytanie jaka jest alternatywa dla wspólnego i otwartego formatu wymiany modeli? Czy przykład DWG jest dobry? Definicja DWG nie jest opublikowana i firmy, które próbują czytać ten format muszą go „rozgryźć”, co nie przychodzi łatwo a Autodesk w kolejnych wersjach wprowadza utrudniające życie haczyki. Jaka jest alternatywa? Albo przyjąć jeden z formatów komercyjnych, albo jeden wspólny. Dla użytkowników różnych systemów najlepszym wyjściem jest jeden wspólny format. Dla producentów oprogramowania także. Inaczej należałoby opracować ogromną liczbę interfejsów Revit to Archicad, revit to Vectorworks, to Tekla, to DDS, DDS to Tekla, tekla to Advance, itd. itp. – jednym słowem obłęd. Może i IFC to zło konieczne ale dla nas użytkowników i producentów jest wyjście lepsze od formatu komercyjnego narzuconego przez jakiegoś molocha.

  2. maciekd Październik 14th, 2013 11:27AM

    jeszcze jedna ważna rzecz apropo IFC którą skomentował w artykule http://www.bimblog.pl/2011/12/ifc-kilka-suchych-faktow/ Przemek Oleśiński:

    „Bylbym ostrozny lekka krytyka “powolnej” pracy przy wprowadzaniu poszczegolnych wersji IFC w zycie. Moim zdaniem, opieszalosc producentow construction software w opracowaniu pelnej kompatybilnosci ich produktow z konkurujacymi programami jest podyktowana jedynie “konfliktem interesow”. Mozliowsc nieskrepowanego uzywania IFC (dopracowanego w 101% bez mozliwosci gubienia danych, pomieszania profili/bibliotek etc.) postawi firmy software przed zupelnie innymi wyzwaniami oraz wymusi na nich reorganizacje ich modelu biznesowego. Z drugiej strony otwiera to kolejne mozliwosci dzieki polaczeniu i wdrozeniu baz danych producentow materialow, produktow oraz serwisow. Wiele dzieje sie rowniez i w tym temacie. Czekam z niecierpliwoscia na udoskonalenie np. serwisow opartych na wycenianiu/kosztorysowaniu “na zywo online”. Wg mnie bedzie to najwiekszy krok milowy w rewolucji virtualnego projektowania i zarzadzania obiektami (tzw. life cycle management).

    Pozostaje jeszcze jeden aspekt frywolnego uzywania plikow IFC: latwosc w nieograniczonej globalnej dostepnosci do danych, ktore sa kumulowane i przekazywane poprzez tenze format plikow. Mysle tutaj o instytucjach panstwowych, ktore to bardzo staraja sie (zreszta chyba musza) kontrolowac rozwoj IFC.”

  3. gester Październik 14th, 2013 11:27PM

    maciek, mozliwosc kosztorysowania, moze na razie nie online, ale in real time ma juz vico office suite. w zasadzie funkcjonalnosc online jest tylko kwestia ich checi i modelu biznesowego:
    http://www.youtube.com/watch?v=RJw7EG7qMXg

    w ogole wszyscy wydaja sie zapominac o jednym: celem ipd nie jest sama budowa (no ok, moze nie jedynym), ale przede wszystkim okres facility management, bo wtedy sa generowane najwieksze koszty. taki jest trend ipd na swiecie.
    rob

  4. maciekd Październik 16th, 2013 11:39PM

    Rob,
    ale po co patrzeć na Vico, czy jakakolwiek firma w Polsce ma to oprogramowania albo inaczej, czy te oprogramowanie nadaje się na nasz rynek? Datacomp testował to oprogramowanie i zachwycających rezultatów nie uzyskali. Poza tym nie zapominajmy o ZuziBIM, która jest cały czas optymalizowana pod kątem wydajności (w sensie szybkości wykonania przedmiaru z IFC)

  5. maciekd Listopad 9th, 2013 10:58AM

    część druga:
    http://www.augi.com/library/myth-buster-revit-ifc-part-2-the-saga-continues
    a w trzeciej częśći artykułu „Revit & IFC” Martijna de Riet już się poddał 🙂 Mamy już takie podtytuły typu ” Why not IFC” „When everybody uses Revit” SZOK!
    http://issuu.com/augi/docs/aw201310hr/25?e=0

  6. gester Listopad 9th, 2013 12:37PM

    generalnie widac zatem, ze adesk w opcji importow ifc nie ma za wiele mozliwych pól w mapping tables.
    to tez moze tlumaczyc, dlaczego tak wiele booleans sie nie importuje do revita (n.p. z archicada lub vectorworks).
    a bez tego adesk nie ma szans na certyfikat buildingsmart dla importow ifc (bo eksporty ma juz certyfikowane).

  7. gester Listopad 9th, 2013 1:27PM

    aha, nie wiem, czy juz tutaj o tym bylo, ale jestescie wspomniani na holenderskiej stronie http://www.mdr-advies.nl/weblog/myth-busters-revit-ifc-vertaald/, artykul na dole: ‚En het laatste nieuwtje…’ (ostatnie nowosci)

  8. maciekd Listopad 9th, 2013 8:19PM

    tego nie wiedzieliśmy, jak się zabieraliśmy za tłumaczenie to pytaliśmy się o zgodę. Dostaliśmy ją i artykuł miał być na stronie augi.
    Ta strona to zdaje się firma Martijna… bardzo ciekawa.

  9. gester Listopad 22nd, 2013 1:55AM

    tak, mdr to martijn de riet.

Comment