Rysunki elewacji muszą pokazywać poziomy stropów, wysokości otworów i istotne wysokości dachu, zawsze w ten sam sposób. Gdy model się zmienia, te liczby też muszą się zmienić.
Tworzę własne narzędzia do Revita z pomocą Codex, agenta AI do pisania kodu, na podstawie zasad rysunkowych, których używam jako projektant. To narzędzie wstawia opisy wysokości na elewacjach.
Najtrudniejsze było określenie, co oznacza każda liczba i jak polecenie ma się zachować po zmianie. Potem przetestowałem narzędzie sześć razy w Revicie. Trzy testy spełniły kryteria. Trzy tylko częściowo i to one pokazują decyzje, które jako projektant nadal muszę podejmować sam.
W tym artykule zobaczysz:
- Jak ustaliłem, skąd pochodzi każda liczba
- Jak przygotowałem testy, które nie mogły na siebie wpływać
- Dlaczego poprawny pomiar nadal nie dał opisu na rysunku
- Cztery kontrole, które możesz zastosować w każdej automatyzacji w Revicie, napisanej z AI lub bez
Jak korzystałem z Codex i co nadal decydowałem sam
Zapisane rozmowy z czasu tworzenia narzędzia pokazują kilka praktycznych problemów. W sierpniu zgłaszałem okna wybierane z innych elewacji, błędne wysokości, problemy z poziomem odniesienia i stare opisy, które zostawały po kolejnym uruchomieniu.
Te obserwacje pomogły doprecyzować wymagania. Przypominają mi też, dlaczego wiarygodnie wyglądający rysunek albo komunikat o udanym zakończeniu nie dowodzą, że automatyzacja działa poprawnie.
Pomiar, jego wybór i jego umieszczenie na rysunku wymagają osobnych kontroli.
Codex pomagał pisać i poprawiać narzędzie, przeglądać jego kod źródłowy i zapisaną historię zmian, prowadzić sesję testową w Revicie według moich instrukcji oraz przygotować ten artykuł. Pomógł też stworzyć osobny skrypt pomiarowy.
Testy pokazują decyzje, za które jako projektant nadal odpowiadam sam:
- Poziom odniesienia
- Znaczenie wysokości otworu
- Obsługiwana geometria
- Zasady widoczności
- To, co wolno zastąpić przy przebudowie opisów
Krok 1: ustal, skąd pochodzi każda liczba
Obecne narzędzie przyjmuje jako zero rzędną projektową konkretnie nazwanego poziomu wykończonej podłogi pierwszej kondygnacji. Odejmuje tę wartość od każdej rzędnej źródłowej i podaje wynik w metrach z dokładnością do trzech miejsc po przecinku.
Brak wymaganego poziomu powoduje odmowę działania. Najniższy poziom w projekcie jest opisany jako teren, co pozostaje umową przyjętą w projekcie: przy piwnicy taki opis mógłby być niewłaściwy.
W modelu testowym zero wykończonej podłogi leżało na −125 mm we współrzędnych projektu, a najniższy poziom był 335 mm niżej.
Dla okien i drzwi narzędzie odczytuje rzeczywisty obrys otworu w ścianie, w której są osadzone, przez funkcję Revit API, z której korzysta też eksport do IFC. Nie zastępuje tego obrysu prostopadłościanem ograniczającym rodziny ani parametrem wysokości.
Ściana musi spełniać obsługiwane warunki dotyczące ściany i widoku. Narzędzie wysyła też promienie testowe, żeby sprawdzić, czy coś nie zasłania otworu. Jeśli promień w coś trafi, otwór jest pomijany.
Wysokości dachu pochodzą z górnych powierzchni standardowych dachów Revita o płaskiej geometrii i prostych krawędziach. Wygenerowana powłoka wykończenia nie daje rzędnej dachu, a dolna krawędź połaci na górnej powierzchni nie wyznacza spodu okapu.
Jak testowałem narzędzie, żeby jeden test nie wpływał na drugi
Testy przeprowadziłem w Revicie 2025.1 i pyRevit 6.5.3, darmowym dodatku do uruchamiania własnych skryptów Python w Revicie. Otworzyłem odizolowaną kopię modelu, bez współdzielenia (non-workshared), pod neutralną nazwą pliku.
Po pierwszym uruchomieniu polecenia zapisałem wynik jako S1. Każdy kolejny test zaczynał się od osobnej kopii pliku S1, więc zmienione okno w jednym teście nie mogło wpłynąć na inny.
Sprawdziłem, że testy nie zmieniły oryginalnego modelu ani siedmiu plików źródłowych narzędzia: ich odciski plików (hashe) pozostały takie same. W narzędziu uruchomiłem tylko etap formatowania elewacji. Testowe zmiany geometrii modelu i niezależne pomiary wykonał osobny skrypt Revit API. Zobacz Fig. 1.
Ten skrypt dał drugi, niezależny sposób pomiaru. Odczytywał wewnętrzne krawędzie otworów bezpośrednio z geometrii ściany, zamiast korzystać z procedury samego narzędzia.
Kontrole dachu odczytywały punkty na górnych powierzchniach dachów. Zapis obejmował też typy opisów, tekst, współrzędne i zapisane identyfikatory elementów.
Te kontrole działały wewnątrz Revita. Zrzuty ekranu, eksporty widoków i pełny wynik diagnostyki zapisałem razem z pomiarami.
Model testowy miał dwa nierozwiązane linki i nieaktywne przycięcie widoku, więc te testy nie obejmują geometrii z linków ani działania przy aktywnym przycięciu.
Sześć testów w skrócie:
| Test | Co zmieniłem | Wynik |
|---|---|---|
| T1 Pierwsze uruchomienie | Nic, stare opisy były już na rysunku | Częściowo: 7 poprawnych liczb, +0,600 m pominięte z braku miejsca, żadne drzwi nie zostały przyjęte |
| T2 Ponowne uruchomienie | Nic | Spełniony: te same 7 liczb, bez duplikatów |
| T3 Wyższe okno | Jedno okno wyższe o 200 mm | Częściowo: +2,600 m odczytane poprawnie, opis nie został wstawiony |
| T4 Bliskie wysokości | Jedno z dwóch okien o tej samej górze wyższe o 100 mm | Częściowo: +2,500 m odczytane poprawnie, opis nie został wstawiony |
| T5 Podniesiony dach | Jeden dach podniesiony o 300 mm | Spełniony: +4,904 i +7,116 m, strzałki się zgadzają |
| T6 Przesunięty symbol | Symbol +2,400 m przesunięty o 1000 mm w bok | Spełniony: symbol odbudowany, ręczne przesunięcie utracone |
T1 i T2: pierwsze uruchomienie i powtórka bez zmian
Pierwsze uruchomienie dało siedem opisów liczbowych na elewacji wschodniej, której użyłem jako kontrolnej, w skali 1:82. Były wśród nich góra otworu na +2,400 m, dół otworu na +1,500 m oraz wartości dachu +4,604 i +6,816 m.
Wartości dachu odpowiadały niezależnie zmierzonym wysokościom 4,603564 i 6,816194 m nad zerem wykończonej podłogi. Wszystkie siedem grotów strzałek zgadzało się z przedstawianymi wysokościami w granicach zaokrąglenia.
Jednak zaakceptowany kandydat dołu otworu +0,600 m został pominięty z braku miejsca na rysunku, a na testowanych elewacjach nie przyjęto żadnego kandydata drzwi zewnętrznych.
Opisy istniały już przed uruchomieniem, więc było to przebudowanie, a nie dowód tworzenia opisów od zera w czystym modelu.
Następnie uruchomiłem polecenie ponownie, bez zmian w modelu. Usunęło opisy, które wcześniej narysowało, i narysowało je jeszcze raz: te same siedem liczb w tych samych miejscach. Nowe były tylko identyfikatory elementów Revita.
Narzędzie prowadzi listę elementów, które utworzyło w każdym widoku. Przed ponownym uruchomieniem i po nim lista miała 54 pozycje. Nie zostały żadne stare elementy, a łączna liczba elementów nie wzrosła. W praktyce dwukrotne uruchomienie polecenia nie mnoży duplikatów.
To potwierdza powtarzalność dla tego stanu wyjściowego. Nie usuwa jednak odziedziczonych pominięć i nie dowodzi, że każdy ręczny opis jest chroniony. Zobacz Fig. 2.
T3 i T4: poprawne wysokości, ale bez nowego opisu
Zmiana okna ujawniła zależność między geometrią a widocznością.
W T3 jedno okno stało się wyższe o 200 mm. Niezależna kontrola potwierdziła, że dół otworu został na +1,500 m, a góra przesunęła się z +2,400 na +2,600 m.
Polecenie odczytało te wysokości poprawnie. Ale kontrola widoczności odrzuciła zmieniony otwór, bo promień testowy trafił w istniejącą, wygenerowaną okładzinę elewacji. Opis +2,600 m nie został wstawiony.
Pozostała liczba +2,400 m nadal opisywała inne okna. Generator okładziny był poza zakresem tego testu, więc ten wynik nie dowodzi, że ponowne wygenerowanie okładziny rozwiązałoby problem. Zobacz Fig. 3.
T4 miał podobne ograniczenie.
Dwa otwory okienne miały początkowo wspólną górę na +2,400 m. Gdy jedno okno stało się wyższe o 100 mm, a dół jego otworu został na +0,600 m, powstała rzeczywista góra na +2,500 m, a drugie okno się nie zmieniło.
Obie wysokości pojawiły się poprawnie w tabeli diagnostycznej, ale zmienione okno znów zostało odrzucone z powodu okładziny. Rysunek nie pokazał więc dwóch osobnych opisów bliskich wysokości.
Starsza wersja kodu łączyła wysokości różniące się o mniej niż 180 mm. Obecna zasada łączy tylko wysokości, które zostałyby wydrukowane jako ta sama liczba. Ten test nie może potwierdzić umieszczania opisów według nowej zasady, bo kontrola widoczności najpierw odrzuciła jedno okno. Zobacz Fig. 4.
T5: dach się przesunął, a liczby razem z nim
Zmiana dachu dała przykład udanej aktualizacji.
Podniesienie jednego dachu o 300 mm przez odsunięcie od poziomu zmieniło niezależnie zmierzoną dolną krawędź i najwyższą wysokość dokładnie o tę wartość.
Przed ponownym uruchomieniem tekst nadal pokazywał +4,604 i +6,816 m. Po uruchomieniu polecenia pokazywał +4,904 i +7,116 m, a wysokości strzałek się zgadzały.
Elewacja miała teraz osiem opisów liczbowych, a trzech innych kandydatów pominięto z braku miejsca.
To potwierdza testowaną aktualizację dachu, ale pełne ponowne generowanie wykończenia dachu i dowolne kształty dachów pozostają poza tym, co testy dowiodły. Zobacz Fig. 5, Fig. 6.
T6: ręczne poprawki wygenerowanych symboli przepadają
Symbole pokazują, dlaczego ponowne uruchomienie ma znaczenie. Każdy symbol wysokości składa się z dwóch notatek tekstowych i czterech linii detalu, z dodatkowymi liniami pomocniczymi tam, gdzie są obsługiwane. Nie są to rzędne wysokościowe Revita (Spot Elevations), które aktualizują się same razem z modelem. Zmieniają się tylko wtedy, gdy ponownie uruchomisz polecenie.
W ostatnim teście osobny skrypt przesunął wszystkie sześć części symbolu +2,400 m o 1000 mm w bok, bez zmiany modelu.
Ponowne uruchomienie usunęło stare elementy utworzone przez narzędzie i przywróciło obliczony układ. Nie zostały żadne przesunięte fragmenty.
Ręczna poprawka projektanta w wygenerowanej grafice nie przetrwa więc tej przebudowy. Zobacz Fig. 7, Fig. 8.
Uwaga: polecenie zmienia więcej niż symbole wysokości
Polecenie sięga dalej niż jeden symbol. Wybrany etap obsługuje też przekroje, legendy, tła, zakończenia osi i inne układy widoków architektonicznych.
Raport z pierwszego uruchomienia odnotował też usunięcie jednego widoku 3D z arkusza tytułowego.
Uwaga: kod zawiera zasady porządkowania elewacji, które mogą usuwać standardowe rzędne wysokościowe Revita (Spot Elevations), także te wstawione ręcznie.
Na moich testowych elewacjach nie było rzędnych wysokościowych ani przed testami, ani po nich, więc nie widziałem, żeby to się stało. To ryzyko wynika z analizy kodu, a nie ze zmierzonej straty. Jeśli budujesz podobne narzędzie, sprawdź, co wolno usuwać jego krokowi porządkowania.
Co zabrać do własnej automatyzacji w Revicie
Trzy testy spełniły kryteria: powtórka bez zmian, aktualizacja dachu i odbudowany symbol.
Trzy częściowo: pierwsze uruchomienie i oba testy okien.
Polecenie nie zgłosiło błędów, ale wykluczenia i pominięcia w układzie nadal wpłynęły na wynik. Nie mam zmierzonej oszczędności czasu ani ogólnego wskaźnika niezawodności dla tego przypadku.
Testy dały mi jaśniejszy sposób pracy. Oto cztery kontrole, które możesz zastosować we własnym narzędziu:
- Określ źródło geometryczne. Ustal, z którego elementu i której powierzchni pochodzi każda liczba, na przykład z otworu w ścianie, a nie z prostopadłościanu ograniczającego rodziny.
- Czytaj diagnostykę. Poprawny pomiar wciąż może zostać odrzucony, jak w T3 i T4.
- Uruchamiaj ponownie po zmianach. Opisy to zwykły tekst i linie, więc same się nie aktualizują.
- Przeglądaj zmienione rysunki. Polecenie zmienia też inne widoki, a ręczne poprawki zostają nadpisane.
Osobista automatyzacja staje się użyteczna, gdy te decyzje są na tyle jasne, że da się je przetestować, a jej ograniczenia pozostają widoczne przy przeglądzie rysunków.
Jeśli chcesz zbudować własne narzędzie do Revita z AI, zacznij od zasad, nie od kodu. Testuj jedną zmianę naraz na kopii modelu i sprawdzaj rysunek, nie tylko komunikat o sukcesie.
Ten artykuł jest wpisem gościnnym na blogu BIM Corner, napisanym przez Andreya Kechina.
