Zarządzanie poziomem szczegółowości LOD w modelu 3D na różnych etapach inwestycji

0
98
2/5 - (1 vote)

Spis Treści:

Intencja zarządzania LOD w modelu 3D

Świadome zarządzanie poziomem szczegółowości LOD w modelu 3D ma jeden nadrzędny cel: dostarczyć dokładnie tyle informacji, ile jest potrzebne na danym etapie inwestycji – ani mniej, ani więcej. Nadmiar detalu zabija elastyczność modelu, niedobór uniemożliwia podjęcie decyzji, a chaos w definicji LOD prowadzi wprost do konfliktów między projektantem, inwestorem i wykonawcą.

Kluczowe jest więc ustawienie jasnych oczekiwań wobec modelu 3D na poziomie umów, BEP i codziennej pracy zespołu oraz taka organizacja rozwoju modelu, aby nie przepalać godzin na „przemodelowanie”, które nie wnosi wartości dla inwestycji.

Futurystyczny model 3D ciemnego miasta z wysokimi wieżowcami
Źródło: Pexels | Autor: Steve A Johnson

Czym faktycznie jest LOD i dlaczego myli się z „ładną geometrią”

LOD jako poziom informacji, a nie tylko ilość detalu 3D

W praktyce wiele zespołów utożsamia LOD wyłącznie z ilością detalu geometrycznego – liczbą śrubek, frezów na profilach, realistycznym kształtem klamek czy fakturą materiału. To połowa prawdy. Poziom szczegółowości LOD obejmuje zarówno geometrię, jak i informacje niegeometryczne – parametry, opisy, kody klasyfikacyjne, dane eksploatacyjne.

Model o wysokim LOD może mieć względnie prostą geometrię, ale bardzo bogaty zestaw parametrów (np. klasa odporności ogniowej, współczynnik przenikania ciepła, koszty jednostkowe, numer systemu). Jednocześnie model „wizualizacyjny”, pełen detali 3D, ale pozbawiony rzetelnych danych, może mieć z punktu widzenia procesu budowlanego bardzo niski, wręcz iluzoryczny poziom LOD.

Przykład: drzwi jako prosty prostopadłościan w modelu PB z parametrami: wymiar w świetle, odporność ogniowa, kierunek otwierania i numer zestawu – to często wystarczający LOD na tym etapie. Natomiast te same drzwi wymodelowane z klamką, uszczelkami i zawiasami, ale bez informacji o odporności ogniowej, nie spełniają celu inwestycji, mimo że „wyglądają lepiej”.

Jak różne standardy definiują LOD – ogólne ramy, nie dogmat

Na rynku funkcjonuje kilka popularnych systemów LOD, np. definicje AIA/BIMForum (LOD 100–500) czy różne warianty europejskie oparte na rozdzieleniu LOG/LOI. Łączy je jedna myśl: każdy poziom LOD opisuje, do jakiego celu można użyć danego elementu modelu – czy nadaje się do szacunków, do projektu budowlanego, do szczegółowej koordynacji czy do rozliczeń powykonawczych.

Problem zaczyna się, gdy tabele LOD są przepisywane bezrefleksyjnie. Standardy AIA/BIMForum powstały w określonym kontekście prawnym i rynkowym; lokalne wytyczne branżowe – w innym. Z tego powodu rozsądniej jest traktować je jako szablon do dostosowania niż jako absolutną prawdę. Wiele biur, które próbuje wdrożyć LOD 1:1 z tabel, szybko odkrywa, że połowy wymagań nikt nie jest w stanie dowieźć w typowych budżetach projektowych.

Bezpieczniejsza droga to wybór jednego systemu jako bazy (np. podział na LOD 100–400 z rozdzieleniem LOG/LOI) i opisanie tylko tych poziomów, które realnie wystąpią w danej inwestycji, z dopasowaniem do lokalnych przepisów i zwyczajów projektowych.

LOD jako umowa, nie obiektywna miara jakości

Najbardziej praktyczne podejście zakłada, że LOD to po prostu część umowy między stronami. To, co w jednym projekcie oznacza „LOD 300 dla ścian”, w innym może być kompletnie nierealne albo nadmiarowe. Kluczowe pytanie brzmi: jakie decyzje mają być oparte na tym elemencie modelu?

Jeżeli ściana ma posłużyć głównie do obliczenia powierzchni w projekcie budowlanym, wystarczy poprawny zarys i przypisanie typu przegrody z odpowiednimi parametrami. Jeżeli ten sam element ma służyć firmie wykonawczej do prefabrykacji ścian, zakres informacji musi być radykalnie szerszy. Oba przypadki można nazwać „LOD 300”, ale sens tych oznaczeń będzie inny, jeśli nie zostaną doprecyzowane w BEP i umowach.

