Artykuł · · 7 min czytania
Opus 5.5 i Blender na RTX 3060: Porsche 911 z kodu, wideo i rachunek za tokeny
Do mojego home labu doszła karta NVIDIA RTX 3060 z 12 GB pamięci. Zanim zaprzęgłem ją do czegoś poważniejszego, chciałem sprawdzić trzy rzeczy: jak Claude Opus 5.5 w Claude Code poradzi sobie z Blenderem, jak w praktyce wygląda wymiana między modelem a programem do grafiki 3D i ile tokenów to zużyje. Zadanie: zbudować jak najbardziej szczegółowe Porsche 911, wyrenderować je i zrobić wideo, na którym kamera okrąża auto.
Miałem też własny powód: modele narzędzi do mojego symulatora śladów narzędzi powstają w Blenderze i chcę, żeby były dokładniejsze wizualnie. Chciałem wiedzieć, ile takiej pracy mogę przekazać Opusowi.
Po jednej sesji mam model generacji 992 złożony ze 186 obiektów, sześć renderów w 1080p i zapętlone wideo. Opus nie dotknął interfejsu Blendera: wszystko powstało z kodu Pythona, który wysyłał do działającego programu. Sesja zużyła około 17,6 mln tokenów, co w cenniku API oznacza mniej więcej 8,5 USD.
Jak Opus rozmawia z Blenderem
Łącznikiem jest oficjalny serwer Blender MCP z Blender Lab, w wersji 1.0.3 (projects.blender.org/lab/blender_mcp). MCP (Model Context Protocol) to standard, przez który agent dostaje dodatkowe narzędzia; tutaj tym narzędziem jest wykonywanie kodu w Blenderze. Projekt ma dwie części:
- dodatek do Blendera, który otwiera gniazdo TCP na
localhost:9876i wykonuje przysłany kod Pythona, - serwer MCP (
blender-mcp), który Claude Code uruchamia jako osobny proces i który przekazuje żądania do tego gniazda.
Poza wykonywaniem kodu serwer udostępnia podsumowania obiektów sceny, zrzuty ekranu interfejsu, szybki render podglądu oraz wyszukiwanie w dokumentacji API Pythona i w podręczniku Blendera, dołączonych do pakietu. To ostatnie ma znaczenie praktyczne: API Blendera zmienia się między wersjami, a model sięga wtedy do dokumentacji tej samej wersji, zamiast polegać na pamięci. Istnieje też starszy, popularny projekt społecznościowy o podobnej nazwie, ale to integracja zewnętrzna, nie od twórców Blendera.
Do samego Blendera nie potrzebowałem żadnego skilla Claude Code, czyli spakowanego zestawu instrukcji do konkretnego rodzaju zadań. Wystarczyły MCP i zwykła powłoka. Skill przyda się dopiero teraz, jako miejsce na pułapki opisane niżej, żeby następna sesja nie odkrywała ich od nowa.
Opus zainstalował wszystko sam, z wiersza poleceń. Najpierw dodatek, bez otwierania interfejsu:
blender --command extension install-file -r user_default -e mcp-1.0.3.zip
Dodatek uruchamia gniazdo przy starcie Blendera, ale tylko wtedy, gdy w preferencjach włączono Online Access; bez tego zgłasza błąd, mimo że łączy się wyłącznie z localhostem, bo autorzy dodatku traktują każde gniazdo sieciowe jako dostęp do sieci. Potem serwer MCP, zainstalowany przez uv i zarejestrowany w Claude Code:
uv tool install ./blender-mcp-server
claude mcp add blender -s user -- ~/.local/bin/blender-mcp
Claude Code wczytuje nowe serwery MCP dopiero po restarcie. Żeby nie przerywać sesji, Opus napisał piętnastolinijkowy klient w Pythonie, który mówi tym samym protokołem co serwer: wysyła do gniazda JSON z polem code zakończony bajtem zerowym i odczytuje z odpowiedzi słownik result, który skrypt ustawia na końcu. W tej sesji cała praca szła przez ten klient: Opus wysyłał gotowy kod Pythona, a z narzędzi serwera MCP, w tym z wyszukiwania w dokumentacji, nie korzystał. API Blendera znał z własnej wiedzy, a błędy poprawiał na podstawie komunikatów zwracanych przez Blendera.
Jedno ostrzeżenie z dokumentacji projektu: dodatek wykonuje dowolny kod przysłany przez model i nie ma zabezpieczeń przed usunięciem lub wysłaniem danych. Blender Lab zaleca maszynę wirtualną albo komputer bez wrażliwych danych.
Co Opus zbudował
Pierwsza próba była prostym, kanciastym coupé. Gdy poprosiłem o bardzo szczegółowe Porsche, Opus zmienił podejście: model jest zbiorem skryptów, a nie ręcznie wyrzeźbioną siatką. Po każdej zmianie cała scena odbudowuje się w około 12 sekund, a kształt auta zmienia się przez edycję tabel liczb.
Nadwozie powstaje z przekrojów. Dla kolejnych położeń wzdłuż auta tabele podają połowę szerokości, wysokość linii dachu, położenie i wysokość grzbietu błotnika oraz linię okien. Każdy przekrój ma tę samą liczbę punktów, więc sąsiednie przekroje łączą się w regularną siatkę czworokątów, a modyfikator subdivision wygładza ją w ciągłą powierzchnię. Charakterystyczny kształt 911 pojawił się, gdy grzbiety przednich błotników znalazły się wyżej niż środek maski.
Detale nie mają wpisanych współrzędnych. Skrypt rzuca promienie na wygładzoną powierzchnię i umieszcza obiekty w punktach trafienia, zgodnie z normalną. Tak powstają szyby, szczeliny drzwi i pokryw, klosze reflektorów, tylna listwa świateł i lamele kratki silnika. Gdy zmienia się bryła, detale same się do niej dopasowują.
Nadwozie jest skorupą o grubości 6 mm, a wszystkie otwory wycina jedna operacja logiczna z kolekcją brył tnących: nadkola, okna, wloty powietrza i gniazda reflektorów. Dzięki temu przez szyby widać fotele, deskę z ekranami i kierownicę. Koła powstają raz, z oponą z rowkami bieżnika, felgą o pięciu podwójnych ramionach, nawiercaną tarczą i zaciskiem z napisem, a potem są wstawiane czterokrotnie jako instancje kolekcji.
Opus ogląda własne rendery
Najciekawsza część interakcji to pętla: kod, render, oglądanie. Po każdej zmianie Blender w tle renderował cztery ujęcia w połowie rozdzielczości (64 próbki, około 11 sekund na ujęcie), skrypt sklejał je w jeden obraz, a Opus wczytywał go do kontekstu jako obraz, oceniał kształt i szukał błędów. Kilku problemów nie dało się zobaczyć w kodzie; wyszły dopiero na obrazie:
- Czarna, poszarpana plama na nosie. Na samym czubku nosa, gdzie powierzchnia musi się zamknąć, grzbiet błotnika wciąż leżał wyżej niż środek maski, więc ostatni przekrój się załamywał. Wewnętrzna warstwa skorupy przebijała wtedy zewnętrzną. Pomogło spłaszczenie końca tabel i cieńsza skorupa.
- Kanciaste lusterka i fotele mimo zaokrągleń. Modyfikator bevel liczy szerokość zaokrąglenia przed skalowaniem obiektu. Na sześcianie o boku 1 m przeskalowanym do 8 cm zaokrąglenie 4 cm skurczyło się do około 3 mm. Rozwiązaniem było wpisanie skali w samą siatkę.
- Reflektory jak żabie oczy. Płaski dysk ustawiony stycznie do mocno zakrzywionego błotnika wystawał na brzegach. Klosz zbudowany z promieni rzucanych wzdłuż osi lampy przylega do powierzchni.
- Biały sześcian zasłaniający auto. Po ponownym uruchomieniu Blender wczytał domyślną scenę startową z sześcianem.
Takich iteracji z pełnym podglądem było pięć. Bez oglądania renderów każdy z tych błędów trafiłby do wyniku końcowego.
Render i wideo na RTX 3060
Seria renderów przez gniazdo MCP okazała się niestabilna: drugi render Cycles z rzędu w otwartym Blenderze zamknął program bez raportu awarii. Opus przeniósł renderowanie do osobnego procesu, który pracuje na zapisanym pliku:
blender -b porsche911.blend -P render_bg.py -- final 256 100 Cam_Hero Cam_Rear
Okno Blendera pozostaje wtedy dostępne, a ewentualna awaria nie zabiera sceny. Sześć zdjęć w 1920×1080 przy 256 próbkach i odszumianiu OptiX zajęło na RTX 3060 po 20–27 sekund na ujęcie.
Wideo to kamera przypięta do pustego obiektu w środku sceny, który obraca się o 360° z liniową interpolacją. Liniowe klucze są konieczne, żeby pętla nie zwalniała na początku i końcu obrotu. 240 klatek przy 128 próbkach zajęło około 21 minut, po 5,3 sekundy na klatkę. Klatki trafiały do plików PNG z opcją pomijania gotowych, więc przerwany render dałoby się wznowić.
W systemie nie było ffmpeg, więc klatki złożył w MP4 sam Blender, przez edytor sekwencji wideo. W Blenderze 5 trzeba najpierw przełączyć typ wyjścia na wideo (image_settings.media_type = "VIDEO"), a dopiero potem ustawić format FFMPEG; w odwrotnej kolejności format nie istnieje na liście. Wynik: H.264, 1920×1080, 30 klatek na sekundę. Powyżej jest jeden pełny obrót (8 sekund, około 5 MB), który przeglądarka odtwarza w pętli.
Ile tokenów to zużyło
Sumę podaję z dziennika sesji, który Claude Code zapisuje przy każdej odpowiedzi modelu. Obejmuje ona całą sesję: przygotowanie środowiska, pierwsze coupé, Porsche, rendery i wideo. Opus odpowiedział 102 razy, a tokeny rozkładają się tak:
- 17,17 mln tokenów odczytanych z pamięci podręcznej (cache),
- 0,25 mln tokenów zapisanych do cache,
- 0,16 mln tokenów wyjścia,
- 212 tokenów zwykłego wejścia, spoza cache.
Przy stawkach Claude Opus 5.5 w API (4 USD za milion tokenów wejścia, 20 USD za milion wyjścia, 0,20 USD za odczyt z cache i 8 USD za zapis do cache godzinnego) daje to około 8,54 USD. Bez cache ta sama praca kosztowałaby około 73 USD, bo każda odpowiedź wysyła ponownie całą rozmowę, razem z kodem, logami i obrazami renderów. Renderowanie odbywało się na lokalnej karcie i nie zużywało tokenów. To wyliczenie według cennika API, a nie faktyczny rachunek: sesja szła w ramach subskrypcji.
Samo Porsche, od prośby o szczegółowy model do sześciu gotowych renderów, zajęło 28 minut, 43 odpowiedzi modelu i około 5,40 USD. Wideo zajęło kolejne 24 minuty, z czego 21 trwał render, i kosztowało około 1,10 USD.
Co z tego wynika
Model nie jest doskonały, ale jak na jedną sesję i wyłącznie kod robi spore wrażenie. To model inspirowany 992, a nie wierna replika. Nos jest za długi, wloty z przodu są prostokątne zamiast kształtów z oryginału, a numer na tablicy rejestracyjnej częściowo zapada się w zakrzywioną tablicę. Ocenę wizualną robił też sam Opus, oglądając własne rendery; to wystarczyło do wyłapania wyraźnych błędów geometrii, ale nie zastępuje oka kogoś, kto zna oryginał.
Podział pracy wyglądał tak: ja wydałem trzy polecenia (zainstaluj Blendera z MCP, zbuduj szczegółowe Porsche, zrób wideo) i niczego nie poprawiałem ręcznie. Opus pisał kod sceny, uruchamiał go, renderował podgląd, oglądał wynik i poprawiał, a RTX 3060 renderowała lokalnie. Do szkicu koncepcyjnego, sceny testowej albo animacji produktu to już wystarcza. Do wiernego odwzorowania konkretnego obiektu potrzebne będą rysunki techniczne lub skan, i tak też podejdę do modeli narzędzi w symulatorze.