Vytvořeno: 22.7.2026 | Aktualizováno: 22.07.2026 10:27
⚠ ROZPRACOVÁNO: Tento článek zatím nebyl prakticky otestován. Ověřené jsou níže označené principy vycházející z dokumentace a citovaných příspěvků; konkrétní spolehlivost, rychlost a kvalitu jednotlivých variant má teprve zjistit testovací plán. Uvedené ukázky proto nejdřív zkoušej na kopii souboru bez přístupu k citlivým datům.
Propojení AI s Blenderem lze řešit ovládáním běžného grafického rozhraní nebo integrační vrstvou nad Blender Python API. Pracovní hypotézou je hybrid: běžné změny provádět strukturovanými nástroji s přesně definovanými parametry a vizuální kontrolu zapojovat tam, kde samotná data nepopisují výsledný vzhled.
Ověřené principy:
bpy je in-process řídicí API uvnitř Blenderu, nikoli samostatný integrační kanál pro AI. AI potřebuje způsob, jak kód do Blenderu předat a spustit, například add-on, launcher, socket, API, MCP nebo zadání přes GUI.bpy a může AI zpřístupnit strukturované operace a stav scény bez klikání podle souřadnic.Zatím neověřeno:
Originální příspěvek Evy Zhang uvádí GPT-Sol, CUA a nezrychlené video. V klipu je vidět Blender 4.5.4 LTS, soubor Slop_Zoo_Cannon.blend a již rozpracovaná scéna, takže nejde o důkaz vytvoření celé scény od nuly.
Navazující příspěvek uživatele Chubby spekuloval o rychlosti 750 TPS. Brandon McKinzie údaj opravil a uvedl GPT-5.6 Sol v režimech Ultra a Fast mode, GUI přes CUA a žádné MCP ani bpy. Dokumentace Fast mode hodnotu 750 TPS pro ukázku nepotvrzuje a přehled modelů Codex popisuje Ultra jako režim využívající subagenty, ne jako samostatný model.
| Varianta | Jak ovládá Blender | Zpětná vazba pro AI | Silná stránka | Hlavní omezení |
|---|---|---|---|---|
| CUA / Computer Use | Computer-use runtime provádí myš, klávesnici a běžné GUI | Screenshoty a stav rozhraní | Nevyžaduje integraci specifickou pro Blender | Citlivost na rozložení oken, kontext, výběr a režim editoru |
Jednorázový bpy skript – deterministický baseline | Launcher spustí v Blenderu jeden vygenerovaný skript | Výstup skriptu, data scény a log | Přesně definované parametry a přímé řízení scény | bpy samo neřeší předání kódu; skript může blokovat Blender |
| MCP / API / socket bridge | Server překládá strukturované nástroje obvykle na bpy | Strukturovaný stav, chyby a volitelné náhledy | Atomické operace a přesně definované parametry | Vlastnosti závisí na konkrétní implementaci serveru |
| Hybridní pracovní hypotéza | Strukturované kroky doplněné cíleným preview nebo CUA | Data scény i cílené obrázky | Kombinuje strojovou kontrolu s kontrolou vzhledu | Přínos musí potvrdit test; složitější orchestrace |
Computer Use v Codexu umožňuje computer-using agentovi vidět a ovládat grafickou aplikaci. Nevyžaduje integraci specifickou pro Blender, ale vyžaduje computer-use runtime, pořizování screenshotů a vykonávání vrácených akcí myši nebo klávesnice. Agent proto pracuje se stejnými okny, panely, výběry, režimy a zkratkami jako člověk.
Také OpenAI Computer Use API zůstává CUA. Model dostane screenshot, vrátí akce pro myš nebo klávesnici, prostředí je provede a pošle nový screenshot. Použití API tedy screenshoty neodstraňuje a nevytváří z Blenderu strukturované doménové API; pouze programově řídí vizuální smyčku.
CUA dává smysl, když:
Nevýhodou je křehkost vůči změně rozlišení, layoutu, aktivního okna, výběru objektu a režimu Object/Edit. Každý screenshot navíc přenáší mnoho informací, které by strukturovaný dotaz na scénu vyjádřil přesněji.
Blender Python API zpřístupňuje data přes bpy.data, aktuální kontext přes bpy.context a operace přes bpy.ops. Jde o in-process API běžící uvnitř Blenderu, nikoli o síťové nebo agentní rozhraní. AI proto potřebuje integrační kanál, který kód do Blenderu předá a spustí: například pevný launcher, add-on, socket, API, MCP nebo práci přes Python Console či Text Editor pomocí GUI.
Skript může běžet v otevřeném Blenderu a měnit právě zobrazenou scénu; použití bpy tedy neznamená headless režim. MCP/API bridge obvykle používá bpy jako řídicí vrstvu uvnitř Blenderu a nad ním definuje transport, nástroje a návratové hodnoty.
Tady je minimální příklad změny scény. Jde o neotestovanou ukázku pro kopii pracovního souboru:
import bpy bpy.ops.mesh.primitive_cube_add(location=(0, 0, 1)) obj = bpy.context.active_object obj.name = "AI_Test_Cube" obj.scale = (2, 1, 0.5) bpy.context.view_layer.update()
Volání bpy.context.view_layer.update() aktualizuje dependency graph pro danou view layer, ale nevynutí překreslení viewportu. Pokud jeden dlouhý skript drží hlavní vlákno, Blender nemusí během jeho běhu zpracovat události a překreslit rozhraní. Změny dat už mohou být provedené, ale ve viewportu se projeví až po návratu skriptu.
Průběžný výsledek lze řešit dvěma způsoby:
bpy.app.timers, který provede jeden krok, vrátí řízení a naplánuje další běh.Princip krokování timerem může vypadat takto:
import bpy state = {"object": None} def add_cube(): bpy.ops.mesh.primitive_cube_add(location=(0, 0, 0)) state["object"] = bpy.context.active_object def move_cube(): obj = state["object"] if obj is None: raise RuntimeError("Cube was not created") obj.location = (0, 0, 2) steps = iter([add_cube, move_cube]) def run_next_step(): try: next(steps)() except StopIteration: return None return 0.5 bpy.app.timers.register(run_next_step)
Každý callback musí zůstat krátký. Timer není řešení pro dlouhou blokující operaci uvnitř jednoho callbacku a Blender Python API se nemá bez rozmyslu volat z vedlejších Python vláken.
Komunitní BlenderMCP používá add-on se socket serverem a samostatný MCP server. Nabízí čtení stavu scény, manipulaci s objekty, screenshot viewportu a také spuštění Python kódu.
Experimentální MCP Server z Blender Lab poskytuje rozhraní nad Blender Python API a aktuálně vyžaduje Blender 5.1 nebo novější. Nejde o vestavěné připojení Blenderu k LLM: je potřeba add-on, LLM klient a MCP server. Dokumentace zároveň varuje, že LLM generovaný kód se spouští bez ochranných guardů.
Vlastní bridge může být bezpečnější a předvídatelnější, pokud místo obecného execute_python nabídne malou sadu validovaných nástrojů, například:
list_scene() get_object(name) create_primitive(type, name, location) set_transform(name, location, rotation, scale) duplicate_object(source, target, offset) render_preview(camera, width, height) save_checkpoint(path)
Validace parametrů, auditní log, oprávnění ani bezpečné oddělení destruktivních akcí nejsou vlastností MCP samotného. Musí je implementovat konkrétní server. Nástroje mohou vracet strukturovaný stav, jednoznačné chyby a identifikátory změněných objektů, ale je potřeba ověřit skutečné chování vybraného serveru. Pokud nástroj pouze přijme libovolný Python a spustí ho, jde z hlediska řízení scény o bpy přenesené přes MCP, nikoli o omezenou nástrojovou vrstvu.
Hypotéza pro testování je používat strukturované nástroje pro přesně popsané změny a cílené preview pro kontrolu vzhledu. Agent načte stav, provede atomický krok, ověří dotčená data a po změně kompozice, materiálu, světla nebo kamery vytvoří náhled. CUA zůstává fallbackem pro dialogy a operace dostupné jen přes GUI. Teprve benchmark a praktické úlohy mohou potvrdit, zda dodatečná orchestrace přináší výhodu.
| Úloha | Strukturovaný stav stačí? | Proč |
|---|---|---|
| Názvy objektů, kolekce a hierarchie | Ano | Lze je porovnat přesně bez obrazu |
| Poloha, rotace, měřítko a rozměry | Ano | Číselné hodnoty jsou jednoznačné |
| Přiřazení materiálů a modifikátorů | Většinou ano | Datové vazby lze načíst přímo; vzhled je samostatná otázka |
| Počet objektů, polygonů nebo chybějící data | Ano | Jde o strojově kontrolovatelné vlastnosti |
| Silueta, proporce a vzájemné zakrytí | Ne | Kvalita závisí na pohledu a kompozici |
| Kamera, světlo, stíny a výsledný materiál | Ne | Rozhodující je výsledný obraz nebo render |
| Čitelnost uzlového grafu v editoru | Částečně | Zapojení lze číst z dat, ale layout a překryvy vyžadují obraz |
| Stav dialogu, aktivní panel nebo problém GUI | Ne | Jde o vizuální stav aplikace, ne pouze o scénu |
Vizuální kontrola nemá znamenat screenshot po každém číselném posunu. Praktické kontrolní body jsou po vytvoření hlavních objemů, nastavení kamery, materiálů, osvětlení a před finálním uložením nebo renderem.
Zkratky jsou kontextové. Před jejich použitím musí být aktivní správný editor, typicky 3D Viewport, správný objekt a správný režim.
Shift+A — otevře nabídku pro přidání objektu.G — přesun vybraného objektu nebo prvků.R — rotace.S — změna měřítka.X, Y, Z — omezení transformace na zvolenou osu.Enter — přesná hodnota a potvrzení transformace.Shift+D — duplikace výběru a okamžitý přesun kopie.Tab — přepnutí mezi Object Mode a Edit Mode.Esc — zrušení právě probíhající operace; nenahrazuje vrácení již potvrzené změny.Krátké sekvence:
G Z 2 Enter # posun o 2 jednotky po ose Z R Z 90 Enter # rotace o 90 stupňů kolem osy Z S X 2 Enter # dvojnásobné měřítko jen po ose X Shift+D X 3 Enter # duplikace a posun kopie o 3 jednotky po ose X Tab # vstup do Edit Mode; další Tab návrat do Object Mode G Z Esc # zahájený posun zrušit před potvrzením
Pro přidání objektu lze začít sekvencí Shift+A a následně z nabídky vybrat typ objektu. CUA musí po otevření nabídky zkontrolovat screenshot, protože další volba závisí na aktivním editoru, verzi Blenderu a keymapě.
Cílem je férové end-to-end porovnání tří agentních cest. U všech metod se měření spustí těsně před předáním stejného uživatelského promptu a skončí až po dokončení a uložení úkolu. Správnost následně určí stejný neměřený inspektor.
Každý běh začne z nové kopie stejného výchozího souboru s objekty Cube, Camera a Light. Všem metodám se předá stejný prompt:
Přejmenuj Cube na AI_Test_Cube_A. Nastav polohu na (0, 0, 1), rotaci kolem osy Z na 30 stupňů a měřítko na (2, 1, 0.5). Objekt duplikuj jako AI_Test_Cube_B a kopii umísti na (3, 0, 1). Camera a Light ponech beze změny. Pořiď finální preview viewportu a výsledek ulož pod názvem určeným pro tento běh.
Metodické rozdíly se nastaví v dostupných nástrojích a pevném systémovém zadání, ne změnou uživatelského promptu.
Pro všechny metody zůstanou stejné:
.blend soubor;Fast mode a kontext předaný modelu;3D Viewport, poloha a přiblížení viewportu;Object Mode, aktivní a jediný vybraný objekt Cube.Před měřením proběhne pro každou metodu jeden nezapočítaný zahřívací běh. Potom každá metoda absolvuje pět nezávislých měřených běhů a jejich pořadí se pro každé opakování náhodně promíchá.
bpy kódu.bpy skript.bpy skript přes jiný transport.
Po každém měřeném běhu se spustí přesně stejný neměřený bpy validační skript. Není dostupný agentovi během práce a jeho čas ani tokeny se nepřičítají k testované metodě. Inspektor načte uložený soubor a vrátí PASS/FAIL s konkrétními odchylkami.
Inspektor ověří:
AI_Test_Cube_A, AI_Test_Cube_B, Camera a Light bez dalších objektů;1e-6;AI_Test_Cube_A rovnou (0, 0, 1) a AI_Test_Cube_B rovnou (3, 0, 1);Camera a Light proti výchozímu souboru;| Metrika | Jak ji zaznamenat |
|---|---|
| Správnost výsledku | Výhradně výsledek stejného neměřeného bpy inspektoru |
| End-to-end čas | Od předání společného promptu po oznámení dokončení a uložení |
| Úspěch bez zásahu člověka | PASS/FAIL; ruční zásah znamená neúspěšný běh |
| Interakce | Modelové tahy, tool calls, GUI akce, retry a chybové stavy |
| Textové využití | Vstupní a výstupní tokeny, pokud je poskytovatel zpřístupňuje |
| Obrazové vstupy | Počet, rozlišení a případně účtované obrazové tokeny screenshotů a preview |
| Náklady | Spotřebované kredity nebo API cena konkrétního běhu bez dosazování ceníku před měřením |
| Nezamýšlené změny | Odchylky objektů a souborů hlášené inspektorem nebo sandboxem |
| Opakovatelnost | Úspěšnost a rozptyl času, interakcí, tokenů a nákladů mezi pěti běhy |
| Průběžná viditelnost | Samostatné pozorování, zda a kdy se viewport překresloval během běhu |
Průběžná viditelnost změn se zaznamená odděleně a nebude součástí rychlostního pořadí. view_layer.update() aktualizuje dependency graph, takže samo o sobě nedokazuje průběžné překreslení viewportu.
PASS bez ručního zásahu.Do článku se výsledky doplní až po provedení testu. Bez naměřených dat nelze určit vítěze.
.blend souboru a před destruktivními kroky ukládat checkpoint.