From ce0c076beac96af6ebeea3f8c6e8aca8bd23ac7a Mon Sep 17 00:00:00 2001 From: Marco Date: Tue, 9 Jun 2026 16:46:26 +0000 Subject: [PATCH] docs: rettifica - BUG 1 era falso allarme (mio errore in script python), chiarito comportamento _applyJoint sul child --- BRIDGE_NOTES.md | 44 +++++++++++++++++++------------------------- 1 file changed, 19 insertions(+), 25 deletions(-) diff --git a/BRIDGE_NOTES.md b/BRIDGE_NOTES.md index 802a215..fd4b2d5 100644 --- a/BRIDGE_NOTES.md +++ b/BRIDGE_NOTES.md @@ -80,25 +80,16 @@ Lato consumer (`automation_kriz`) ho aggiunto una pagina di ispezione live a `/l Ispezionando l'export attuale (`329 joints, 28 asBuiltJoints, 9 motionLinks, 20 rigidGroups`) ho trovato tre problemi che impediscono al viewer di propagare il movimento sull'asse X (e probabilmente anche Y e PEN dipendono dagli stessi pattern). Servono fix lato `ExportKinematicGraph.py`. -### BUG 1 — `rigidGroups[].occurrences` è SEMPRE vuoto +### BUG 1 — ~~`rigidGroups[].occurrences` è SEMPRE vuoto~~ FALSO ALLARME -Tutti i 20 gruppi rigidi esportati hanno `occurrences: []`. Esempio dal file corrente: -```json -[ - {"name": "Gruppo rigido 6", "occurrences": []}, - {"name": "Gruppo rigido 17", "occurrences": []}, - ... -] +**Ritiro questo punto.** Era un errore nel mio script Python di diagnostica a terminale (avevo scritto `rg.get('occurrences', [])` invece di `rg.get('occurrenceNames', [])`), poi ho copiato la conclusione qui sopra senza ricontrollarla. Verifica fatta: + +``` +Keys di un rigid group: ['name', 'occurrenceNames', 'occurrencePaths', 'isSuppressed', 'isLightBulbOn', 'includeChildren'] +Gruppo rigido 6 contenuto: ['end stop X PIastrina:1', 'binario SX:1', 'Cinghia T5:1'] ``` -Nel `BRIDGE_NOTES` precedente è scritto che `Gruppo rigido 6` doveva contenere `end stop X PIastrina:1 | binario SX:1 | Cinghia T5:1`. Nell'export reale quelle occorrenze NON ci sono. Senza occurrences, il viewer non sa quali parti tenere "incollate" al carrello / motore / cinghia → il driver X non muove nulla. - -Possibili cause da verificare nell'add-in: -- Si itera `rigidGroup.occurrences` ma con un proxy stale (collection invalidata dopo `activate`/`returnToParent`)? -- Si guarda `nativeObject.occurrences` invece di farla risolvere via `assemblyContext`? -- Si filtra accidentalmente per `occ.isLightBulbOn` o `isSuppressed`? - -Verifica veloce: in console Fusion durante export stampare `len(list(rg.occurrences))` per ogni `rg` in `rootComp.allRigidGroups` e confrontare con quello che finisce nel JSON. +Il JSON è conforme al contratto §2.3 (`occurrenceNames` + `occurrencePaths`). Anche `FusionRig.js` e `KinGraphPage.jsx` lato viewer leggono già correttamente `g.occurrenceNames`. Quindi BUG 1 non esiste, scusa il rumore. ### BUG 2 — `Collegamento movimento 14` (driver X) ha `joint1: null` @@ -126,18 +117,21 @@ Nel BRIDGE_NOTES precedente è scritto "ignorabili, propagazione passa dai rigid Fisicamente è il motore stepper che è fissato al telaio e fa girare la puleggia. Nel JSON è il contrario. Il viewer applica sempre la rotazione al `child` mantenendo fermo il `parent`, quindi vede il motore ruotare nel vuoto e la puleggia (che dovrebbe seguire) sta ferma. -Fix in Fusion: aprire il joint, cliccare **Switch** per invertire `Component 1`/`Component 2`. Sospetto valga anche per gli altri driver — andrebbero controllati tutti e cinque con questo criterio: -- `parent` = pezzo che resta solidale al telaio (o al precedente livello cinematico) -- `child` = pezzo che si muove rispetto al parent +**Risposta alla domanda "il viewer applica al child?"**: sì, lo applica al `child` (più tutti i compagni del/dei rigid group che contengono il child). Codice in `FusionRig.js#_applyJoint` + `_worldDelta`: +```js +// d.origin viene dal joint, d.axis dal joint, d.child dal joint +const T1 = new THREE.Matrix4().makeTranslation(d.origin.x, d.origin.y, d.origin.z); +const R = new THREE.Matrix4().makeRotationAxis(d.axis, value); +const T2 = new THREE.Matrix4().makeTranslation(-d.origin.x, -d.origin.y, -d.origin.z); +// la matrice ottenuta viene poi applicata a `child` e a tutti gli oggetti in `rigidComponent` +``` +Quindi sì, serve premere `Switch` in Fusion. Stessa verifica da fare per `Motore asse Y`, `Asse Penna `, `asse Z pneumatico M5?` e `Motore A` (asBuilt): controllare per ognuno che `child` = il pezzo che si muove rispetto al telaio del livello precedente, `parent` = il pezzo solidale al livello precedente. + +In ogni caso il fix è **lato Fusion**, non lato codice viewer. ### Patch temporanea lato viewer (in valutazione, non ancora applicata) -Se i fix 1-3 lato Fusion richiedono tempo, lato viewer posso aggiungere: -- una mappa `viewerOverrides.json` con `{ jointName: { swapParentChild: true } }` per simulare il fix BUG 3 senza modificare l'export -- una mappa `viewerRigidGroups.json` con i contenuti che `Gruppo rigido N` dovrebbe avere, in attesa del fix BUG 1 -- una mappa `viewerMotionLinks.json` per ricostruire i `joint1` mancanti del BUG 2 - -Sono workaround sporchi: preferisco fixare l'export quando possibile e tenere il viewer privo di patch ad-hoc. Fammi sapere se preferisci che proceda comunque con gli override per sbloccare le demo nel frattempo. +~~Override `viewerOverrides.json` / `viewerRigidGroups.json` / `viewerMotionLinks.json`.~~ Saltato. Visto che BUG 1 non esiste e BUG 2 non è bloccante per i driver puri (la propagazione passa dai rigid groups, che ora il viewer legge correttamente), aspetto solo il fix Fusion del BUG 3 e proviamo subito. ### Per gli altri driver