Blender

BIGGI treats Blender as an auxiliary asset pipeline, not as the project's Game Loop engine. A .blend file can live beside a Unity, Godot, Unreal, or browser game without changing primary engine detection.

The integration is currently a preview. General availability remains gated on the full Blender 4.5, browser-asset, Unity-import, and Godot-import acceptance matrix.

Install Blender 4.5 LTS or newer yourself. BIGGI never downloads or bundles Blender. It resolves the executable from BIGGI_BLENDER_BIN, project configuration, your system path, and then common operating-system locations.

What BIGGI can do

• Discover and inspect .blend scenes
• Validate geometry, materials, textures, animation, and export compatibility
• Apply allowlisted transforms, parenting, mesh cleanup, modifiers, collections, and Principled PBR material edits
• Render previews, stills, turntables, and transparent frame sequences
• Export FBX, GLB, and browser sprite atlases with hashes and manifests
• Work through isolated background Blender jobs or an optional authenticated live bridge

BIGGI does not embed Blender's viewport and does not expose unrestricted Python through the live bridge.

Export profiles

An explicit profile or consumer overrides inference. Matter.js is treated as physics rather than a renderer. Projects with multiple renderers or an unidentified custom Canvas must identify the intended consumer.

Browser exports remain uncompressed by default. Draco, Meshopt, KTX2, and WebP need matching consumer-side decoders, so BIGGI does not enable them implicitly.

Use the live bridge

Run BIGGI: Install Blender Bridge from the Command Palette, then run BIGGI: Open Blender File. The separately licensed GPL-3.0-or-later bridge connects from Blender to an ephemeral BIGGI loopback endpoint.

Each connection is authenticated, expires automatically, and is bound to one canonical workspace and .blend file. Live mutations execute on Blender's main thread as one undoable operation and remain unsaved. Run BIGGI: Remove Blender Bridge to uninstall it.

Without the bridge, inspection, validation, editing, rendering, and export use deterministic background Blender processes.

Blender status, open, bridge installation, and bridge removal are authenticated local control-plane operations. They fail closed when server credentials are absent and require valid credentials when configured. In the supported VS Code flow, open/install/remove also require an explicit modal confirmation. Public status and open responses never expose the bridge endpoint path.

Browser-game workflow

Ask the Tech Art or Gameplay agent to export the asset and integrate the returned loader parameters. BIGGI does not silently rewrite the game's source.

After integration, ask it to verify the result:

1. game_refs confirms the GLB, PNG, or JSON reference.
2. game_build with preview proves the asset bundles and serves.
3. game_console checks network, decoder, shader, and runtime errors.
4. game_scene_query finds Three.js, Babylon.js, Phaser, or PixiJS objects.
5. game_runtime_query checks contract state for Kaplay, Excalibur, Matter.js, or custom games.
6. game_screenshot captures rendered evidence.
7. game_profile checks supplied network, texture, triangle, and draw-call budgets.

For Vite-style projects, public/assets/ is the default recommendation. BIGGI preserves common existing asset-directory conventions and requires export destinations to stay inside the workspace.

Configuration

{
  "gamedev": {
    "blender": {
      "binary": "/path/to/blender",
      "bridge": true
    }
  },
  "experimental": {
    "blender_scripts": false
  }
}

The experimental blender_run_script tool runs only an approved workspace-local .py file, only in an isolated background process, and only against a staging copy. It is disabled by default. BIGGI snapshots at most 1 MiB before asking permission, shows the canonical path, byte count, and SHA-256 in the approval, rejects a changed path after approval, and executes the exact approved bytes.

Safety model

Background mutations start from a staging copy. BIGGI verifies the source path identity and hash before promoting output, defaults edits to save: "copy", and replaces the original only when save: "source" was explicit.

Agent-invoked editing, rendering, exporting, and arbitrary scripts use separate BIGGI permission checks. Launching Blender and changing the bridge installation use authenticated local endpoints plus explicit modal confirmation in VS Code. The bridge rejects stale endpoints, oversized messages, unknown methods, and file, hash, version, or workspace mismatches.

Jobs are bounded to 8192 pixels per render axis, 1,000 frames, 268,435,456 effective rendered pixels, a 4096-pixel sprite-atlas axis, and 2 GiB of staged output. Artifact hashing uses four workers. Returned artifacts and blender.log share one limit of eight attachments and 16 MiB raw data; artifacts keep their order and the result says when the log could not fit.

Promotion remains atomic per file. BIGGI rechecks source identity and content immediately before each artifact or manifest is promoted, so a source change stops later promotions without pretending the entire multi-file export is one global transaction.