Fusion 360 Texture Output

The runtime half of the Fusion 360 texture handoff. MKRFusion360TexturePlan builds the plan; MKRFusion360TextureOutput is the node that takes your generated texture IMAGE batch and writes the files to the asset path that plan describes, so the Fusion 360 add-in can pick them up and apply them to the named appearance. Plan and execute, same split as every other node in the pack's host-bridge lane.

Under the hood it's a subclass of the pack's shared single-asset-plan runtime - the same machinery that drives the Nuke, Premiere and Affinity output nodes - with the host label and plan field swapped to Fusion 360. Familiar shape if you've used any of the others.

How it works

Two required inputs:

• images - the IMAGE tensor batch containing your generated texture(s). This is what lands on disk.
• fusion_texture_plan_json - the plan from MKRFusion360TexturePlan (the mkrshift_fusion360_texture_plan_v1 schema). The node reads the asset_path out of it and writes there.

One optional: filename_override - a string to override the planned filename on the way out, if you need a different stem. Empty follows the plan.

Outputs:

• written_paths_json - JSON with the paths array of every file written, plus the plan used.
• primary_path - the first written path as a plain string.
• summary_json - host, apply mode, target appearance, file count, primary path, warnings.

The summary's has_path-style sanity checks live in the plan; here the check is that primary_path is non-empty. If it comes back empty with warnings, the plan had no usable asset path and nothing was written.

How it fits

The full loop: generate a texture → MKRFusion360TexturePlan (decide target appearance and apply mode) → MKRFusion360TextureOutput (write files) → Fusion 360 add-in applies the texture to the named appearance. This node is deliberately dumb - parse plan, write images, report paths - and that's the point: the "decision" logic lives in the plan node where you can inspect and re-route it, and the "do" step is predictable and repeatable. If the add-in isn't seeing your texture, check primary_path against what the plan says and what the add-in's watch folder expects.

Installing

Part of MKRShift Nodes:

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

Restart ComfyUI, or ComfyUI Manager search "MKRShift_Nodes". No extra Python deps. The Fusion 360 add-in scaffold under addons/fusion360/ is the other half.

The honest take: this node is unglamorous and correct, which is exactly what a file-writing step should be. There's no community noise around it yet - this whole Fusion 360 lane is young and niche - so treat the plan JSON and the add-on scaffold as your source of truth for what fields matter. If you're building a CAD-texture round trip, this is the reliable "put it where Fusion can find it" step.