Fusion 360 Texture Plan

The texture version of the pack's Fusion 360 "decide before you do" pattern. MKRFusion360TexturePlan builds a structured return plan - schema-tagged, with an asset path, a target appearance name, and an apply mode - that tells the Fusion 360 add-in exactly how to consume a generated texture. The matching runtime node, MKRFusion360TextureOutput, is what actually writes the image files the plan describes.

If you've read MKRFusion360ImageOutputPlan, this is its sibling with a narrower focus: image output plans cover decals and canvas references too, while this node is aimed at the appearance/texture path specifically - the "give the material its map" workflow. Both build _v1-schema plans; they just encode different intent.

The inputs that matter

• asset_path - where the generated texture lives (or will live). The node also computes an asset_slug from it, so the plan carries both the human path and a stable slug for referencing.
• target_appearance_name (default MKRShift Appearance) - the Fusion 360 appearance this texture should feed. Rename per material; the add-in uses this to know what you're updating.
• apply_mode - three choices, same as the image plan: decal, appearance_texture, or canvas_reference. For texture work you'll typically want appearance_texture.
• transport_plan_json (optional) - attach a pack network-transport plan (endpoint/HTTP/OSC) when the asset is delivered over the wire rather than just a local path.

Outputs

• fusion_texture_plan_json - the plan, in the mkrshift_fusion360_texture_plan_v1 schema: asset path + slug, target appearance, apply mode, and any transport info.
• manifest_line - a flat CSV-ish line (target_appearance_name,apply_mode,asset_path) for logs and manifests.
• summary_json - target appearance, whether a path was present (has_path), whether a transport plan was attached, and warnings.

The has_path flag is your honesty check: a texture plan with an empty asset_path is metadata with nothing to execute, and MKRFusion360TextureOutput will have nothing to write.

How it fits

The pipeline: generate a texture → MKRFusion360TexturePlan (describe where it goes and what it is) → MKRFusion360TextureOutput (write the files per plan) → the Fusion 360 add-in applies it to the named appearance. Plan first, execute second, and the plan is inspectable JSON the whole way. If your workflow branches on "is this texture decal or material," the apply mode lives right here.

Installing

Part of MKRShift Nodes:

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

Restart, or ComfyUI Manager search "MKRShift_Nodes". The Fusion 360 add-in from addons/fusion360/ completes the loop. No extra Python deps.

Straight talk: it's a small metadata-construction node whose entire job is giving the texture handoff a stable, readable contract. No community discussion exists yet - this lane of the pack is young and niche - so lean on the add-on scaffold and the plan JSON itself to see exactly what fields get consumed on the Fusion side.