Dlatego w dobrze prowadzonych projektach LOD jest zawsze powiązany z opisem zastosowania modelu: „ściany o LOD X mogą być użyte do…”, „instalacje o LOD Y nadają się do…”. Bez takiego doprecyzowania same liczby szybko tracą znaczenie i stają się polem do nieporozumień.

Najczęstsze mity: więcej detali = lepszy model

Warto rozbroić kilka typowych mitów dotyczących LOD:

  • „Im wyższy LOD, tym lepsza jakość projektu” – nieprawda. Wysoki LOD w złym momencie potrafi zablokować elastyczność projektu i dramatycznie spowolnić pracę.
  • „LOD to głównie grafika” – błędne założenie. W wielu przypadkach kluczowy jest poziom informacji niegeometrycznych (LOI), a nie perfekcyjna geometria 3D.
  • „Jedno LOD dla całego budynku” – rzadko sensowne. Realne projekty wymagają zróżnicowania LOD między strefami, branżami i elementami.
  • „LOD = jakość wizualizacji” – wizualizacja rządzi się innymi prawami niż model BIM przeznaczony do koordynacji, kosztorysowania czy FM.

Konsekwencją tych mitów jest częste „przemodelowanie” – zbyt szczegółowe opracowanie elementów, które za tydzień zmieni inwestor, lub których nikt nie wykorzysta ani w kosztorysie, ani na budowie.

Powiązanie LOD z etapami inwestycji – od koncepcji po eksploatację

Rola modelu 3D na poszczególnych etapach inwestycji

Model 3D nie pełni tej samej roli w fazie koncepcji, co podczas opracowania projektu wykonawczego czy eksploatacji obiektu. Każdy etap wymaga innego zakresu pewności i szczegółowości, a więc i innego LOD.

Na etapie koncepcji model ma przede wszystkim wspierać decyzje strategiczne: układ funkcjonalny, relacje między strefami, wielkości powierzchni, wstępne analizy nasłonecznienia i zacieniania, wariantowanie bryły. Geometria może być uproszczona, ale proporcje, powierzchnie i relacje przestrzenne powinny być wiarygodne.

Na poziomie projektu budowlanego model staje się narzędziem do formalizacji rozwiązań: nośny układ konstrukcyjny, podstawowe trasy instalacyjne, zgodność z przepisami (drogi ewakuacji, wysokości, gabaryty). Tu LOD musi umożliwić w miarę stabilne zestawienia i podstawową koordynację międzybranżową.

W projekcie wykonawczym rośnie znaczenie szczegółowości nie tylko geometrii, ale też informacji materiałowych, technicznych i montażowych. To na tym etapie wysoka precyzja LOD faktycznie przekłada się na mniejszą liczbę kolizji na budowie, lepsze kosztorysy i mniejszą liczbę zapytań od wykonawcy.

Co powinno być możliwe do „zobaczenia” i policzenia na każdym etapie

Dobrym sposobem określania LOD jest zadanie sobie pytania: co dokładnie chcemy móc odczytać z modelu na danym etapie? W praktyce może wyglądać to tak:

  • Koncepcja: powierzchnie stref funkcjonalnych, gabaryty budynku, stosunek powierzchni netto do brutto, relacje wysokościowe, bardzo wstępne ilości głównych przegród.
  • Projekt budowlany: ilości podstawowych elementów konstrukcyjnych, kategorie przegród z parametrami cieplnymi i akustycznymi, zasadnicze trasy instalacji, powierzchnie do celów pozwolenia na budowę.
  • Projekt wykonawczy: detale połączeń w kluczowych miejscach, dokładne ilości materiałów, zestawienia elementów prefabrykowanych, szczegółowa koordynacja instalacji, przygotowanie pod model powykonawczy.
  • Powykonawczy / FM: aktualne dane o zamontowanych urządzeniach, ich parametrach serwisowych, numerach części, danych gwarancyjnych, lokalizacji w przestrzeni.

W każdym z tych etapów „poprawny” LOD oznacza co innego. Np. dla instalacji elektrycznych w koncepcji wystarczą trasy głównych pionów i szaf; w projekcie wykonawczym – dokładne trasy kabli i rozmieszczenie gniazd; w modelu FM – dane o zasilanych urządzeniach, typach linii, grupach zasilania.

Więcej informacji na późniejszym etapie, ale nie zawsze bardziej skomplikowana geometria

