|
| 1 | +# Kernel Ask Report for Production B-Rep Editor |
| 2 | + |
| 3 | +Date: 2026-03-21 |
| 4 | +Kernel audited: `../OpenGeometry-Kernel/main/opengeometry` and `../OpenGeometry-Kernel/main/opengeometry-three` |
| 5 | + |
| 6 | +--- |
| 7 | + |
| 8 | +## 1) Recheck Summary |
| 9 | + |
| 10 | +The kernel has a solid editable B-Rep baseline and currently passes editor tests, including: |
| 11 | + |
| 12 | +- face push/pull |
| 13 | +- face/edge/vertex move |
| 14 | +- topology render data |
| 15 | +- edit result payload control flags |
| 16 | + |
| 17 | +Confirmed by local test run: |
| 18 | + |
| 19 | +- `cargo test editor::tests -- --nocapture` |
| 20 | +- Result: `7 passed, 0 failed` |
| 21 | + |
| 22 | +--- |
| 23 | + |
| 24 | +## 2) What Is Already Good Enough |
| 25 | + |
| 26 | +## 2.1 Editable operations exist and are wired to JS/TS wrappers |
| 27 | + |
| 28 | +- Rust exports: |
| 29 | + - `pushPullFace`, `moveFace`, `moveEdge`, `moveVertex` |
| 30 | + - [mod.rs](/Users/vishwajeetmane/Work/OpenGeometry/OpenGeometry-Kernel/main/opengeometry/src/editor/mod.rs#L202) |
| 31 | +- TS wrapper mirrors these methods: |
| 32 | + - [editor.ts](/Users/vishwajeetmane/Work/OpenGeometry/OpenGeometry-Kernel/main/opengeometry-three/src/operations/editor.ts#L198) |
| 33 | + |
| 34 | +## 2.2 Polygon can enter editable B-Rep pipeline |
| 35 | + |
| 36 | +- `Polygon` exposes B-Rep payload: |
| 37 | + - `getBrepData()` |
| 38 | + - [polygon.ts](/Users/vishwajeetmane/Work/OpenGeometry/OpenGeometry-Kernel/main/opengeometry-three/src/shapes/polygon.ts#L469) |
| 39 | +- `createEditableBrepEntity()` accepts `getBrepData/getBrepSerialized`: |
| 40 | + - [editor.ts](/Users/vishwajeetmane/Work/OpenGeometry/OpenGeometry-Kernel/main/opengeometry-three/src/operations/editor.ts#L251) |
| 41 | + |
| 42 | +## 2.3 Topology remap payload exists |
| 43 | + |
| 44 | +- `topology_changed` and `topology_remap` are returned in edit results: |
| 45 | + - [mod.rs](/Users/vishwajeetmane/Work/OpenGeometry/OpenGeometry-Kernel/main/opengeometry/src/editor/mod.rs#L359) |
| 46 | + |
| 47 | +--- |
| 48 | + |
| 49 | +## 3) Production Gaps and Kernel Asks |
| 50 | + |
| 51 | +## P0 (Blockers for robust CAD-grade behavior) |
| 52 | + |
| 53 | +### P0.1 Face extrude operation (true topology-creating push/pull) |
| 54 | + |
| 55 | +Current `push_pull_face_internal` moves existing face vertices along normal, then recomputes normals: |
| 56 | + |
| 57 | +- [edits.rs](/Users/vishwajeetmane/Work/OpenGeometry/OpenGeometry-Kernel/main/opengeometry/src/editor/edits.rs#L27) |
| 58 | + |
| 59 | +This is not sufficient for planar polygon "push/pull to solid" workflows expected in CAD. |
| 60 | + |
| 61 | +Ask: |
| 62 | + |
| 63 | +- Add `extrudeFace(face_id, distance, options)` on editable entity. |
| 64 | +- It must create proper side faces + cap/bottom topology where applicable. |
| 65 | +- Return standard `BrepEditResult` with topology changes. |
| 66 | + |
| 67 | +Acceptance: |
| 68 | + |
| 69 | +- extruding a single-face polygon creates a watertight prism-like shell (unless explicitly open-surface mode). |
| 70 | +- face/edge/vertex IDs remap correctly after extrusion. |
| 71 | + |
| 72 | +### P0.2 Real semantic topology remap from actual edits |
| 73 | + |
| 74 | +Current remap builder used in edit result is domain default mapping: |
| 75 | + |
| 76 | +- [remap.rs](/Users/vishwajeetmane/Work/OpenGeometry/OpenGeometry-Kernel/main/opengeometry/src/editor/remap.rs#L106) |
| 77 | + |
| 78 | +This mostly maps `old_id -> same_id if still present`, or deleted. |
| 79 | +`split/merged` support is currently synthetic via helper tests, not emitted by real topology-changing ops. |
| 80 | + |
| 81 | +Ask: |
| 82 | + |
| 83 | +- Replace default ID-overlap remap with edit-aware remap generation for each topology-changing operation. |
| 84 | +- Ensure `status` reflects real behavior (`split`, `merged`, `deleted`, `created`, `unchanged`). |
| 85 | +- Ensure `primary_id` is deterministic and useful for selection continuity. |
| 86 | + |
| 87 | +Acceptance: |
| 88 | + |
| 89 | +- topology-changing ops produce non-identity remap entries in real edit tests. |
| 90 | +- remap is deterministic across repeated identical operation sequences. |
| 91 | + |
| 92 | +### P0.3 Created-ID reporting contract |
| 93 | + |
| 94 | +`TopologyRemapStatus` includes `Created`, but current remap structure is `old_id -> new_ids`; it has no first-class entries for purely new IDs. |
| 95 | + |
| 96 | +Ask: |
| 97 | + |
| 98 | +- Add explicit created-feature reporting, either: |
| 99 | + - a `created_ids` section per domain, or |
| 100 | + - a remap schema that can encode created entries without `old_id`. |
| 101 | +- Keep backward compatibility or version payload (`topology_remap_v2`) if needed. |
| 102 | + |
| 103 | +Acceptance: |
| 104 | + |
| 105 | +- editor can select newly created face/edge/vertex from result payload without heuristic scan. |
| 106 | + |
| 107 | +## P1 (Strongly recommended for v1 UX quality) |
| 108 | + |
| 109 | +### P1.1 Topology-edit operations for 2D/polygon workflows |
| 110 | + |
| 111 | +Needed for direct polygon/ polyline-like editing ergonomics: |
| 112 | + |
| 113 | +- `insertVertexOnEdge(edge_id, t_or_position, options)` |
| 114 | +- `removeVertex(vertex_id, options)` with validity guards |
| 115 | +- optional: `splitEdge(edge_id, t, options)` |
| 116 | + |
| 117 | +Acceptance: |
| 118 | + |
| 119 | +- polygon point insertion/removal works through kernel ops. |
| 120 | +- remap and validity are returned consistently. |
| 121 | + |
| 122 | +### P1.2 Constraint-aware edit operations |
| 123 | + |
| 124 | +Current move ops are free-vector transforms and can unintentionally break intended constraints (coplanar editing, axis constraints). |
| 125 | + |
| 126 | +Ask: |
| 127 | + |
| 128 | +- Add operation variants/flags: |
| 129 | + - plane constrained |
| 130 | + - axis constrained |
| 131 | + - preserve coplanarity for selected contexts |
| 132 | + |
| 133 | +Acceptance: |
| 134 | + |
| 135 | +- same operation with constraints yields deterministic constrained geometry without UI-side post-fix hacks. |
| 136 | + |
| 137 | +### P1.3 Capability discovery API |
| 138 | + |
| 139 | +Editor needs to know what controls to show/hide per entity/feature. |
| 140 | + |
| 141 | +Ask: |
| 142 | + |
| 143 | +- Add `getEditCapabilities()` at entity and/or feature level: |
| 144 | + - e.g. `canPushPullFace`, `canExtrudeFace`, `canMoveEdge`, `canInsertVertex`, etc. |
| 145 | + |
| 146 | +Acceptance: |
| 147 | + |
| 148 | +- UI does not expose invalid operations and avoids trial-and-error calls. |
| 149 | + |
| 150 | +## P2 (Scale/performance and robustness) |
| 151 | + |
| 152 | +### P2.1 Delta payload support |
| 153 | + |
| 154 | +Current result can include full serialized geometry; useful but heavy under repeated drags. |
| 155 | + |
| 156 | +Ask: |
| 157 | + |
| 158 | +- Optional changed-domain delta payloads (`changed_faces`, `changed_edges`, etc.) to reduce bandwidth/work. |
| 159 | + |
| 160 | +### P2.2 Better validity diagnostics taxonomy |
| 161 | + |
| 162 | +Current validity returns warnings/errors strings. Helpful, but categorization would improve UX. |
| 163 | + |
| 164 | +Ask: |
| 165 | + |
| 166 | +- Add machine-readable codes/severity per diagnostic entry. |
| 167 | + |
| 168 | +--- |
| 169 | + |
| 170 | +## 4) Explicit Notes About Polygon Editing |
| 171 | + |
| 172 | +- Polygon edge/vertex dragging is feasible today via editable B-Rep `moveEdge/moveVertex` after creating editable entity from polygon B-Rep. |
| 173 | +- Polygon "push/pull" today is geometric face translation, not solid extrusion. |
| 174 | +- For AutoCAD/Blender-like expected push/pull on polygon faces, `extrudeFace` is the key missing operation. |
| 175 | + |
| 176 | +--- |
| 177 | + |
| 178 | +## 5) Minimal Kernel API Ask Set (If You Want Strict MVP) |
| 179 | + |
| 180 | +If we only request the minimum to unblock production editor quality: |
| 181 | + |
| 182 | +1. `extrudeFace(...)` |
| 183 | +2. true semantic remap for topology-changing ops |
| 184 | +3. created-ID reporting in edit result |
| 185 | +4. `insertVertexOnEdge(...)` and `removeVertex(...)` |
| 186 | + |
| 187 | +Everything else can follow in later iterations. |
0 commit comments