Blender Return Plan

When a generated image is going back into a Blender scene, "just save it somewhere" is how renders end up lost. MKRBlenderReturnPlan is the antidote: it writes a precise plan - what file, what kind of asset, how Blender should apply it, and in what color space - before you generate anything. It's the thinking half of the roundtrip; MKRBlenderReturnOutput is the doing half. Plan first, generate second, and the handoff stops being a mystery.

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.

The inputs that define the contract

• generated_asset_path - where the file will land. This is the one field that will bite you if it's wrong.
• asset_kind - image, image_sequence, or video. An image batch that you mark as a sequence gets numbered; mark it image and only the first frame is treated as the asset.
• apply_mode - the four ways Blender can show it: image_plane, camera_background, compositor_image, texture_image. Pick the one that matches your intent (plane for boards, background for plates, compositor for post passes, texture for material work).
• target_name - what the asset is called in the scene.
• colorspace - sRGB, Non-Color, or Linear. The boring-but-crucial one: a normal or roughness map must be Non-Color, or Blender interprets it as display color and your material looks wrong.

Optionally you can pass scene_packet_json (from MKRBlenderSceneImport) so the plan carries scene context, plus notes. Outputs: return_plan_json, a manifest_line, and summary_json.

Why the colorspace field earns its keep

This is the part people skip until they've been burned. An sRGB texture on a normal-map slot isn't subtly wrong - it's unusable. Having the color space written into the plan means the applying side can't forget it, and if you generate a full PBR set you'll be glad the decision is recorded next to the path instead of living in your head.

The honest shape of it

Like every plan node in this pack, it produces data, not pixels - nothing is written until the runtime node executes the plan. There's essentially no community chatter on this node yet, so the README and the add-on docs are your reference. Keep the path in sync between plan and output and you'll be fine; let them drift and you'll be hunting for a file that landed exactly where you told it to, which is somehow always the last place you look.