Naturalną tendencją jest rosnąca precyzja modelu w miarę postępu projektu. To nie znaczy jednak, że geometria musi stawać się coraz bardziej „dekoracyjna”. Dojrzałe projekty często utrzymują geometrię względnie prostą, a zwiększają poziom informacji opisowej.

Przykład: w modelu PB okna mogą być prostymi otworami z podstawowymi parametrami. W PW geometria okna może pozostać prosta (bez wiernego odwzorowania listew i uszczelek), natomiast dojdą parametry systemu, numer producenta, sposób otwierania, klasy odporności, dane cieplne. Z punktu widzenia budowy jest to znacznie cenniejsze niż dokładnie wymodelowane profile, które nie wpływają na kluczowe decyzje.

Tymczasem wielu projektantów wrzuca modele producentów z bardzo wysoką szczegółowością 3D już na wczesnych etapach, co dramatycznie obciąża pliki i komplikuje późniejsze zmiany. Bardziej racjonalne podejście to wczesne wprowadzenie uproszczonych reprezentacji z parametrami kluczowymi, a dopiero w fazie wykonawczej – wymiana ich na obiekty producentów, jeśli jest taka realna potrzeba.

Przykład z praktyki: zbyt szczegółowy model koncepcyjny

Częsty scenariusz: architekt przygotowuje „pokazowy” model koncepcyjny z dużą ilością detalu (wystroje wnętrz, realne meble, fotorealistyczne przeszklenia). Inwestor zakochuje się w obrazkach, ale po kilku tygodniach zmienia założenia funkcjonalne, metraż powierzchni najmu albo układ komunikacji.

W takiej sytuacji każda zmiana wymaga przebudowy mocno rozbudowanego modelu. Zamiast elastycznie modyfikować bryłę i podziały funkcjonalne, zespół walczy z tysiącami szczegółowych obiektów. Do tego plik staje się ciężki i niestabilny, co utrudnia współpracę międzybranżową.

Jeżeli na etapie koncepcji LOD byłby świadomie ograniczony do bryły, stref, podstawowych przegród i prostych reprezentacji mebli, zmiany dałoby się wprowadzać szybko i tanio. Detale wizualne można wtedy przenieść do osobnego modelu marketingowego lub opracować dopiero po ustabilizowaniu głównych decyzji inwestora.

Abstrakcyjny render 3D nowoczesnej architektury z warstwową strukturą
Źródło: Pexels | Autor: Steve A Johnson

Standardy i systemy LOD – jak z nich korzystać, a nie się w nich zgubić

Najczęściej spotykane systemy LOD

Na rynku da się zauważyć kilka głównych rodzin standardów LOD. Ich nazwy i dokładne definicje różnią się, ale ogólna logika jest podobna. Najczęściej spotyka się:

  • Amerykański system LOD 100–500 (AIA, BIMForum) – dość popularny jako punkt odniesienia, choć nie zawsze wprost przenaszalny na lokalne realia.
  • Systemy z rozdzieleniem LOG/LOI – osobno poziom geometrii (Level of Geometry), osobno poziom informacji (Level of Information), co ułatwia precyzyjne ustalanie wymagań.
  • Wytyczne krajowe lub branżowe – w wielu krajach powstają własne standardy, często oparte na europejskich normach i lokalnych przepisach.
  • Wytyczne inwestorów – duzi inwestorzy tworzą własne systemy LOD, powiązane z ich procedurami zakupowymi, FM i systemami ERP.

Niezależnie od nazwy, te systemy próbują odpowiedzieć na pytanie: w jakim stopniu można polegać na tym elemencie modelu? Czy jest to jedynie wskazówka koncepcyjna, czy już wiążąca podstawa do zamówień i rozliczeń.

Różnice między LOD, LOI, LOG i LOA

Istotne jest rozróżnienie kilku powiązanych pojęć, które są często używane wymiennie, co prowadzi do nieporozumień:

  • LOD (Level of Development / Detail / Definition) – ogólny poziom „rozwinięcia” elementu, często traktowany jako skrót myślowy obejmujący zarówno geometrię, jak i dane.
  • LOG (Level of Geometry) – poziom szczegółowości i dokładności kształtu 3D; odpowiada na pytanie, jak wiernie odzwierciedlony jest element fizyczny.
  • LOI (Level of Information) – zakres i jakość informacji niegeometrycznych (parametry materiałowe, eksploatacyjne, klasyfikacje).
  • LOA (Level of Accuracy) – dokładność odwzorowania w stosunku do rzeczywistej lokalizacji, wymiarów czy stanu istniejącego (ważne szczególnie przy skanach i inwentaryzacjach).

