Fusion - the Fusion 360 Bridge

Accepted, working on it now. Plan: fusion_make_3d_package (and the library builders that call it) get an explicit placement block {translation:[x,y,z] mm, rotation:[rx,ry,rz] deg, scale:1} that bypasses every heuristic (orient, centering, the pin-1 rotation in the _mark routine), preserves the STEP bytes, and returns the applied 4x4 matrix plus provenance and a verification status; orient:false will mean no reorientation at all, with the reply saying which steps ran; invalid or nonfinite transforms and any scale other than 1 are rejected before Fusion is touched; warnings when placement metadata is absent. Test fixture will use your nonzero offset and a misleading circular aperture. Will report the release here.

Shipped in 1.10.8 to 1.10.10 (insiders, installed on ConfRoomROG, AdomLapper, winvm, arav-rog) and verified live on ConfRoomROG.

The verb. fusion_make_3d_package (and each parts[] entry of fusion_build_library_3d) takes placement: {translation:[x,y,z] mm, rotation:[rx,ry,rz] deg, scale:1}. Rotation is applied about X, then Y, then Z (extrinsic, about the origin), then the translation; that is the convention, stated in the reply so nobody has to guess it. With a placement every heuristic is bypassed: no bounding-box orient, no centering, and the pin-1 mark routine is not armed at all (PIN1 is None in the generated script, so it cannot rotate in 90-degree steps; unit test asserts it). The STEP bytes are never touched; the reply carries source {path, sha256, bytes, preserved:true}.

orient:false now means no reorientation of any kind: the pin-1 rotation that used to survive it is skipped too, reported as pin1.status: skipped_orient_false. A default mint keeps both heuristics and says so in warnings and pin1.status (rotated / aligned).

Refusals before Fusion is touched: invalid_placement for a non-finite number, a wrong shape, or units other than mm/deg; unsupported_scale for any scale other than 1. Both verified against the installed build (1.2 s, Fusion untouched).

Live result, your transform on the sample 0603 part (translation [-0.00008128, 1.39191746, 0.18269966] mm, rotation [0, 0, 90]), read back from the occurrence after import:

appliedMatrix (row-major, translation column in mm)
[ 0, -1, 0, -0.000081 ]
[ 1,  0, 0,  1.391917 ]
[ 0,  0, 1,  0.182700 ]
[ 0,  0, 0,  1        ]
verification: verified   pin1: skipped_explicit_placement   heuristics: {orient:false, centering:false, pin1:skipped}
source sha256 1875571c326d... (40618 bytes, preserved)   saved: urn:adsk.wipprod:fs.file:vf.9idGG9UOTWeaCXOXL1kUCg?version=1

Two bugs the verification itself found and fixed (1.10.9, 1.10.10): Fusion titles a library opened through a DOS short path by its 8.3 stem ("0603WA~1" under a path with spaces such as the bridge cache), and the active-library, duplicate-close and footprint checks only knew the long name, so any mint from the bridge's own samples failed with library_not_active and left duplicate library documents open. Both title forms count now.

Honest limits. The verification is the matrix read back from occurrence.transform2, which proves Fusion holds the requested transform; it does not judge whether that transform puts the body on the footprint, so keep your underside alignment check. The circular-aperture case is covered by construction (the mark heuristic is never armed under a placement) rather than by a body with an aperture; if you want that fixture in the daily verb run, attach the TMF8829 STEP and per-part .lbr and I will add it.