← Wizualizacje i wycenaDokumentacja wykonawczaSpacer

Jak powstaje model, rendery, spacer i dokumentacja

Wszystko w tym projekcie jest generowane programami z jednego zestawu wymiarów. Nie ma ręcznie modelowanej sceny ani ręcznie rysowanych rzutów: zmiana jednej liczby (np. głębokości blatu) przechodzi automatycznie przez model, rendery, spacer, rzut, wycenę i rysunki wykonawcze. Pracę wykonuje Claude (asystent AI) — pisze i uruchamia skrypty, ogląda wyniki i poprawia je; decyzje projektowe podejmuje właściciel.

Wspólną część — liczenie w chmurze, wypalanie i przeglądarkę spaceru, rysunki, druk, wersje — biuro dzieli z innymi projektami wnętrz w silniku vistelier. Tutaj jest to, co dotyczy biura; opis samego silnika: Wspólny silnik.

1. Źródła wymiarów

• Model SketchUp właściciela (eksport COLLADA .dae, całe piętro). Nie jest importowany do Blendera — importer źle ustawia komponenty SketchUpa. Zamiast tego krótki program w Pythonie (numpy) czyta plik, wylicza położenia ścian, okna, drzwi, słupa i ścianki kolankowej i z nich powstają stałe w scenie.
• Plany budowlane (rzut poddasza, przekrój A-A w PDF): z nich położenie i wymiar okna dachowego 78 × 160 oraz wysokość jego dolnej krawędzi. PDF jest rasteryzowany (pdftoppm) i mierzony w skali 1:50.
• Informacje od właściciela: grzejnik (góra 75 cm, odstaje 15 cm), pudła szafek 85 × 60 × 92, wzrost 172 cm → blat 72 cm, kierunek otwierania drzwi i okna, zdjęcia lampy i klimatyzatora. Wymiary niepewne są oznaczone w dokumentacji gwiazdką.

2. Model 3D (Blender, skrypt)

• Blender 4.2 bez okna (blender -b -P scene.py). Scena jest za każdym razem budowana od zera z prostopadłościanów, walców, brył z przekroju (skos, okno dachowe) i kilku modeli roślin z darmowej biblioteki Poly Haven (licencja CC0).
• wymiary.py — jedyne źródło wymiarów (pokój, blaty, wycięcie, konsole, szafki, okna). Czytają je model, rzut i dokumentacja wykonawcza, więc zmiana jednej liczby nie wymaga poprawiania kilku plików.
• scene.py — pokój: ściany, skos, okna, drzwi, podłoga z desek, lamele, grzejnik, materiały, światło dzienne (model nieba Nishita), kamery.
• lab.py — wyposażenie: blaty bez nóg z konsolami, ALEX-y, szafki z szufladami (puste korpusy z prawdziwymi skrzynkami szuflad i zawartością), BESTÅ, drukarka z podajnikiem, stanowiska komputera i lutowania, rośliny, rozsady, lampy i taśmy LED. Każdy mebel to funkcja z parametrami (np. pudlo(x, y, fronty)), więc przesunięcie albo zmiana wymiaru to jedna liczba.
• Materiały są proceduralne: drewno ze słojami z szumu, z przesunięciem na każdą deskę i lamelę; reszta to kolory, szorstkość i metaliczność.
• Światło w grupach: dzień, lampa (szyna z reflektorami), taśmy LED, światło robocze — każdą grupę da się włączyć osobno.

3. Rendery

• Silnik Cycles (śledzenie promieni), 384 próbki na piksel, 2400 × 1500, odszumianie OpenImageDenoise, mapowanie tonów AgX jak w Blenderze.
• Szybkie podglądy (1200 × 750, 24–48 próbek) też liczą się w chmurze, żeby nie obciążać laptopa — do oceny zmian przed decyzją.
• Pełne rendery liczą się w chmurze (RunPod, karta NVIDIA RTX A6000 lub A40, ok. 0,59 $/h) jednym poleceniem deploy/chmura/chmura.py uruchamianym przez silnik (silnik/vistelier cloud): zakłada maszynę, wysyła spakowaną scenę, instaluje Blendera, renderuje na karcie (OptiX), pobiera wyniki i zawsze usuwa maszynę (także po błędzie). 14 kadrów ≈ 9 minut, z wypalaniem spaceru ≈ 30 minut.
• Rzut z góry to render z kamery ortogonalnej (bez sufitu), na który plan.py nakłada numery, wymiary pokoju, legendę i listę zakupów jako SVG; PNG robi przeglądarka Chromium bez okna.

4. Spacer 3D

Wypalanie (Blender, w chmurze)

