Hartmut/HartOMat
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: learning erfasst - OCC face_loc behavior und GLB-Cache-Invalidierung nach Tessellierungs-Fixes

Browse Source 
Dokumentiert drei neue Learnings aus der GE360-HF Wälzkörper-Positions-Untersuchung:
1. BRepMesh auf Compound: Triangulation in Definition-Space, Face-loc = Instance-Placement
2. IsSame() vs IsPartner() für Assembly-Instanz-Deduplizierung
3. Stale GLB-Cache maskiert Code-Fixes — nach Tessellierungs-Änderungen Cache invalidieren

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
Hartmut Nörenberg
2026-03-12 18:08:48 +01:00
parent de7f97be87
commit 71584edce6
2 changed files with 139 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
LEARNINGS.md
+9
View File
@@ -462,3 +462,12 @@ OCC `linear_deflection=0.1mm` auf einem 50mm-Zylinder → Kantenlänge ~5mm. GMS
### 2026-03-12 | GMSH | Priority 3 vollständig — GMSH-Pipeline Status
GMSH 4.15.1 in render-worker installiert. `tessellation_engine=gmsh` ist der aktive DB-Default. `_tessellate_with_gmsh()` in `export_step_to_gltf.py` vollständig: `CharacteristicLengthMax = linear_deflection × 50`, `MinimumCirclePoints = min(12, ...)`, REVERSED Solids bleiben erhalten (kein invertierter Jacobian). Produktion-GLB nutzt Cache-Reuse (kein Re-Tessellieren bei Materialwechsel). Sharp-Edge-Extraktion läuft nach Tessellierung unabhängig vom Engine-Typ — `Injected N segment pairs into GLB extras` gilt für beide Pfade.
### 2026-03-12 | OCC | BRepMesh auf Compound: Triangulation in Definition-Space, Face-loc = Instance-Placement
`BRepMesh_IncrementalMesh(compound)` tesselliert alle Faces in Definition-Space-Koordinaten. Für Instanzen mit Placement enthält `face.Location()` (= `TopoDS_Shape`-Location) die Instance-Transformation. `BRep_Tool.Triangulation_s(face, loc)` gibt die Triangulation-Knoten in Definition-Space zurück, `loc` enthält die Face-Location (= Instance-Placement). `BRep_Builder.UpdateFace(face_def, tri)` mit einer aus `solid.Located(TopLoc_Location())` gewonnenen Face schreibt auf das geteilte TShape — ALLE Instanzen der gleichen Geometrie sehen die neue Triangulation, da sie IsPartner teilen.
### 2026-03-12 | OCC/XCAF | IsSame() vs IsPartner() — Deduplizierung bei Assembly-Instanzen
`IsSame()` prüft TShape-Pointer UND Location → für 16 Instanzen desselben Wälzkörpers sind alle 16 "unique" (unterschiedliche Location). `IsPartner()` prüft nur TShape-Pointer → gibt 9 tatsächlich unterschiedliche Geometrien. In `export_step_to_gltf.py` GMSH-Schleife: `IsSame()`-Deduplizierung tesselliert alle 16 Instanzen separat, aber da sie das gleiche TShape teilen, werden alle 16 mal auf dasselbe TShape geschrieben (idempotent, korrekt). `RWGltf_CafWriter` traversiert XCAF-Labelhierarchie und liest Triangulation von Definition-Labels (Identity-Location) — kein Double-Transform.
### 2026-03-12 | Debugging | Stale GLB-Cache maskiert Code-Fixes
Bug "Wälzkörper an falscher Position" war in Code durch commit 638b93b (IsSame-Fix) bereits behoben. Aber gecachtes Produktions-GLB (vor dem Fix generiert) zeigte weiterhin falsche Positionen im Viewer. Lösung: Geometry-GLB manuell neu generieren oder `step_file_hash = NULL` in DB um Cache-Invalidierung zu erzwingen. Nach Code-Fixes an Tessellierung/Export IMMER alle betroffenen GLB-Caches invalidieren.