W wielu projektach używanie jednego słowa „LOD” do opisania wszystkich tych aspektów powoduje zamieszanie. Rozdzielenie LOG i LOI pozwala np. ustalić, że geometria instalacji może pozostać prosta (LOG średni), ale informacje o średnicach, materiałach i wydajnościach muszą być już pełne (LOI wysoki).

Dostosowanie gotowych standardów do własnej praktyki

Gotowy system LOD kusi prostotą: wystarczy wskazać liczby i „problem z głowy”. Rzeczywistość jest bardziej uparta. Standardy branżowe są punktem startowym, a nie instrukcją obsługi konkretnej inwestycji. Bez adaptacji bardzo szybko okazuje się, że albo wymagamy za dużo (model puchnie i grzęźnie), albo za mało (brakuje danych do realnych decyzji).

Praktyczne podejście to potraktowanie standardu jako szkieletu, do którego dopisuje się warstwę projektową i organizacyjną. Zwykle oznacza to:

  • wybranie kilku poziomów LOD realnie potrzebnych na danej inwestycji (np. 200 / 300 / 400 zamiast całej drabinki),
  • spisanie w osobnej tabeli, co konkretnie znaczą te poziomy dla głównych kategorii elementów (architektura, konstrukcja, HVAC itd.),
  • przypisanie tych poziomów do kamieni milowych projektu (decyzje zarządcze, przetargi, pozwolenia, przekazanie do FM).

Bez tych doprecyzowań „LOD 300” w umowie znaczy co innego dla architekta, co innego dla instalatora, a co innego dla inwestora. Każdy patrzy na własny standard branżowy i ma poczucie, że pracuje „zgodnie z wytycznymi”. Konflikt pojawia się dopiero na etapie rozliczeń.

Minimalny zestaw ustaleń dotyczących LOD w dokumentach kontraktowych

Żeby system LOD działał w praktyce, w dokumentach kontraktowych musi się znaleźć kilka kluczowych elementów – w przeciwnym razie strony będą interpretowały te same hasła po swojemu.

  • Słownik pojęć – prosta tabela wyjaśniająca, co w tym projekcie oznacza LOD/LOG/LOI/LOA, z odwołaniem do źródłowego standardu (np. BIMForum, normy krajowej).
  • Mapa LOD do etapów – wskazanie, jaki poziom (lub zakres poziomów) jest celem na dany kamień milowy. Nie tylko „PB = LOD 300”, ale rozpisanie, które branże i które elementy mają dojść do jakiego poziomu.
  • Zakres odpowiedzialności – kto nadaje, weryfikuje i aktualizuje LOD; czy odpowiedzialność za LOI urządzeń przenosi się z projektanta na dostawcę, a jeśli tak – w którym momencie.
  • Sposób kontroli – opis, jak będzie sprawdzany LOD (np. przeglądy koordynacyjne, raporty z modeli, automatyczne reguły w CDE), żeby wymagania nie pozostały na papierze.

Bez tych czterech punktów zapis „model w LOD 350” bywa w praktyce nieweryfikowalny. Spory o to, czy „jeszcze nie ma” czy „już jest” odpowiedni poziom, są wtedy kwestią opinii, a nie mierzalnych kryteriów.

Definiowanie wymaganego LOD w praktyce – kto, kiedy i na jakiej podstawie

Kto faktycznie powinien decydować o LOD

Decyzja o wymaganym LOD często bywa cedowana na projektanta albo generalnego wykonawcę z prostym komunikatem: „ma być BIM, najlepiej na wysokim LOD”. To odwrócenie logiki. Poziom LOD ma wynikać przede wszystkim z potrzeb informacyjnych inwestora i użytkownika obiektu, a dopiero potem z wygody zespołu projektowego.

W praktyce sensowny podział ról wygląda tak:

  • Inwestor / przyszły operator – określa, jakich decyzji będzie dokonywał na podstawie modelu (zakupy, analizy, zarządzanie majątkiem), a więc jakie dane są krytyczne.
  • Koordynator BIM / Project Manager – przekłada te oczekiwania na strukturę wymagań informacyjnych, mapując je na poziomy LOD/LOI/LOG.
  • Projektanci branżowi – weryfikują realność oczekiwań wobec własnej branży, wskazują elementy, w których zwiększenie LOD przyniesie realny efekt, a gdzie będzie tylko generować koszty.
  • Wykonawca – doprecyzowuje, jaki poziom szczegółowości jest potrzebny do organizacji robót, prefabrykacji, zamówień i rozliczeń.

