Fusion - the Fusion 360 Bridge

Reproduced a stale-image variant of this issue on 2026-09-10, in addition to the originally reported blank viewport. Fusion bridge 1.10.11, add-in 1.0.19, ConfRoomROG AB 2.1.96; Linux CLI 2.1.96 (541e1f0c-dirty). Fusion remained behind other windows; no foreground changes, restarts, or bridge upgrades.

Native study18 imported 29 groups and 689 solid bodies, passed native count/volume/bounds comparisons, then passed constrained -50/+50/0 mm slider travel with 23 groups fixed. Thirteen camera inspections exported different correct native images through activeViewport.saveAsImageFile. Cloud reopen preserved all 689 solids and the joint.

However, WGC background window recordings C149/C150/C151 retained an earlier stage-only viewport, omitting the newly imported sensor/carrier and the subsequent camera/motion changes. The title/tabs changed while the rendered viewport remained stale. The GPU recorder reported hardwareEncoder=true, gpuZeroCopy=true and droppedFrames=0, so recorder health alone does not establish fresh application pixels. The encoded clips are excluded from the positive project film.

Please return capture freshness and an actionable AI hint from the Fusion bridge. For background design capture, compare an intentional camera or geometry change against the returned pixels and report stale/unknown rather than claiming capture success. Expose a supported native viewport recording/sampling path when WGC cannot capture fresh embedded graphics; include acquisition timestamps, camera/document identity, geometry revision and timing limitations. Do not advise foregrounding as the default workaround.

Current project fallback captures each actual Fusion viewport after a native pose change using activeViewport.saveAsImageFile. It will be labeled as sampled native viewport footage at the declared playback frame rate, not wall-clock real-time or a WGC recording. No fake UI is composited. Evidence: Depth Lab docs/research/fusion-r18-native-motion.json, fusion-r18-cloud-reopen.json, media/metadata/C149-fusion-r18.json and C151-fusion-r18.json, plus the native component inspection images.

Shipped in 1.10.13 (insiders, on ConfRoomROG, AdomLapper and arav-rog; winvm is offline today) and verified on ConfRoomROG with your Depth Lab file.

fusion_state now reports geometry separately from window pixels, with no foregrounding:

• nativeViewport {path, ok, bodies, productType, document, capturedAt}: the frame Fusion itself renders, through activeViewport.saveAsImageFile in the add-in. viewport:"native" skips the window capture entirely; nativeViewport:false skips the native export.
• geometry {bodies, productType}: the API body count, independent of any capture.
• windowPixels {dominantColorFraction, blank}: the window capture measured; above 0.97 one colour it is declared blank, and the hint then says to trust the native frame and never to foreground Fusion for a capture. When the native export fails on a blank capture, the hint says nothing substantiates visible geometry.

Verified live: V - Pincer Moving Large opened by lineage on ConfRoomROG, fusion_state {} returned nativeViewport ok with 1 body, productType DesignProductType, a 34 KB native frame at the returned path, windowPixels dominant fraction 0.756 (not blank on that box), and the hint pointing at the native frame for Design documents.

Not done here: a recording adapter that streams native viewport frames with timestamps. That is a separate piece of work (a frame loop through the add-in at a stated rate); if you want it, say the rate and length you need and I will scope it on its own issue.