• Ten sam model jest łączony w kilka dużych obiektów („atlasów”): skorupa pokoju, trzy atlasy mebli i jeden z ruchomymi frontami. Każdy dostaje rozwinięcie UV (smart_project + gęste upakowanie wysp), żeby meble oglądane z bliska miały ok. 300 pikseli światła na metr.
• Kolor powierzchni wypalany jest do tekstury 4096 px (skorupa) / 2048 px (meble).
• Światło każdej grupy osobno (dzień, lampa, taśmy, robocze): Cycles, 2048 próbek (dzień 4096), zapis w liczbach zmiennoprzecinkowych, odszumianie. Fronty szuflad i drzwiczek są dla promieni niewidoczne — wnętrza szafek mają światło jak przy otwartych.
• Atlasy są potem cięte z powrotem na nazwane elementy (np. „Szafki BESTÅ nad ramieniem”), żeby w przeglądarce dało się je przemalować, przesunąć albo ukryć. Eksport: glTF (biuro.glb) + opis (walk.json: elementy, ruchome fronty z osią obrotu lub wektorem wysuwu, siatka kolizji 5 cm, miejsca).

Obróbka (build_spacer.py)

• Mapy światła są wygładzane tylko w obrębie jednej wyspy UV i jednego kierunku powierzchni (żeby ciemny spód blatu nie przeciekał na wierzch), barwa światła mocniej niż jasność.
• Zapis do JPEG w skali logarytmicznej (11 przesłon na 8 bitach, z drobnym szumem zamiast pasów) — kilkadziesiąt MB zamiast setek.

Przeglądarka (three.js)

• Własny shader: kolor × suma włączonych grup światła × ekspozycja, potem AgX. Przełączanie świateł jest płynne i nie wymaga liczenia czegokolwiek na telefonie.
• Chodzenie po siatce kolizji (klawiatura, mysz, na telefonie drążek), przeskoki do miejsc, minimapa.
• Dotknięcie frontu otwiera szufladę lub drzwiczki (animacja wokół osi zapisanej przy wypalaniu), dotknięcie lampy ją włącza.
• Panel „Zmiany” (kolor z zachowaniem faktury, przesunięcie, obrót, ukrycie — zapamiętane w przeglądarce) i „Warstwy”.
• Lektor: teksty stref napisane przez Claude, nagrane syntezą mowy Google Gemini (głos Puck), sprawdzone automatyczną transkrypcją (Whisper); odtwarzane po wejściu w strefę z napisem na ekranie.

Ograniczenie: spacer ma światło „namalowane” na teksturach, więc nie dorównuje renderom (brak odbić, miejscami plamy przy ciemnych powierzchniach). Służy do sprawdzania układu i interakcji; o wyglądzie mówią rendery.

5. Dokumentacja wykonawcza

• wykonawcza.py ma własny, jawny zestaw wymiarów w centymetrach (pokój, blaty, wycięcie, konsole, szafki, fronty) — te same co w modelu, ale zapisane tak, jak się je mierzy i tnie (np. luzy 5 mm przy ścianach, zapas na docięcie).
• Z nich program rysuje arkusze SVG: rzut z wymiarami (W-01), rozkrój desek i łączenia (W-02), podpory z przekrojem (W-03), widok ściany wschodniej (W-04), zabudowę przy drzwiach z frontami (W-05). Linie wymiarowe, opisy i legendy są generowane, nie rysowane ręcznie.
• Tabele (skrzynki szuflad, materiały, kolejność prac, pomiary) liczą się z tych samych stałych, np. szerokość skrzynki = światło pudła − 2 × prowadnica.
• PDF A3 drukuje Chromium bez okna z tej samej strony HTML.
• Rysunki są przeglądane przez Claude jako obrazy (nachodzące napisy, błędne strony, kolizje) — tak wyszła np. kolizja szuflady z regałem na rozsady.

Uwaga: rozstaw i przekroje konsol to propozycja, nie obliczenie konstrukcyjne; wymiary oznaczone gwiazdką trzeba zmierzyć na miejscu.

6. Powtarzalność i publikacja

• Cały kod jest w prywatnym repozytorium git (GitHub gutt/biuro) z opisem w README; wyniki (rendery, spacer) nie są w nim trzymane, bo da się je odtworzyć.
• Kolejność jest stała: zmiana w wymiary.py / lab.py → szybki podgląd w chmurze → chmura.py (rendery i spacer) → build.sh (rzut, strona, dokumentacja z PDF, wgranie).
• Przy porządkowaniu kodu sprawdzane jest, że scena się nie zmieniła: „odcisk” (położenie, wymiar i materiał każdego z ok. 830 obiektów) przed i po musi być identyczny, a rysunki wykonawcze — bajt w bajt takie same.
• Wynikiem są zwykłe pliki (HTML, JPG, SVG, PDF, glTF). Serwer two71.io podaje je z małego kontenera Caddy; adresy mają numer wersji, żeby telefon nie pokazywał starej wersji z pamięci.
• Pliki trafiają na serwer jednym poleceniem (archiwum tar przez SSH).

Narzędzia