Jeśli cały proces decyzyjny o LOD zostanie zostawiony jednej stronie (np. tylko biuru projektowemu), efekt jest przewidywalny: albo powstaje model nadmiernie rozbudowany „na wszelki wypadek”, albo tak uproszczony, że ma niewielką wartość na budowie czy w eksploatacji.

Kiedy jest najlepszy moment na zdefiniowanie wymaganego LOD

Najczęstszy błąd: dyskusja o LOD zaczyna się dopiero przy pierwszym konflikcie („czemu nie ma tego w modelu?”). Tymczasem poziomy szczegółowości powinny być ustalone zanim powstaną pierwsze istotne fragmenty modelu – inaczej część pracy i tak będzie trzeba robić dwa razy.

Ramy czasowe, które zwykle się sprawdzają:

  • na etapie tworzenia OIR/AIR/EIR (wymagania informacyjne organizacji/projektu) – zdefiniowanie, do czego ma służyć model oraz które dane są priorytetowe,
  • przy przygotowaniu Planu realizacji BIM (BEP) – przełożenie tych potrzeb na konkretne poziomy LOG/LOI dla klas obiektów i etapów,
  • po wstępnym etapie koncepcji – korekta wymagań LOD, gdy realny kształt inwestycji i harmonogram są już bardziej znane.

Pełne „zamrożenie” wymagań też bywa pułapką. W dłuższych projektach aktualizacja BEP i tabel LOD przynajmniej raz na kilka kluczowych kamieni milowych jest praktycznie nieunikniona – zmieniają się założenia technologiczne, wykonawca wchodzi z innymi oczekiwaniami, pojawiają się nowe systemy FM.

Na jakiej podstawie ustalać wymagany LOD – kryteria praktyczne

Najrozsądniej zacząć nie od pytania „jaki LOD chcemy mieć?”, tylko „jakie pytania chcemy zadać modelowi na danym etapie?”. Dopiero z takiej listy wynika, jak szczegółowa musi być geometria i informacje.

Przykładowe kryteria:

  • Decyzje finansowe – jeśli na podstawie modelu będzie tworzony kosztorys do przetargu, LOI dla elementów kosztotwórczych musi być wysoki; geometrycznie elementy mogą być wciąż dość proste.
  • Ryzyko kolizji i błędów wykonawczych – tam, gdzie tolerancje są małe (np. szachty instalacyjne, prefabrykacja), LOG musi być podniesiony odpowiednio wcześnie, inaczej model straci sens koordynacyjny.
  • Wpływ na harmonogram – jeśli pewna grupa elementów jest krytyczna dla ścieżki czasowej, ich LOD powinien „dojrzeć” szybciej niż reszta, żeby umożliwić wcześniejsze zamówienia.
  • Wartość dla FM – dla elementów, które będą intensywnie zarządzane w eksploatacji (urządzenia, instalacje), LOI zwykle musi być znacznie wyższy niż LOG.

Dobrym filtrem jest pytanie: kto i kiedy zapłaci za podniesienie LOD oraz kto z tego realnie skorzysta. Jeśli odpowiedź nie jest jednoznaczna, bezpieczniej utrzymać ostrożniejszy poziom szczegółowości i przewidzieć możliwość jego zwiększenia później.

Cyfrowa wizualizacja futurystycznego miasta z wieżowcami o zmierzchu
Źródło: Pexels | Autor: Steve A Johnson

Strategia rozwoju modelu 3D – od bryły do detalu

Model jako produkt „iteracyjny”, a nie stały szablon

Model 3D to nie jest stały artefakt, który raz się definiuje i potem tylko „uzupełnia”. Jego struktura i poziom szczegółowości powinny ewoluować wraz z dojrzewaniem inwestycji. Sztywny pomysł na LOD od początku do końca projektu rzadko wytrzymuje zderzenie z rzeczywistością.

Rozsądna strategia rozwoju modelu zakłada stopniowe „zagęszczanie” informacji – ale w różnych obszarach w różnym tempie. Bryła i funkcja dojrzewają wcześniej, detale montażowe i dane serwisowe – zwykle później. Próba rozwijania wszystkiego równolegle jest jednym z głównych źródeł przeładowanych, a mimo to niekompletnych modeli.

Segmentacja modelu – co rozwijać szybko, a co celowo opóźnić

Zamiast podnosić LOD „po całości”, sensownie jest podzielić model na logiczne segmenty i dla każdego przyjąć inną krzywą rozwoju. W praktyce mogą to być:

  • strefy funkcjonalne (np. część biurowa, techniczna, handlowa),
  • systemy (np. konstrukcja szkieletowa, elewacje, HVAC, SSP),
  • obszary ryzyka (szachty, węzły konstrukcyjno-instalacyjne, przestrzenie o skomplikowanej geometrii).

