Blender Return Output
Writes your files, reports the paths
- images
- written_paths_json
- primary_path
- summary_json
MKRBlenderReturnOutput is the do-er at the end of the Blender return-plan pipeline. MKRBlenderReturnPlan writes the plan; this node executes it. You feed it your generated images and a return_plan_json, and it writes the files to the path the plan specifies, then hands back the list of everything it wrote plus the primary path. If you've built a roundtrip where ComfyUI generates an image that Blender is supposed to pick up, this is the node that makes the file appear where Blender looks.
From MKRShift_Nodes by criskb. Install via ComfyUI Manager (search "MKRShift_Nodes") or git clone https://github.com/criskb/MKRShift_Nodes into custom_nodes/, restart.
How it works
The node parses the return plan, reads the generated_asset_path (and the asset kind - image, image sequence, or video), and writes the IMAGE batch there. A single image becomes a single file; a batch becomes a numbered sequence, matching the plan's asset_kind. The optional filename_override lets you bypass the plan's naming if you need a specific name for the handoff. Outputs are written_paths_json, primary_path, and a summary_json that reports any write warnings.
The two inputs that matter
images- your generated frames. Non-negotiable.return_plan_json- the plan dictating where they go. This is what you get fromMKRBlenderReturnPlan, and it's where theapply_mode(image_plane, camera_background, compositor_image, texture_image) andcolorspace(sRGB / Non-Color / Linear) decisions live.
Everything else is convenience.
Where it sits in the flow
The clean pattern: generate → MKRBlenderReturnPlan (decide where and how it lands) → MKRBlenderReturnOutput (write the bytes) → Blender add-on reads the file and applies it according to the plan. Two useful realities: this node is file-bridge, not live-link - it doesn't open a socket to Blender, it makes sure the file is on disk at the right path, and that's more robust than a live connection anyway. And colorspace is metadata in the plan, so Blender knows whether a map is sRGB or Non-Color when it applies it - a small detail that prevents the classic "my normal map looks washed out" facepalm. Keep the plan and the output on the same subfolder logic and this runs all day without surprises.
Inputs (3)
| Name | Type | Default | Description |
|---|---|---|---|
| images | IMAGE | — | |
| return_plan_json | STRING | {} | — |
| filename_overrideopt | STRING | — |
Outputs (3)
| Name | Type | Description |
|---|---|---|
| written_paths_json | STRING | — |
| primary_path | STRING | — |
| summary_json | STRING | — |