W poprzednim wpisie nawiązującym do tematu IFC4, krótko wspomniałem o jego historii oraz przedstawiłem kluczowe aktualizacje od wersji IFC2x3. Jeżeli przegapiłeś ten wątek, gorąco zachęcam do zapoznania sie najpierw z nim.
W tym wpisie zaprezentuje praktyczne ćwiczenie, które wykonaliśmy na projekcie Uniwersyteckiego Szpitala w Stavanger, kiedy omawialiśmy możliwość wykorzystania IFC4. Niniejszym zaprezentuję nasze założenia, wykonane testy oraz finalne rezultaty. Na koniec zaś zawarte będą konkluzje oraz odpowiedź na zadane główne pytanie.
Spis treści
Status certyfikacji
Ta strona zawiera wykaz statusu certyfikacji IFC dla różnych programów. Jak widać, lista oprogramowania IFC2x3 jest stosunkowo długa, i wszystkie są certyfikowane w MVD zwanym Coordination View 2.0. Jednakże, należy wskazać że z listy licznych przeglądarek IFC oraz tzw. issue checkerów, znalazłem jedynie Solibri, DDS-CAD oraz usBIM które posiadają certyfikaty Importu IFC2x3. Martwi mnie zwłaszcza to, że tzw. programy Field BIM, które są używane na tabletach na placy budowy nie posiadaja certyfikatu. W przypadku budowania na bazie modelu z nieprawidłową reprezentacją modelu, może to skutkować poważnymi usterkami na budowie.
Proces certyfikacji IFC4 wygląda mniej imponująco. Jest lista oprogramowań, które są uprawnione do eksportu, ale jest ona znacznie krótsza niż lista przy IFC2x3, i bardzo wolno rośnie. Na przykład, popularny Revit uzyskał certyfikacje IFC4 Reference View dopiero pod koniec 2020 (wraz z wydaniem Revit 2021). Reference View oraz Design Transfer są to nowe MVD, które buildingSMART wprowadził dla IFC4 (więcej tutaj).
Na tą chwilę liczba certyfikowanych oprogramowań służacych do eksportu w MVD Design Transfer wynosi całe okrągłe 0. Musimy jeszcze poczekać by być w stanie przenosić modele pomiędzy oprogramowaniami w obydwie strony. Niestety, proces certyfikacju żadnego programu dla DT nawet się nie zaczął. Nawet nie jestem pewny czy buildingSMART ukonczył specyfikację testu.
Certyfikacja importu IFC4 wyglada jeszcze gorzej. Jedynie dwa oprogramowania uzyskały certyfikat (Tekla oraz BridgeBIM). Pozostałe popularne przeglądarki IFC są w trakcie certyfikacji. Oznacza to, że po otwarciu modelu w przeglądarce IFC, nie możemy być pewni czy oprogramowanie przetworzyło dane prawidłowo. Faktem jest, że nawet jeżeli projektanci wykonają prawidłowy eksport do IFC4, Koordynator BIM może znależć błędy (np. w reprezentacji graficznej), ktore nie istnialy wcześniej w “czystym” pliku IFC4.
Porównanie eksportów w IFC2x3 oraz IFC4
Projekt nad którym w tej chwili pracuję, jest wielki i skomplikowany. Przed nami stoją ogromne wyzwania związane z wydajnością. Mamy ponad 400 modeli IFC które w całości ważą 30 GB. Jeden wielobranżowy model Solibri zawierający wszystkie budynki to 2,4 GB.
Słyszeliśmy, że IFC4 poprawia wydajność zaokrąglonych obiektów oraz lepiej przetwarza dane. Jako że mamy ciężkie modele MEP oraz ilość danych w każdym obiekcie jest ogromna, zespół projektowy zdecydował się spróbować i przetestować.
Podsumowując, nasze założenia oraz oczekiwania były następujące:
- lepsza obsługa geometrii, przede wszystkim zaokrąglonych obiektów MEP
- lepsza reprezentacja otworowania w cienkich warstwach (problem, który architekt podnosił wielokrotnie)
- lepsza obsługa danych dzięki parametryzacji
ogólnie, schemat IFC4 powinien mieć lepszą wydajność
Przeprowadziliśmy szereg eksportów oraz testów:
- ARCH badał zachowanie dwóch różnych eksportów Revit do IFC: Reference View oraz Design Transfer. Porównał je do zwykłych eksportów IFC2x3
- MEP sprawdzał rozmiar pliku Solibri, czas otwarcia oraz reakcji na pliki MEP oraz ARCH eksportowane do IFC2x3 w porównaniu do IFC4
- Następnie ja dokonałem ogólnego sprawdzenia używając Solibri oraz innych przeglądarek IFC. Obejmowało to zarówno wizualną obserwację, sprawdzenie danych oraz uruchomienie issue checkera dla modeli IFC2x3 w porównaniu do IFC4.
Opiszę teraz rezultaty przeprowadzonych testów w każdym segmencie oraz podam ogólne wnioski na temat formatu IFC4.
Test IFC4 Architekta
Eksporty do Design Transfer MVD okazały się całkowitą porażką. Design Transfer ma być MVD, który jest używany do przenoszenia modelu pomiędzy różnymi oprogramowaniami w obydwie strony (taki Św. Graal w projektowaniu BIM). Architekci znalezli liczne błędy, głównie brakujące elementy geometryczne. Można się tego było spodziewać ponieważ Revit nie posiada certyfikacji odnośnie Design Transfer. Zastanawiam się tylko dlaczego ta opcja jest w ogóle dostępna w Revicie, kiedy osiąga się tak marne rezultaty?
Zespół architektów stwierdził iż format Reference View MVD oferuje znacznie lepszy podkład do dalszych testów. Reference View służy do pracy z modelem referencyjnym, koordynacji oraz sprawdzania kolizji (więcej na ten temat). Nie jest jednakże bez wad. Oto wyniki testów zespołu (zarówno te pozytywne jak i negatywne):
- Drobne różnice w klasach lub obiektach IFC (np. IfcFurniture staje się IfcFurnishingElement),
- Domyślne parametry Revit oraz ustawienia IFC Property Sets zmieniły nazwy, a niektore zniknęły.
- Wszystkie właściwości specyficzne dla danego projektu zachowały się.
- Właściwości materiałów zgubiły się lub pojawiły się błędy. Np.
- Informacyjne znaczniki nie były już koloru pomarańczowego tak jak były modelowane w Revit.
- Oznakowanie modelowane z różnych materiałów dla tekstu i tła zostały wyeksportowane jako ten sam domyślny materiał. To sprawiło trudności w odczytaniu tekstu w Solibri (szary tekst na szarym tle).
- Otwarowania w cienkich powierzchniach zostały prawidłowo eksportowane w IFC4 w porównaiu do IFC2x3 (równiez przy otworach na drzwi),
- Znaczna poprawa w rozmiarach pliku, bez żadnych brakujących obiektów (ok. 40% zaoszczędzonego rozmiaru pliku przy tej samej liczbie elementów przetworzonych przez eksportera).
Test IFC4 MEP
Testy przeprowadzone przez inżynierów MEP głównie koncentrowaly się na porównaniu rozmiarów pliku oraz wydajności modeli MEP oraz ARCH w naszym narzędziu do przeglądania IFC (Solibri). Revit MEP nie uzyskał jeszcze certyfikacji odnośnie eksportu w czasie przeprowadzanych testów, toteż nie mogliśmy całkowicie polegać na jakości eksportu. Dopiero niedawno zakończyła sie procedura (eksport MEP certyfikowany w 27.04.2022).
Głównym zaskoczeniem było odkrycie że nie-graficzne dane w naszym projekcie zajmują aż ok. 80% rozmiaru pliku. Dało nam to do myślenia w kontekście poprawy wydajności przy następnych krokach (redukcja liczby parametrów).
Po przeprowadazonym teście, okazało się iż IFC4 lepiej sprawuje sie w przetwarzaniu geometrii – czyste pliki geometryczne były ok. 30% mniejsze niż przy IFC2x3. Jednakże, zysk ten niweluje się przy eksporcie pełnych modeli – model IFC4 jest jedynie 7% mniejszy niż przy IFC2x3. Stąd można wnioskować iż IFC4 obsługuje strukturę płaskich danych tak samo jak IFC2x3. Na moje oko, aby uzyskać lepsze wyniki przy IFC4, dane powinny by inaczej ustrukturyzowane (typy właściwości lepiej eksportować jako właściwości pochodne, a nie powiązane z każdą instancją).
Pomiary czasu otwarcia oraz reakcji wykazały mniejsze różnice niż błędy pomiarowe (1-2%), więc można stwierdzić brak poprawy. Ale istotna uwaga jest taka że ustawienie struktury danych pod kątem IFC4, może skutkować lepszymi rezultatami wydajności.
Ogólne sprawdzenie
Wzrokowa obserwacja
Po bliższym przyjrzeniu się wartościom, stwierdziliśmy parę błędów z reprezentacją danych:
- Podana niewłaściwa grubość materiału (pomimo że prawidłowo podana w innych przeglądarkach IFC)
- Nie wszystkie domyślne IFC property sets są eksportowane
- Niektóre otwarcia pokazują odwrotne wymiary (X i Y)
- Problem z IfcShapeRepresentation – zakrzywione kształty z Revita nie są prawidłowo pokazane
Sprawdzenie reguł (Rule checking)
Wynik czystej kontroli parametrów dał ten sam wynik dla obu plików – co oznacza brak utraty żadnych danych projektowych. To samo wykazała podstawowa kontrola architektury oraz przestrzeni.
Z drugiej strony, porównanie rewizji modeli (obiekty w IFC2x3 w porównaniu do obiektów w IFC4) wykazało błędy. Każdy model który porównałem, dawał w rezultacie kilka tysięcy zmienionych obiektów. Większość z tych problemów dotyczyło:
- Brakujący typ materiału/nazwa/grubość,
- Zmieniona geometria (można było tego oczekiwać, skoro metoda tworzenia geometrii się zmieniła)
- Zmiana w wymiarach, powierzchni i objętości. Czasami niewielkie (<2% prawdopodobne z powodu zmienionej geometrii), ale czasami dużo ponad 100%, co już oznacza poważny błąd.
- Czasami zmiany w nazewnictwie typu, prawdopodobnie z powodu tego jak Revit definiuje eksport do IFC4
Wnioski
Zdecydowalimy sie pozostać przy IFC2x3, przynajmniej do momentu gdy Revit zdobędzie certyfikat eksportu MEP a Solibri otrzyma certyfikat importu. Powodu przemawiające za naszym wyborem:
- Budujemy bezpośrednio z modeli – nie możemy sobie pozwolić na żadne ryzyko utraty danych, które w postaci modeli są bezpośrednio kierowane na plac budowy.
- Modelujemy w sposób, który nie jest optymalizowany dla IFC4 – modele są przetwarzane podobnie wolno jak w IFC2x3
- Oprogramowanie nie jest jeszcze gotowe do eksportu i importu IFC4 w zadowalający sposób – problemy w reprezentacji graficznej, które nie istnieją w eksportach IFC2x3
Podsumowanie- czy branża jest gotowa na IFC4?
Odowiadając krótko i dosadnie – nie. Branża jeszcze nie jest gotowa. Głównym powodem są dostawcy oprogramowania, którzy zostali z tyłu z adaptacja oprogramowania do eksportu/importu IFC4 (potwierdza to m.in. otrzymanie certyfikatów). Generalnie oznacza to, iż ich oprogramowanie nie jest gotowe do transferu danych do IFC przy zachowaniu 100% dokładności, lub do przetwarzania otrzymanych plików IFC. Dlaczego dostawcy się tak opóźniają (IFC4 ma już 9 lat!), to już inne pytanie i zupełnie nowa dyskusja.
Koniec końców, nasze projekty wciąż muszą używać IFC2x3 i dalej borykać się ze wszystkimi problemami znanymi w tym formacie i jego obróbce przez znane nam oprogramowanie. Ryzyko nieprawidłowej reprezentacji modelu w IFC4 jest zbyt wysokie w porównaniu do zysków, które nam on daje.
Chociaż nie uważam się za eksperta w kwestii IFC4 i z chęcią zapoznam się z przykładami skutecznego wdrożenia IFC4 na projektcie!
cześć,
szukając informacji o Ifc4 zaciekawiłeś mnie tym punktem:
“Zmiana w wymiarach, powierzchni i objętości. Czasami niewielkie (<2% prawdopodobne z powodu zmienionej geometrii), ale czasami dużo ponad 100%, co już oznacza poważny błąd.”
Sam zaobserwowałem też różnice, ale na plus – IFC4 podawał poprawne objętości, w przypadkach gdy stary format generował błędy. Przykład: przy eksporcie płyty zamodelowanej dwoma osobnymi obwiedniami w ifc 2×3 mamy całkowitą objętośc przypisaną do każdego z elementów, a w 4 poprawnie policzoną dla każdej z części.
Ciekawi mnie czy w Twoim przypadku porównywałeś wyniki z natywnymi z Revita i zauważyłeś błędy po stronie eksportu do 4ki?
Cześć,
dzięki za komentarz!
W sumie dobry pomysł – nie sprawdzałem tego w Revicie. Być może jakby to była jedyna różnica, to szukalibyśmy głębiej przyczyn różnic. Jednak to niestety nie był jedyny punkt i summa summarum, odpuściliśmy na razie temat IFC4 całkowicie, jednocześnie zgłaszając te uwagi do Solibri i Autodesku.