Dla niektórych segmentów przyjmuje się agresywny wzrost LOD już w PB (np. kluczowe węzły konstrukcyjne), dla innych wręcz odwrotnie: model jest możliwie prosty aż do momentu wyboru wykonawcy lub producenta (np. Elewacje systemowe, zabudowy wnętrz). Wymaga to dyscypliny, ale znacząco redukuje liczbę prac wykonywanych „na ślepo”.

Stopniowe podnoszenie LOG i LOI – dwa różne tempo

W praktyce LOG i LOI rzadko rosną w tym samym tempie. Typowy wzorzec wygląda mniej więcej tak:

  • Wczesne etapy – LOG umiarkowany, LOI niski; liczy się kształt, relacje, strefy.
  • Środek projektu – LOG w newralgicznych miejscach rośnie (koordynacja), LOI dla elementów kosztotwórczych podnoszony stopniowo (analizy finansowe).
  • Końcowe fazy projektowania i realizacji – LOG stabilizuje się (duże zmiany są ryzykowne), LOI nadal rośnie, zwłaszcza w obszarze danych serwisowych i eksploatacyjnych.

Błędem jest forsowanie bardzo wysokiego LOG w całym modelu zbyt wcześnie, przy wciąż zmiennych założeniach funkcjonalnych. Dopóki decyzje co do układu przestrzennego nie są stabilne, rozbudowana geometria zwykle oznacza jedynie więcej pracy przy każdej iteracji.

Odkładanie detalu na później – gdzie to działa, a gdzie nie

Nie każde uproszczenie jest bezpieczne. Są obszary, w których świadome „opóźnienie” detalu daje duże oszczędności i niewielkie ryzyko, oraz takie, gdzie brak szczegółowości mści się na budowie.

Przykładowo:

  • Bezpieczne odkładanie detalu – umeblowanie, zabudowy g-k, częściowo instalacje elektryczne w strefie sufitów, niekonstrukcyjne ścianki działowe w aranżacjach najemców, elementy wyposażenia wnętrz.
  • Ryzykowne odkładanie detalu – węzły konstrukcyjno-instalacyjne, strefy pożarowe i dymowe, przejścia instalacji przez przegrody o wymaganiach ogniowych i akustycznych, przestrzenie o ograniczonej wysokości technicznej.

Jeśli w tych „wrażliwych” obszarach LOG nie zostanie podniesiony odpowiednio wcześnie, koordynacja na modelu będzie iluzoryczna – wszystko „się mieści”, dopóki średnice, grubości izolacji i dokładne trasy nie są odzwierciedlone w 3D.

Strategia archiwizacji i „odchudzania” modelu

Model, który rośnie bez kontroli, prędzej czy później staje się mało użyteczny operacyjnie. Dlatego oprócz planu rozwoju potrzebna jest też strategia „odchudzania” – określenie, które elementy i informacje można zamrozić lub zarchiwizować poza głównym modelem.

Praktyczne zabiegi to m.in.:

  • utrzymywanie osobnych modeli dla wizualizacji marketingowych i dla koordynacji technicznej,
  • archiwizacja starszych wersji modelu w CDE i praca na wersji „roboczej” z ograniczonym poziomem detalu geometrycznego dla elementów nieaktywnych projektowo,
  • wprowadzenie reguł usuwania lub zastępowania ciężkich rodzin obiektami uproszczonymi po zakończeniu konkretnego etapu (np. po przetargu na wyposażenie).

Brak takich reguł kończy się modelami, które świetnie wyglądają na pokazach, ale są praktycznie nieużywalne przy codziennej pracy projektowej czy przeglądach koordynacyjnych.

Dobór LOD do narzędzia – Revit, Archicad, Tekla i reszta ekosystemu

Różne narzędzia, różne „naturalne” poziomy geometrii

System LOD często tworzony jest abstrakcyjnie, bez odniesienia do możliwości i ograniczeń konkretnych narzędzi. Tymczasem każde środowisko ma swoje „naturalne” poziomy szczegółowości, których przekraczanie szybko staje się nieopłacalne.

Przykładowo:

  • Revit / Archicad – optymalnie radzą sobie z geometrią budynków na poziomie projektu budowlanego i wykonawczego, ale przy bardzo detalicznej geometrii producentów (śruby, uszczelki, frezy) pliki łatwo puchną.
  • Tekla Structures – idealna do wysokiego LOG elementów stalowych i żelbetowych, ale wizualne detale architektoniczne nie są jej mocną stroną ani celem.
  • Narzędzia instalacyjne (np. Revit MEP, MagiCAD) – dobrze obsługują precyzyjną geometrię instalacji, o ile rodziny są zoptymalizowane i spójne; zbyt dekoracyjne biblioteki producentów potrafią tu zablokować pracę całego zespołu.

