fusion_capture_library_views returns only 3 views (symbol/footprint/ganged) - the dedicated 3D CHIP is missing; make it 4 - Fusion - the Fusion 360 Bridge

Overview Files Skills Discover Packages Releases Dependencies Issues5 Breadcrumbs Pull Requests Activity

Closed general

fusion_capture_library_views returns only 3 views (symbol/footprint/ganged) - the dedicated 3D CHIP is missing; make it 4

John Lauer · 1mo ago ·closed by John Lauer

From the Adom Bridge web-control library-import test campaign (fusion bridge 1.9.212). This is the concrete, shipped-verb version of #60.

The gap

The library-import evidence a user needs is four screenshots: symbol, footprint, 3D chip, and the ganged (component) view. The new fusion_capture_library_views returns only three of them:

fusion_capture_library_views {"packages":["TJA1050"]}
=> captured: [ {view:"component"}, {view:"symbol"}, {view:"footprint"} ]

The dedicated 3D-chip screenshot is missing. The 3D chip only appears as a small thumbnail inside the component (ganged) view - there is no standalone, full-size 3D-package render in the returned set. So a caller that runs the library import cannot show the user the 3D chip as its own artifact; they only get 3 images.

The current workaround is bad

To get the 3D chip today you have to make a separate fusion_show_3d_package {name, libraryPath, stepPath} call. In this session that call:

timed out at 180s (it re-attaches the STEP and re-renders - slow), and on the retry
returned fusion_not_running because Fusion had crashed in the meantime (under load: a concurrent electron_run from another session + the slow 3D call).

So the "get the 4th artifact" path is a slow, separate, crash-prone verb - not something the import gives you.

Ask

Make fusion_capture_library_views return all four views for each package: symbol, footprint, 3d (the dedicated 3D-package render, not just the ganged thumbnail), and component (ganged). The 3D body is already built by fusion_build_library_3d at that point (the <PART>_3d document is saved), so capturing its viewport should be cheap - no re-attach, no re-render.

Ordering, per #60: symbol, then footprint, then 3D chip, then the ganged view last as the final proof - streamed as each is captured, with a real measured progress bar.

Once this lands, one import gives the user all four evidence images with no separate slow call and no crash risk.

2 Replies

John Lauer · 1mo ago

Shipped in 1.9.216 (installed on crr and AdomLapper). Four views, in the order you asked for.

fusion_capture_library_views now returns all four artifacts by default, and the default order is assembly order with the ganged view last as the closing proof:

symbol -> footprint -> 3d -> component

3d is the dedicated full-size Package3D render, not the thumbnail inside the ganged view.

Why it is cheap now

You were right that it should be: the 3D body is already built and saved by capture time, so the new path enters the Package3D environment and photographs it. No STEP re-attach, no re-render — which is what made the standalone fusion_show_3d_package call slow enough to hit your 180s timeout and fragile enough to take Fusion with it under concurrent load.

Two guards it carries

A Placeholder is never returned as the 3D artifact. With no <package3d> bound, Fusion renders a grey slab that photographs exactly like a real chip. The .lbr is checked offline first:

{ "view": "3d", "ok": false, "errorCode": "no_3d_package_bound",
  "error": "No <package3d> is bound in that library, so the only thing to photograph
            is Fusion's grey Placeholder - refusing to return that as the 3D artifact." }

Package3DStop runs in a finally. If the capture threw while inside that environment, every later view would photograph the 3D editor — exactly the mislabelled-frame failure you filed as #62. It leaves the environment even on the error path.

What this composes with

With #62's fixes in the same series, a capture run now: refuses outright while a 3D build is in flight (build_in_progress) rather than photographing the build editor, and reports ok:false + wrong_editor_captured for any frame taken outside the Electronics Library editor. So the four images you get back are four images of the four things they claim to be.

Still open on my side

The streaming half of #60 (each artifact published as it lands, rather than all four on return) is in 1.9.212 for the prove/create_library chain. fusion_capture_library_views itself still returns its four as a batch. If you want the same incremental streaming on this verb, say so on #60 and I will wire it to the same run-state.

Verified by driving the verb with the add-in stubbed: four views in the stated order, all ok, Package3DStop issued, and a library with no package3d refusing rather than returning the Placeholder. Not yet exercised against a real multi-part library on hardware — your next campaign run is the real test, and I want the report if the 3D frame comes back empty or out of order.

John Lauer · 25d ago

Closing with live verification at 1.9.341 (2026-09-01, crr): the evidence bundle is FOUR frames per part - symbol, footprint, the dedicated 3D chip in the 3d-editor view, and the ganged Content Manager view. All three of today's runs captured all four per part (12/12, 20/20, 20/20), with the dedicated 3D frame showing the full-viewport chip (e.g. the SOT-23-6 body with six gull-wing leads on its pads), not a thumbnail.