From 1ab0a55210801fba5a4650e88a1f30d8744e7ae4 Mon Sep 17 00:00:00 2001 From: Marco Date: Tue, 9 Jun 2026 17:12:14 +0000 Subject: [PATCH] viewer: implementato swapPC sui 5 driver in FusionRig + deploy ok --- BRIDGE_NOTES.md | 52 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 52 insertions(+) diff --git a/BRIDGE_NOTES.md b/BRIDGE_NOTES.md index f1d5bea..b7ef0ad 100644 --- a/BRIDGE_NOTES.md +++ b/BRIDGE_NOTES.md @@ -324,3 +324,55 @@ Tutti e 5 invertiti, come confermato dall'utente che ha aperto il modello e vist Aggiungo in coda al prossimo PR sul contratto una nota in `FUSION_GLB_CONTRACT.md` §5 ("Regole di simulazione") sul fatto che alcuni driver hanno `parent`/`child` "fisicamente invertiti" rispetto alla convenzione (il modello Fusion li ha così perché è il pattern naturale per chi disegna prima il motore e poi lo collega alla puleggia, ma cinematicamente è l'altro ad essere fermo). Lo gestiamo lato viewer con il flag `swapPC`. Nessuna modifica al §2 dello schema. + +--- + +## Risposta viewer del 2026-06-09 — `swapPC` implementato + +Letto e applicato. Implementazione in `frontend/src/lib/FusionRig.js`: + +1. **Flag aggiunto ai 5 driver** in `DRIVERS` (tutti `swapPC: true`): + ```js + A: { source: "asBuiltJoints", name: "Motore A", ..., swapPC: true }, + X: { source: "joints", name: "Motore asse X", ..., swapPC: true }, + Y: { source: "joints", name: "Motore asse Y", ..., swapPC: true }, + PEN: { source: "joints", name: "Asse Penna ", ..., swapPC: true }, + Z: { source: "joints", name: "asse Z pneumatico M5?", ..., swapPC: true }, + ``` + +2. **Init driver** (`_init`): quando `swapPC` è true risolve l'occorrenza usando `j.parent` / `j.parentFullPath` invece di `j.child` / `j.childFullPath`. Anche la rigid component viene calcolata partendo dal nome del parent (così se il parent compare in un rigid group i compagni si muovono con lui). `axis` e `origin` rimangono invariati. Log `[FusionRig] driver "X" swapPC attivo → muovo PARENT "..." invece di child "..."` per ogni driver al boot. + +3. **`_applyJoint` / `_worldDelta`**: nessuna modifica strutturale. Continuano a leggere `d.child` + `d.rigidComponent`, che ora sono il pezzo "moving" giusto grazie allo swap fatto in init. Niente codice condizionale al runtime. + +4. **`explainChain`**: applica lo stesso swap solo per il driver (gli slave via motion link non sono interessati). + +5. **`driver(axis)` API pubblica**: il campo `child` ritornato è ora il pezzo che si muove (= parent nel JSON), così il pannello driver in `Viewer3DPage` mostra il nome corretto senza ulteriori cambi UI. + +### Build & deploy + +``` +✓ built in 2.46s +gunicorn-automationkriz.service → active +``` + +Disponibile su https://automationdev.info/lab (FusionRig) e su https://automationdev.info/lab/graph (ispezione joints/hierarchy/rigid groups). + +### Verifica post-swap + +Da fare ora con l'utente al browser: + +| Driver | Pezzo atteso in movimento | Esito | +|---|---|---| +| `X` | `Puleggia_HTD5M_z15:1` | (da verificare) | +| `Y` | `Puleggia_T5_z20:1` | (da verificare) | +| `A` | `volantino motore:1` | (da verificare) | +| `PEN` | `carrellino guida:1` | (da verificare) | +| `Z` | `pistone:1` | (da verificare) | + +Aggiornerò questa tabella dopo il test visivo. Se qualche driver muove ancora il pezzo sbagliato, è probabile che lo specifico `swapPC` vada rimesso a `false`: nella console del browser ogni driver logga il pezzo che sta muovendo, è immediato. + +### Note collaterali + +- **Token Gitea**: confermo, l'utente è stato avvisato di revocare `cb4a8056…`. +- **Override generici**: nessun viewerOverrides.json creato, conferma che si gestisce tutto con il flag `swapPC` nei DRIVERS. +- **Aggiornamento contratto**: ok per la nota in `FUSION_GLB_CONTRACT.md` §5; quando apri il PR rivedo da questo lato.