Dopasowanie LOD do roli modelu w procesie

Te same narzędzia mogą generować modele o bardzo różnej funkcji: koncepcyjne, koordynacyjne, wykonawcze, produkcyjne, FM. Każdy z tych modeli „lubi” inny LOD. Próba zrobienia jednego supermodelu „do wszystkiego” kończy się zwykle przerośniętym plikiem, którego nikt realnie nie aktualizuje.

Praktyczniejsze jest zaplanowanie kilku ról modelu i pod nie dobrać zakres LOG/LOI oraz właściwe narzędzie:

  • Model projektowy / koordynacyjny – Revit, Archicad, narzędzia MEP; LOG umiarkowany do wysokiego w strefach ryzyka, LOI skoncentrowane na parametrach technicznych i powierzchniach.
  • Model produkcyjny / warsztatowy – Tekla, Advance Steel, narzędzia prefabrykacji; wysoki LOG, selektywny LOI (dane potrzebne do produkcji, niekoniecznie do FM).
  • Model „as-built” / FM – często uproszczony geometrycznie, ale z wysokim LOI; niekiedy zbierany w osobnym środowisku CAFM/CMMS, a nie w narzędziu projektowym.

Kluczowe jest doprecyzowanie, który model jest „wiodący” do jakiego typu decyzji. Jeśli model warsztatowy ma służyć tylko do produkcji, nie ma sensu wtłaczać w niego pełnego LOI na potrzeby FM. Z kolei model FM nie musi znać każdej śruby – istotne są identyfikatory, lokalizacja, parametry serwisowe.

Granice opłacalnego LOG w poszczególnych środowiskach

LOI skaluje się w miarę liniowo – dopisywanie parametrów obiektom jest kosztowne, ale przewidywalne. LOG ma natomiast bardzo nierówną „krzywą kosztu”. Od pewnego momentu każdy dodatkowy detal mocno obciąża model.

Typowe granice (z dużym uproszczeniem):

  • Revit / Archicad – detale na poziomie elementu budowlanego (słup, belka, panel, okno), ale bez przenoszenia pełnego detalu warsztatowego (śruby, zbrojenie pręt po pręcie) do modelu głównego.
  • Tekla – bardzo wysoki LOG konstrukcji jest naturalny, jednak detal architektoniczny lepiej pozostawić w programie architektonicznym i wymieniać go przez IFC, zamiast próbować odwzorowywać całą architekturę w Tekli.
  • Narzędzia instalacyjne – dokładne trasy, średnice, kształtki są zasadne, ale wnętrza urządzeń (wirniki, wymienniki, listwy zaciskowe) nie wnoszą nic do koordynacji, a potrafią „zabić” wydajność.

Wyjątki się zdarzają, głównie przy prefabrykacji i projektach o wysokiej powtarzalności. Tam wysoki LOG już na etapie głównego modelu bywa opłacalny, bo przekłada się na automatyzację produkcji. Przy typowej kubaturze jest to jednak raczej wyjątek niż reguła.

Rodziny, obiekty, komponenty – jak nie wpuścić „bombie LOD” do modelu

Najczęstsze problemy z przeładowanym LOD wynikają nie z decyzji o standardzie, tylko z bezrefleksyjnego używania bibliotek producentów. Jeden „ładny” klimakonwektor z kilkudziesięcioma zaokrągleniami i śrubkami potrafi być cięższy niż cała kondygnacja instalacji.

Aby uniknąć takiej sytuacji, potrzebne są konkretne zasady:

  • Polityka rodzin / obiektów – przed startem projektu ustala się kryteria dopuszczania rodzin do modelu (maksymalna złożoność geometrii, ograniczenie liczby zagnieżdżonych elementów, zakres parametrów).
  • Wersje „light” obiektów producentów – jeśli producent dostarcza tylko ciężkie modele, zespół BIM przygotowuje wersję uproszczoną (z zachowaniem kluczowych wymiarów i parametrów).
  • Testowanie wydajności – nowe typy rodzin sprawdza się na wydzielonym modelu testowym; jeśli plik gwałtownie rośnie, rodzina wraca do optymalizacji.

Na jednym z projektów centrali biurowej zastosowanie oryginalnych modeli opraw oświetleniowych „prosto od producenta” skończyło się tym, że plik Revita nie chciał się otworzyć na stacjach roboczych podwykonawcy. Wersja „light” opraw, zredukowana do prostego prostopadłościanu z poprawnymi wymiarami i parametrami, rozwiązała problem – a koordynacja i tak nie wymagała finezyjnej geometrii.

