Fusion 360 Image Output Plan

Writing a file is easy; writing a file somewhere that makes sense to Fusion 360 is the actual work. MKRFusion360ImageOutputPlan is the plan-building node in the pack's Fusion 360 lane: it takes an asset path, a role, and an apply mode, and produces a structured plan JSON describing exactly how that image should be used back in Fusion - as a decal, an appearance texture, or a canvas reference.

This is the "decide, then do" pattern the MKRShift bridge lane is built on. You don't write directly; you build a plan with this node (or its sibling MKRFusion360TexturePlan), and a runtime node (MKRFusion360ImageOutput) executes it. Keeping them separate means you can review and re-route the plan before anything touches disk.

The inputs that matter

• asset_path - where the image is (or will be) on disk. Required, and empty-string plans are worth nothing - the summary's has_path will tell you.
• image_role (default decal) - what the image is in Fusion terms. decal is the default and the common case: a logo or label mapped onto a face.
• target_name (default MKRShift Appearance) - the name of the appearance or entity it should be applied to, so the add-in knows what you mean.
• apply_mode - the real decision, three choices: decal, appearance_texture, or canvas_reference. A decal is a placed image on a surface; an appearance texture is the material's map; a canvas reference is the sketch-reference lane. Pick by what you're generating.
• target_component_name (optional) - narrows the application to a named component.
• transport_plan_json (optional) - if you're using the pack's network-transport lane (endpoint plans, HTTP, OSC), attach that plan here so the add-in knows how to receive the asset.

Outputs

• image_output_plan_json - the plan itself, in the pack's mkrshift_fusion360_image_output_plan_v1 schema.
• manifest_line - a flat CSV-ish line (host,role,mode,target,path) useful for manifests and logs.
• summary_json - host, role, mode, and whether a path and transport plan were present.

How it fits

The flow is: MKRExportPreset-style output or a generated image → MKRFusion360ImageOutputPlan → MKRFusion360ImageOutput (which actually writes the files per the plan). The plan node is pure metadata construction - no I/O, no Fusion connection, nothing that can fail on the file system. It's the half of the pipeline you can always inspect.

Installing

Part of MKRShift Nodes:

cd ComfyUI/custom_nodes
git clone https://github.com/criskb/MKRShift_Nodes

Restart, or ComfyUI Manager search "MKRShift_Nodes". To complete the loop you'll also load the Fusion 360 add-in from addons/fusion360/ in the repo. Zero extra Python deps.

This node is only interesting if you're building a Fusion 360 round-trip workflow, and there's no community noise around it yet - but the plan/execute split is a genuinely good pattern, and the plan output is plain JSON you can read, edit, or log before anything happens to your disk.