Blender Generic Runner

The "Blender Generic Runner" node is the odd one out in your node list: it doesn't load a checkpoint, sample latents, or call any API. It takes a .blend file, points a real headless Blender at it, and runs whatever Python stage script is baked into that file. It's the pipeline glue that turns ComfyUI from an image generator into a general-purpose automation canvas - the author built it for a game/film production pipeline that mass-generates rigged characters, where the AI step is only the first ten percent of the work.

Why reach for it? Because Blender already does the hard parts of asset work - decimation, unwrap, baking, retopo, rigging, geo nodes - and reimplementing any of that in Python nodes is a fool's errand. Drop a .blend stage into your graph and it behaves like any other node: input a mesh, get a processed mesh back.

How it works

The node is thin by design. It reads your Blender executable path from blender_tools_config.json in the pack folder, then shells out:

blender --background --python wrapper.py

Inputs are handed over as environment variables (BLEND_FILE, INPUT_MODEL, CONFIG_FILE, OUTPUT_JSON), which is how ComfyUI talks to the Blender subprocess. Inside wrapper.py, Blender loads the config, imports your model into a collection named INPUT, appends every datablock from the stage .blend, and then runs the stage's text block named Main (falling back to running all text blocks if there's no Main). The stage writes results to OUTPUT_JSON, the node reads them back, and your graph continues.

The stage script gets a few globals injected: config (already parsed into a dict), blend_file, input_model, input_objects, and config_path. That's the whole contract, and it's refreshingly small.

The inputs that matter

Four inputs, all strings except seed - this is one of those rare nodes where the fields are self-explanatory:

• blend_file - path to the stage .blend that holds your pipeline logic. Required, and the file has to exist or the wrapper just prints a warning and does nothing.
• input_model - the mesh Blender acts on. Supports .fbx, .obj, .glb/.gltf.
• config_file - a path to a JSON dict of "balancing parameters" for your stage. Leave it empty if the stage doesn't ask for it; whether it's needed is up to whoever wrote the stage.
• seed - honest note: in the shipped code this is wired to nothing. It's declared and ignored, so don't expect reproducibility from it unless your stage reads it some other way.

Two outputs: fbx_path (a string the stage sets via fbx_export in its output JSON - "No FBX Exported or not set" if nothing was written) and output_json, a dict that lets the stage author talk up to the next node. Wire output_json into a node that takes a dict, or just preview it.

Writing your own stage

Copy one of the example blends (MeshCleanUp.blend, SimpleRig.blend) and add a Python text block named Main. In it, grab your objects from the INPUT collection, read globals().get("blend_file", None) or config for parameters, and write results to the OUTPUT_JSON path from the environment. The author's trick - worth stealing - is that LLMs are weirdly good at Blender scripting, so you can sketch a stage in plain English and mostly have it work.

Install

ComfyUI Manager (search "comfyUI-blender-wrapper"), or:

cd ComfyUI/custom_nodes
git clone https://github.com/IRCSS/comfyUI-blender-wrapper

Restart ComfyUI. There are no model downloads - the only real dependency is Blender itself (tested on 4.5, works on most versions). After cloning, edit blender_tools_config.json and set blender_path to your Blender executable.

Where people get burned

• The Windows default. The shipped config points at C:\Program Files\Blender Foundation\Blender 4.5\blender.exe, and the env-var handoff is written for Windows. On Linux you'll likely need to adjust the subprocess call; the author admits he never really tested it there.
• Invalid path, silent-ish failure. If blender_path is wrong the node returns a string ("Blender path not set or invalid...") instead of its two normal outputs - you'll notice, but the error is easy to mistake for something deep when it's really just a typo in a JSON file.
• No Main, no output. If the stage blend has no text block named Main, everything else silently no-ops. Keep your stage logic in Main.
• Windows file-lock pain. The author bundles patched files from Kijai's Hunyuan3D wrapper specifically for Windows read/write permission collisions when batch-processing meshes - if you're hammering it with hundreds of jobs, that's the fix you'll be reaching for.

Debugging is old-school: the wrapper prints everything to the ComfyUI console, so that's where your stage's print() calls land. It's a niche, opinionated tool - but if your pipeline touches .blend files at all, it's the shortest path between ComfyUI and a full DCC.