Konwersje międzyformatowe a utrata lub „fałszywe” podniesienie LOD

Przesyłanie modeli między narzędziami (IFC, dwukierunkowe pluginy) zmienia nie tylko strukturę danych, ale także faktyczny LOD. Często pozornie szczegółowy model po imporcie okazuje się „martwą geometrią” bez parametrów albo przeciwnie: prosty model zostaje „rozbity” na tysiące elementów i formalnie wygląda na bardziej szczegółowy, choć informacyjnie nie wnosi nic więcej.

Spotykane problemy:

  • Utrata LOI – mapowanie parametrów nie jest poprawnie skonfigurowane i po imporcie do innego narzędzia obiekty mają tylko nazwę i kilka ogólnych pól.
  • Nadmierny rozpad geometrii – prosty panel elewacyjny z Revita staje się w IFC wieloma bryłami, każda liczona jako osobny element, co sztucznie zawyża liczbę obiektów i utrudnia filtrowanie.
  • Brak spójnych klasyfikacji – obiekty w różnych narzędziach mają inne kody i typy, przez co trudno je powiązać w analizach.

Żeby LOD zachował sens po konwersji, nie wystarczy „eksport do IFC”. Potrzebne są przetestowane zestawy mapowań, wspólny system klasyfikacji (Uniclass, Omniclass, CCS lub lokalne rozwiązania) oraz kontrola jakości wymiany – najlepiej na fragmencie modelu, zanim uruchomi się masową wymianę.

LOD a widoki, poziomy szczegółowości i szablony w programach

Samo narzędzie często oferuje kilka poziomów prezentacji: „coarse / medium / fine” w Revicie, różne poziomy detalu widoku w Archicadzie, filtry i style wizualne w narzędziach instalacyjnych. To ważne, bo LOD modelu (realna złożoność obiektu) to jedno, a poziom prezentacji na widoku to drugie.

Bez dyscypliny powstaje klasyczny chaos: ten sam model w jednym biurze „ma LOD 300”, w drugim „LOD 400”, a w praktyce różnica polega tylko na tym, że ktoś włączył widok „fine” i detale 2D. Żeby uniknąć mylenia obu poziomów, przydają się proste reguły:

  • Opis w BEP: co oznacza LOD obiektu, a co jest tylko ustawieniem widoku; LOD odnosi się do rzeczywistej informacji i geometrii zapisanej w obiekcie, niezależnie od tego, jak jest wyświetlany.
  • Szablony widoków: predefiniowane zestawy (koordynacja, architektura, instalacje, detale) z jasnym opisem, kiedy których używać.
  • Zakaz maskowania LOD 2D: używanie nadmiaru linii 2D i detali w widokach tworzonych z modelu maskuje faktyczny poziom LOD i utrudnia ocenę jakości modelu.

Model, który wygląda na bardzo „dopieszczony” na rzutach dzięki dodatkom 2D, w koordynacji 3D szybko ujawnia realną dokładność LOG. Lepiej od razu założyć, że to 3D jest punktem odniesienia, a detale 2D – jedynie pomocą graficzną.

Scenariusze pracy mieszanej – jak dzielić odpowiedzialność za LOD między narzędzia

W większych inwestycjach rzadko udaje się pracować w jednym środowisku. Architekt, konstruktor, branże instalacyjne, prefabrykatorzy, dostawcy technologii – każdy ma własne preferencje i ograniczenia. Bez jasnego podziału ról w zakresie LOD kończy się to sytuacją, w której kilka zespołów równolegle modeluje ten sam element z różnym poziomem szczegółowości.

Przejrzystszy jest układ, w którym określa się:

  • Model „master” danego systemu – np. konstrukcja żelbetowa w Tekli, HVAC w Revit MEP; tylko ten model jest referencją dla pozostałych.
  • Zakres powielanej geometrii – architekt przenosi do swojego modelu jedynie uproszczoną wersję konstrukcji (np. bryły nośne), a nie pełny detal warsztatowy.
  • Przepływ zmian – zmiana w modelu „master” jest synchronizowana do reszty zespołów określoną ścieżką, a nie „ręcznym” poprawianiem wszystkiego wszędzie.

Bez tego powstają sprzeczne informacje: jedna wersja modelu wskazuje np. inny przekrój belki niż druga. Przy wysokim LOG i średnim nadzorze nad wersjami łatwo wtedy o kosztowne błędy wykonawcze.