Obsah

Možnosti propojení AI s Blenderem

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.

Stav ověření

Ověřené principy:

Zatím neověřeno:

Co skutečně dokládá původní ukázka

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.

Stručné srovnání možností

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

1. CUA / Computer Use přes GUI

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.

2. Přímé Blender Python API bpy

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:

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.

3. Blender MCP nebo vlastní API/socket bridge

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.

4. Pracovní hypotéza: hybrid

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.

Kdy AI potřebuje obraz a kdy stačí data

Ú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.

Praktické zkratky Blenderu pro CUA

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.

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ě.

Testovací plán: CUA vs. bpy baseline vs. krokové nástroje

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.

Společný prompt a očekávaný výsledek

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.

Fixní prostředí a pořadí běhů

Pro všechny metody zůstanou stejné:

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á.

Hranice měření

  1. Připravit čistou kopii výchozího souboru a fixní prostředí.
  2. Spustit časomíru bezprostředně před předáním společného promptu modelu.
  3. Zahrnout plánování modelu, generování výstupu, všechny akce nebo tool calls, preview a uložení.
  4. Zastavit časomíru, když metoda oznámí dokončení a vytvoří výstupní soubor.
  5. Teprve potom spustit nezávislý inspektor; jeho čas se do výkonu metody nezapočítá.

Metoda A: CUA

Metoda B: jednorázový bpy skript – deterministický baseline

Metoda C: krokové MCP/API nástroje

Nezávislý inspektor správnosti

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ěří:

Metriky

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.

Kritéria vyhodnocení

  1. Běh je úspěšný pouze při výsledku PASS bez ručního zásahu.
  2. Za prakticky spolehlivou se v tomto malém testu považuje metoda s alespoň čtyřmi úspěšnými běhy z pěti.
  3. Čas, tokeny a náklady se porovnají mediánem pouze úspěšných běhů.
  4. Chybné výběry, retry a nadbytečné screenshoty nebo tool calls se vyhodnotí z logu interakcí.
  5. Hybrid se otestuje až jako samostatná pracovní hypotéza se stejným promptem, prostředím, měřením a inspektorem.

Do článku se výsledky doplní až po provedení testu. Bez naměřených dat nelze určit vítěze.

Bezpečnost a provozní doporučení

Zdroje