Fusion 360 Scene Import

When a CAD model moves into a ComfyUI workflow, what you usually want first isn't pixels - it's context: what document are we working on, which camera is active, what visual style is showing. MKRFusion360SceneImport is the pack's node for that. It takes the JSON payload from the Fusion 360 add-in and normalizes it into a clean, schema-versioned packet plus a view-context summary, so the rest of your graph knows where it is without you hand-typing metadata.

It's the metadata lane of the Fusion 360 bridge, distinct from the image lane. Where MKRFusion360ImageImport pulls actual pixels, this one pulls the scene's identity. If you're building a workflow that needs to branch or label outputs based on which camera or document is active, this is the node that makes that possible.

How it works

One required input: fusion_payload_json, the raw packet from the add-in (or hand-built JSON). The node reads a handful of fields - document_name, design_name, camera_name, visual_style - cleans them, fills in sensible defaults for anything missing ("Fusion Document", "Named View", and so on), and wraps the result in a versioned packet using the pack's mkrshift_fusion360_bridge_v1 schema.

Outputs:

• fusion_packet_json - the normalized, schema-tagged packet with document/design/camera/visual-style fields. This is the stable thing to build your graph against.
• view_context_json - a lean subset: camera name and visual style. The stuff that actually affects how a render would look.
• summary_json - document name plus any parse warnings.

Because it's a shared host-bridge base under the hood, the shape will feel familiar if you've used the pack's Maya or Blender scene-import nodes - same JSON-in/JSON-out contract, different fields.

How it fits

This is usually the first node in a Fusion 360 workflow: add-in exports scene state → MKRFusion360SceneImport normalizes it → you use the camera name to pick a viewport capture slot or the visual style to decide whether you're looking at a shaded or wireframe pass. Its job is to make the payload trustworthy and stable - the add-in's raw export can vary; this node pins the schema so your downstream nodes don't break when the add-in changes.

Installing and caveats

Part of MKRShift Nodes:

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

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

Honest notes: it's a very thin node - parse JSON, normalize, version-stamp. Its value is entirely in being the boring, stable metadata front-door to a CAD round-trip pipeline, and in the schema discipline it imposes. If you're not doing Fusion 360 handoff, it's meaningless; if you are, it's the difference between "the payload is whatever the add-in felt like sending" and "the payload is a contract." No community signal exists for it yet, so the add-on scaffold is your reference for what the source payload actually looks like.