# Edge classification scheme (BIM → 2D projection, elevations/orthographic views)

## Overview

Every drawn edge is assigned to exactly one of five classes: **outline**, **sharp**, **crease**,
**flush**, or **boundary**. Classification runs in a fixed order, using topology first, then
projected geometry, then dihedral angle.

Non-manifold edges (3+ faces sharing an edge) are a geometry-health / QA concern, not an
architectural line category, and are not part of this scheme. Flag them separately in a
debug/QA view if useful.

Visibility (solid vs. dashed rendering based on view occlusion) is a separate, orthogonal
system and applies independently to any of the classes below — a hidden sharp edge is still
sharp, just drawn dashed.

## Classes

| Class | Trigger | Default |
|---|---|---|
| **Boundary** (naked) | Edge belongs to only one face | Always drawn |
| **Outline** | Edge lies on the projected silhouette — either object-vs-background or self-occluding (same object behind) | Always drawn |
| **Sharp** (ridge) | Signed dihedral angle deviation from flat is convex and its magnitude exceeds `ridgeAngleMin` | Always drawn |
| **Crease** (valley) | Signed dihedral angle deviation from flat is concave and its magnitude exceeds `valleyAngleMin` | Always drawn |
| **Flush** | Deviation magnitude falls below the applicable threshold for its sign (not "coplanar" — a 5° edge isn't coplanar, just below the noise floor) | Suppressed by default, toggle-able |

Sharp and crease are opposite signs of the same measurement, not two magnitudes of the same
fold direction. **Crease is a valley (concave)**, **sharp is a ridge (convex)**. This requires
a **signed** dihedral angle deviation from flat (180°) — positive for convex folds, negative
for concave — rather than an absolute value.

## Evaluation order

1. **Boundary** — if an edge has only one adjacent face, there's no second face to measure an
   angle against, so this is tested before any angle-based logic runs.
2. **Outline** — overrides the angle-based bucket. A flush edge that happens to sit on the
   projected silhouette is still drawn as an outline, not suppressed as flush.
3. **Angle-based bucket** (sharp / crease / flush) — for anything not already classified as
   boundary or outline, via the two thresholds below.

## Thresholds

Two independent settings, each a magnitude compared against the deviation on its respective
side of zero:

- `ridgeAngleMin` — minimum convex deviation to classify as **sharp**
- `valleyAngleMin` — minimum concave deviation to classify as **crease**

Anything with a smaller magnitude than the applicable threshold, on either side, is **flush**.

Keeping these separate allows ridges and valleys to read at different sensitivities — for
example, valleys often read as visually softer than ridges at the same angle, so
`valleyAngleMin` might reasonably be set higher than `ridgeAngleMin`.

# SVG edge classification (issue #3668) — root cause confirmed + implementation plan

## Context

[GH issue #3668, comment](https://github.com/IfcOpenShell/IfcOpenShell/issues/3668#issuecomment-2489524775)
originally asked for OpenCASCADE-linework SVG output to classify each **projection edge** (not
cut/section edges) by a rough contour/crease/sharp/hidden heuristic, so CSS could style them
differently and fix the "ugly faceted sphere" rendering problem shown in the issue. That naming
has since been superseded by [`edge-classification.md`](edge-classification.md) — the
authoritative scheme for this plan, five classes: **boundary**, **outline**, **sharp**,
**crease**, **flush** (see "Nomenclature correction" below for the full mapping and why it's
more than a rename).

Three prior attempts exist as detached worktrees
(`StagingPost.worktrees/origin-feature-svg-edge-classification-3668{,-2,-3}`), plus raw
source dumps in `../archive_failed_SvgSerialiser` and `../SvgSerialiser_patchset`. All were
abandoned as non-working. This plan is based on a full read of the current `v0.8.0`
`SvgSerializer.cpp`/`.h`, `operator.py`, and a diff/history review of all three WIP branches.

## Hypothesis check: confirmed, but the real fix is different from what was tried

The user's hypothesis — "a Python function recreates edges with `class="projection"` and
discards our classification" — is **directionally correct but the mechanism is different
from what it looks like at first**, which is why fixing the C++ alone never worked. Two
independent things were wrong:

**1. `merge_linework_and_add_metadata` (`src/bonsai/bonsai/bim/module/drawing/operator.py:1440-1471`)
does wholesale-overwrite the `class` attribute of every per-element `<g guid=...>` it visits:**

```python
if "projection" in el.get("class", "").split():
    classes = self.get_svg_classes(element)   # freshly built from IFC type/material/layer
    classes.append("projection")
    el.set("class", " ".join(classes))          # <-- replaces the WHOLE attribute
    continue
```

`get_svg_classes()` only knows about IFC semantics (entity type, material, layer, psets) —
it has no idea any geometric edge-classification token like `contour`/`crease` ever existed,
so any such token present on that `<g>` is silently dropped.

**2. But all three WIP branches implemented classification at the wrong granularity.** In
`draw_hlr()` (`SvgSerializer.cpp:1769-1831` on current `v0.8.0`; see commits `46ae0f401e` →
`c631de8eea` → `b8b1f2f1d8` on the worktree branches), they bucketed edges into **multiple
`<g>` groups per product** — one group per class (`grouped_paths` map / `get_group(cls)`
lambda in the WIP), each still carrying the product's `guid`. Every one of those per-class
groups independently matches the `for el in root.findall(".//g[@guid])")` loop in
`merge_linework_and_add_metadata` and independently hits the `"projection"` branch above,
so **every bucket's distinguishing class gets wiped, every time**. The confirmed diagnostic
step the user already ran — commenting out the `self.merge_linework_and_add_metadata(root)`
call (see `archive_failed_SvgSerialiser/.../diff_against_hash-00ec587_partial_svgserialiser.diff`
lines 22-25) and dumping the raw pre-merge SVG — is exactly the right test and would have
shown the classes present before, and gone after, that call.

There is a **third, independent bug** found in the final commit of two of the branches
(`2d8d351652`/`db28eba138`, "last svg classification attempt this branch"): the
`classify_edge_from_faces()` function has a stray, unreachable `return edge_style_class::contour;`
placed right after the face-count check, added during a debugging session (alongside a debug
counters struct and a `"debug-draw-hlr-hit "` class tag) — **all edges therefore always
classified as `contour` regardless of geometry**, independent of the Python problem above.
This means at least one of the "even when we thought it should work" failures was a genuine,
separate C++ regression, not just the Python overwrite.

## Nomenclature correction (post-review with the user)

The `.hidden { stroke-dasharray: 3, 2; }` rule in `sample.css:24` — which the previous draft of
this plan assumed was added in anticipation of this feature — **predates it and is unrelated**:
it's the existing generic dashed-line convention for occluded/hidden-line rendering, orthogonal
to edge classification. Re-examining the WIP's naming against
[`edge-classification.md`](edge-classification.md) (the user's cleaned-up scheme, worked out
with a separate AI chat) shows the WIP's naming was muddled, and — beyond naming — the bucket
*logic* needs to change too, not just the labels. The corrected scheme has **five classes**:
`boundary`, `outline`, `sharp`, `crease`, `flush`. Mapping from the old WIP concepts:

- Old **contour** (front/back face-normal sign flip) → **`outline`**. Same test, same code path
  — this part of the WIP genuinely does align, per the user's expectation.
- Old lumping of 0/1-adjacent-face edges into `contour` → these are now their own class,
  **`boundary`** (naked edges), always drawn, tested *before* any angle logic — not merged into
  `outline`.
- Old **unsigned** dihedral magnitude with three bands (`<12°→crease`, `12–45°→hidden`,
  `>45°→sharp`), gated on "both faces must face the camera" → replaced by a **signed** deviation
  from flat (convex vs. concave), tested regardless of camera-facing (see scope note below for
  why that gating no longer matters here), with **two independent per-sign thresholds**
  (`ridgeAngleMin` for convex/`sharp`, `valleyAngleMin` for concave/`crease`) and anything below
  the applicable threshold on either side is **`flush`** (suppressed by default, toggle-able) —
  this replaces old `hidden`/`svg_emit_hidden_edges` (rename to avoid clashing with the
  unrelated visibility `.hidden` CSS class).
- **This is not just a rename**: getting the *sign* (convex ridge vs. concave valley) requires
  more than the old code computed. The old `angle_deg_between(n0, n1)` (via `acos(dot)`) only
  ever gives an unsigned magnitude. Determining convexity needs the edge's tangent direction
  too — the standard technique is the sign of `cross(n0, n1) · edge_tangent` (consistently
  oriented using each face's `TopAbs_REVERSED` flag, same as the WIP's existing
  `face_normal_from_planar_face()` already does for the normals themselves). This sign
  computation must be added; it wasn't present in any of the 3 prior attempts.
- Non-manifold edges (3+ adjacent faces) are explicitly **out of scope** for the 5-class scheme
  per the doc — a geometry-health/QA concern, not an architectural line category. Don't bucket
  them into any of the 5 classes; either skip them or (optionally, if trivial) tag them with a
  distinct non-scheme debug class, but don't force-fit them into `boundary` or `outline`.

**Scope decision (confirmed with user):** implement all 5 classes for **visible edges only** —
i.e. classify edges within the existing HLR-visible edge set that `draw_hlr()` already receives
today (`occt_join(OutLineVCompound, VCompound)`), matching all 3 prior WIP attempts and the
original issue's scope. The doc's statement that "visibility is a separate, orthogonal system...
a hidden sharp edge is still sharp, just drawn dashed" describes the *conceptual* model but
**full occlusion-aware dashed rendering of hidden edges in every class is deferred to a future
issue** — it would require pulling OCCT's hidden-edge HLR compounds (`OutLineHCompound`,
`HCompound`, etc.), which none of the prior attempts touched and is materially more work. One
consequence: since everything reaching `draw_hlr()` is already visibility-filtered by OCCT, the
old WIP's "both faces must face the camera" precondition before angle-bucketing is now moot —
just classify every non-boundary, non-outline, non-manifold-excluded edge in the visible set by
signed dihedral angle.

## Recommended fix: classify per `<path>`, not per `<g>` — sidesteps the Python overwrite entirely

`SvgSerializer::write(path_object& p, const TopoDS_Shape&, ...)` (`SvgSerializer.cpp:108-370`)
already emits **one `<path>` element per edge** when called from `draw_hlr` (one call to
`write(*po, w)` per edge at `SvgSerializer.cpp:1822-1827` — `path_object` is literally
`std::pair<std::string group-attrs, std::vector<string_buffer> paths>`, i.e. one shared group
with many independent `<path>` children). This means we do **not** need multiple `<g>` groups
per product to express per-edge classes — we can tag the **individual `<path>` tag** instead.

Crucially, `merge_linework_and_add_metadata`'s `"projection"` branch does `el.set("class", ...)`
on the `<g>` **and then `continue`s immediately** — it never descends into or touches child
`<path>` elements' own `class` attributes. So a `class="outline"` (or `sharp`/`crease`/`flush`/
`boundary`) attribute placed directly on a `<path>` tag survives this function untouched, and
CSS rules like `.outline { stroke: ...; }` win over the ancestor `.projection { stroke: black; }`
rule because directly-matched styles always beat inherited ones in CSS, regardless of
specificity.
**This means `operator.py` likely needs no change at all** for this to work — confirm this
during implementation rather than assuming it, since `generate_freestyle_linework()`
(operator.py:868) and a couple of other spots do touch group classes and should be checked too.

This also means we should **not** resurrect the WIP's `grouped_paths`/`get_group()` bucketing
approach — it's the thing that caused the Python clobbering, is more complex, and risks other
code that assumes one non-cut `<g>` per guid per drawing (e.g. `move_projection_to_bottom`,
the SVGFILL raycast block). Classify-and-tag-per-path is strictly simpler.

### C++ implementation

## STATUS UPDATE (implementation session, blocked — see below)

Implemented and empirically verified working, on branch `feature-svg-edge-classification-3668-4`:
- Settings `SvgRidgeAngleMinDegrees`/`SvgValleyAngleMinDegrees`/`SvgEmitFlushEdges` in
  `ConversionSettings.h`, read in `SvgSerializer::ready()`, confirmed showing up correctly as
  `--svg-ridge-angle-min-degrees`/`--svg-valley-angle-min-degrees`/`--svg-emit-flush-edges` in
  `IfcConvert --help`.
- `write(path_object&, ...)` now takes an optional `css_class` and emits it as `class="..."` on
  the individual `<path>` tag — confirmed in raw SVG output (`path.outline`/`.boundary`/etc. CSS
  rules render correctly in the `<style>` block).
- `classify_edge_from_faces()` and the 5-class enum are implemented per the scheme below.
- **Python wiring correction (deviates from the plan text as originally approved):** the new
  settings belong on `self.svg_settings` (`ifcopenshell::geometry::Settings`, read via
  `geometry_settings()` in C++), **not** `self.serialiser_settings`
  (`ifcopenshell::geometry::SerializerSettings` — a disjoint tuple for unrelated things like
  `UseElementGuids`). The WIP branches and this plan's original wording both had this backwards;
  `self.serialiser_settings.set("svg-ridge-angle-min-degrees", ...)` would have silently done
  nothing (or thrown) since that key doesn't exist in that container. Fixed in
  `operator.py:setup_serialiser()`.
- Decided **not** to add `prop.py`/`ui.py` panel entries: none of the existing similar
  operator-only flags (`sync`, `print_all`, `open_viewer`) are exposed in `ui.py` either — they
  rely on the operator's own redo-panel. Matching that convention, the three new properties live
  only on the `CreateDrawing` operator.

**RESOLVED.** Root cause and fix, in order of discovery:

1. First attempt (matching `b8b1f2f1d8`'s approach): build the edge→faces map from
   `hlr_compound_unmirrored` (HLR's own output). **Always empty** —
   `HLRBRep_HLRToShape`'s output compounds contain only `TopAbs_EDGE` shapes, no `TopAbs_FACE` at
   all (confirmed via OCCT's own header docs: *"these 2D edges are not included in the data
   structure of the visualized shape"* — true for both the BRep and poly HLR engines).
2. Second attempt: build the map from the pre-HLR original solid instead. Non-empty map, but
   **still zero matches** looking up HLR-output edges in it — `HLRBRep_HLRToShape` reconstructs
   new `TopoDS_Edge` objects, it doesn't preserve the original edge's identity even when fully
   visible/untrimmed.
3. **The actual fix**, empirically verified via a standalone OCCT program (see below): don't
   classify HLR's output at all. `HLRBRep_HLRToShape::VCompound(const TopoDS_Shape& S)` /
   `OutLineVCompound(const TopoDS_Shape& S)` filter the algorithm's internal results down to a
   caller-supplied shape `S`, correlating by the identity of the **original input edges** (not
   the reconstructed output) — exactly how `hlr_calc` already gets correct per-product
   breakdown today. So: classify the original, pre-HLR edges (real face topology, trivially
   reliable) into up to 5 class-labeled **edge-only** sub-compounds per product, register them
   via a new `hlr_t::add_classified_edges(product, class, edges)`, and let `hlr_calc::extract()`
   query `VCompound(bucket)`/`OutLineVCompound(bucket)` per bucket — `draw_hlr()` then already
   knows each edge's class, no post-hoc guessing at all.

   Isolated verification (`test_hlr_filter2.cpp`, a 12-edge box): summing `VCompound(bucket)` over
   each of the 12 individual edges as its own one-edge bucket reproduced the unfiltered
   `VCompound()` total exactly (9 visible edges either way) — confirming edge-only `S` shapes
   correlate correctly with no faces required in the filter shape.

Implemented in `SvgSerializer.h`/`.cpp` on branch `feature-svg-edge-classification-3668-4`:
`hlr_calc::result_type` is now `list<tuple<product, class-name, compound>>`; `prefiltered_hlr`
gained `classified_items_` + `add_classified_edges()`; classification happens once, right where
`hlr->add(*compound_to_hlr, data.product)` is already called in `write(const geometry_data&)`;
`draw_hlr()` groups results by product (one shared `path_object`/`<g>` per product, as before —
no bucketing into multiple groups) and writes each bucket's edges with its already-known class.

**Verified working end-to-end at the C++ level** on the hand-built L-shape+box test IFC: real,
differentiated classes now appear (`10 outline`, `27 sharp` in one run) instead of 100%
`boundary`. Zero `crease` results in that specific run turned out to be a property of the test
geometry/view combination (axis-aligned box+L-shape viewed from 4 axis-aligned cardinal
elevations — the concave notch's two walls never happened to be simultaneously front-facing from
those exact angles), not a bug — confirmed by a separate isolated unit test
(`test_sign.cpp`) exercising `classify_edge_from_faces()` directly with synthetic convex/concave
face pairs under a view direction chosen to make both faces of each fold simultaneously
front-facing: convex → `deviation_deg=+90` → `sharp` ✓, concave → `deviation_deg=-90` → `crease`
✓. Sign convention confirmed correct.

**Remaining to verify:** whether `merge_linework_and_add_metadata` leaves per-path classes intact
end-to-end through Bonsai, and a full Blender `Create Drawing` run.

**Attempted, blocked by an environment issue (not a code issue):** built a self-contained headless
Blender script (no UI clicking — `bpy.ops.bim.create_project`/`assign_class`/`add_drawing`
(`target_view="ELEVATION_VIEW"`)/`save_project`/`activate_drawing`/`create_drawing`) using the
`bonsai_test` profile + debug-build Blender ([[project_blender_test_profile]]). It got through the
whole pipeline (project creation → wall → elevation drawing → real SVG output) with no crashes,
but the produced SVG's `<path>` elements had **no class attribute at all** — not even the old
`cut`/`projection` group-level behavior being wrong, just genuinely absent per-path classes.
Debug instrumentation (temporary `std::ofstream` writes to `/tmp/svg_classify_debug.log` at
several points in the C++ call chain, since `logger_.Warning(...)` calls don't surface anywhere
visible when driven via the Python bindings) proved the debug lines **never fired at all** —
i.e. code I knew was being exercised (verified moments earlier via `IfcConvert`) wasn't running.
Root cause: `strings <the loaded .so> | grep <a marker string only in the new build>` showed the
marker present in the checkout's freshly-built `.so` but **absent** in the copy Blender actually
loaded from `bonsai_test`'s extension directory, and that file's mtime changed *during* the
Blender run — confirmed Blender's own extension/wheel installer silently overwrites
`_ifcopenshell_wrapper.cpython-311-*.so` on every launch of this profile (even survived
replacing it with an explicit `ln -s` beforehand — got deleted and replaced with a plain file
again). This contradicts this project's own memory note claiming that file is symlinked like the
pure-Python packages; corrected that memory. Removed all the temporary debug instrumentation
before finishing (verified via `IfcConvert` that the classification behavior is unaffected).

**Net effect:** the C++ classification logic itself is verified correct and working (via
`IfcConvert` CLI + isolated OCCT unit tests) but this session could not get a live signal from
an actual Blender/Bonsai run, because of this test-harness limitation rather than anything wrong
with the feature. Whoever picks this up next should either fix the wheel-reinstall issue (find
what triggers it and disable/skip it for dev iteration) or rely on `IfcConvert` CLI testing plus
careful manual review of `merge_linework_and_add_metadata`'s interaction with per-path classes
(architecturally sound per the "Recommended fix" section above — it only rewrites `<g>`-level
`class`, never touches child `<path>` elements — but not yet seen operating on a real
Bonsai-generated SVG).

---

1. **Settings** (`src/ifcgeom/ConversionSettings.h`): add `SvgRidgeAngleMinDegrees` (convex/
   `sharp` threshold, default TBD e.g. 45.0), `SvgValleyAngleMinDegrees` (concave/`crease`
   threshold, default TBD e.g. 12.0 — the doc notes valleys often need a higher threshold than
   ridges to read the same, so don't assume symmetry), `SvgEmitFlushEdges` (default false —
   renamed from the WIP's `SvgEmitHiddenEdges` to avoid clashing with the pre-existing,
   unrelated `.hidden` visibility class). Follow the existing `SettingBase<...>` pattern (see
   e.g. `CgalSmoothAngleDegrees`) and add to the `Settings` tuple. Reuse the WIP's settings
   mechanism (commits `a5a7a71b72`/`15da588adb`) but drop the env-var fallback
   (`IFCOPENSHELL_SVG_*` getenv reads) — it duplicates the settings mechanism for no reason.

2. **Classification function** (new anonymous-namespace helper in `SvgSerializer.cpp`, near
   `draw_hlr`), implementing the 5-class scheme in evaluation order:
   - `enum class edge_style_class { boundary, outline, sharp, crease, flush };`
   - **Boundary**: 0 or 1 adjacent face → `boundary` (naked edge; no second face to measure
     against). Tested first.
   - **Outline**: exactly 2 adjacent planar faces, `projection_direction.Dot(normal)` sign
     differs between them (front/back flip) → `outline`. This is the WIP's existing `contour`
     logic (`c631de8eea`) reused as-is — the user's expectation that "the existing algorithm
     aligns" holds here.
   - **Non-manifold** (3+ adjacent faces): explicitly out of scope for the 5 classes — skip
     (don't emit/classify), or optionally tag with a distinct QA-only debug class if trivial;
     do not force into `boundary` or `outline`.
   - **Angle bucket** (remaining 2-planar-face, non-outline edges): compute the **signed**
     deviation from flat. Magnitude via the WIP's existing `acos(dot(n0, n1))`-based
     `angle_deg_between()`, deviation-from-180°-flat = `180 - angle_deg_between(n0, n1)` (confirm
     sign/offset convention empirically against a known convex/concave test case). Sign via
     `cross(n0, n1) · edge_tangent` (consistently oriented per each face's `TopAbs_REVERSED`,
     matching how `face_normal_from_planar_face()` already orients normals) — positive/convex
     vs. negative/concave. Then: `|deviation| < ridgeAngleMin` and convex, or
     `|deviation| < valleyAngleMin` and concave → `flush`; convex and `|deviation| >=
     ridgeAngleMin` → `sharp`; concave and `|deviation| >= valleyAngleMin` → `crease`.
   - Reuse the real bug fix from `b8b1f2f1d8`: build the edge→faces map from
     `hlr_compound_unmirrored` and iterate edges from that same unmirrored shape (mirroring
     only applied at write time), not from the possibly Y-mirrored `hlr_compound`.
   - **Do not** carry over the debug counters, the stray early `return contour`, the
     `try{ }catch` wrapping of the whole `write()` function, or the `debug-draw-hlr-hit` tag —
     leftovers from an unfinished debugging session on the WIP branches.
   - Any exception or non-planar-face case during classification should conservatively fall
     back to `outline`, matching the WIP's conservative-fallback intent.

3. **Wire it into `draw_hlr()`** (`SvgSerializer.cpp:1769-1831`): keep the **single**
   `path_object`/group per product exactly as today (no bucketing). Add an edge→faces map
   built once per HLR result (`TopExp::MapShapesAndAncestors(hlr_compound_unmirrored, ...)`),
   and for each edge in the existing `for (; exp.More(); exp.Next())` loop, classify it and
   pass the resulting CSS class token into `write()`.

4. **`write(path_object&, const TopoDS_Shape&, dash_array)` signature**
   (`SvgSerializer.cpp:108`, declared `SvgSerializer.h:644`): add an optional
   `boost::optional<std::string> css_class = boost::none` parameter. When present, emit
   `class="<value>"` on the individual `<path ...>` tag (alongside `d="..."` and the existing
   optional `stroke-dasharray`). All other call sites (`SvgSerializer.cpp:1337, 1403, 1576,
   1692` — annotations/cut-plane geometry) pass nothing and are unaffected. Skip emitting the
   class at all when `svg_emit_flush_edges_` is false and the class is `flush` — i.e. don't call
   `write()` for that edge (matches the doc's "suppressed by default, toggle-able").

5. **CSS** (`doWriteHeader()`, `SvgSerializer.cpp:2225-2271`, plus the shipped
   `src/bonsai/bonsai/bim/data/assets/default.css` / `sample.css`): add rules for `.boundary`,
   `.outline`, `.sharp`, `.crease`, `.flush`. **Do not reuse or touch the existing
   `.hidden { stroke-dasharray: 3, 2; }`** rule in `sample.css:24` — confirmed unrelated,
   predates this feature, and is the generic occluded/hidden-line visibility convention (a
   future, separate concern per the scope decision above). Pick distinct visual treatments per
   class (e.g. `.flush` likely wants a lighter/thinner stroke by default, given it's meant to be
   an unobtrusive fallback bucket even when shown).

### Bonsai (Blender) integration

6. **`src/bonsai/bonsai/bim/module/drawing/operator.py`**: reuse the WIP's `setup_serialiser()`
   wiring shape, renamed: `CreateDrawing.svg_ridge_angle_min_deg` /
   `svg_valley_angle_min_deg` / `svg_emit_flush_edges` props, passed via
   `self.serialiser_settings.set(...)` in a try/except for older ifcopenshell builds (see the
   worktree diff for the ~15-line block shape to follow, with names/defaults updated per the
   settings above). Keep clamping/swap-if-inverted logic only if it still makes sense for two
   independent, non-comparable thresholds (ridge and valley aren't on the same scale the way
   old crease/sharp were, so re-check whether a "swap if crossed" guard even makes sense here —
   it may not).
   **Verify (don't assume) whether `merge_linework_and_add_metadata` needs any change** — per
   the analysis above it shouldn't, since per-path classes aren't touched by that function, but
   confirm empirically by inspecting the finalized SVG (see Verification below) rather than
   trusting the static-analysis conclusion blindly.
7. **`src/bonsai/bonsai/bim/module/drawing/prop.py`** / **`ui.py`**: reuse the WIP's three
   property definitions and panel rows (renamed), exposing the two thresholds and the
   flush-edge toggle in the Create Drawing operator UI.

### Scope explicitly excluded

- Cut-plane/section edges (`BRepAlgoAPI_Section` path around `SvgSerializer.cpp:1433`,
  `class="cut ..."`) are **not** touched — the issue is specifically about the OpenCASCADE
  Linework/projection mode used for elevations, not plan/section cuts.
- Non-manifold edges (3+ faces) are out of scope for the 5-class scheme per the doc — QA/debug
  concern only, not to be force-classified.
- Occlusion-aware dashed rendering of hidden edges (any class, drawn dashed when occluded) is
  explicitly deferred — confirmed with the user as future work. This PR classifies only the
  edges already surviving today's visible-only HLR pass
  (`occt_join(OutLineVCompound, VCompound)`); no change to `HLRBRep_Algo`/`HLRBRep_PolyAlgo`
  itself or use of OCCT's hidden-edge (`*HCompound`) accessors.

### Known interaction to verify, not solve up front

`SvgSerializer.cpp:1128-1209` (`profile_edges` / `profile_threshold_`) already pre-filters
edges by a similar front/back-facing sign-flip test **before** HLR runs, for performance on
large element counts. When that pre-filter is active, some edges may never reach
`draw_hlr()`'s classification at all. Confirm during testing whether enabling both
`profile_threshold_` and edge classification on the same drawing produces surprising gaps, and
note the finding — don't need to fix it as part of this feature unless testing shows it's
broken.

## Files to change

- `src/ifcgeom/ConversionSettings.h` — 3 new settings.
- `src/serializers/SvgSerializer.h` — `write()` signature; possibly store
  `svg_ridge_angle_min_deg_`/`svg_valley_angle_min_deg_`/`svg_emit_flush_edges_` members.
- `src/serializers/SvgSerializer.cpp` — `ready()` (read settings), classification helper,
  `draw_hlr()`, `write(path_object&, ...)`, `doWriteHeader()` CSS.
- `src/bonsai/bonsai/bim/data/assets/{default,sample}.css` — new/reused class rules.
- `src/bonsai/bonsai/bim/module/drawing/operator.py` — settings wiring in `setup_serialiser()`;
  no change expected to `merge_linework_and_add_metadata` but verify.
- `src/bonsai/bonsai/bim/module/drawing/prop.py`, `ui.py` — threshold/toggle UI.

Follow AGENTS.md: keep this as a small number of independently-reviewable commits (e.g.
C++ classification+settings; CSS; Blender UI wiring), disclose AI assistance in commit bodies
per the repo's mandatory disclosure rule, and don't touch the abandoned worktrees or
`archive_failed_SvgSerialiser`/`SvgSerialiser_patchset` folders — they're reference material
only, not to be merged from directly (they contain the known-broken debug code).

## Verification plan

1. Build the modified C++ core using the existing local Docker build environment
   (`docker/ifcos_env` — see `docker/SKILL.md`) rather than a full from-scratch build.
2. Run `IfcConvert` directly on a small test IFC containing a curved/faceted shape (e.g.
   recreate the icosphere case from the issue screenshots, or use an existing sphere/dome test
   fixture if one exists under `test/input`) with an elevation/axonometric view, and inspect
   the raw output SVG's `<path>` elements for `class="boundary|outline|sharp|crease|flush"`
   attributes before any Bonsai/Python post-processing touches it — this isolates a correct C++
   implementation from the Python-integration question. Specifically check a known convex
   corner classifies `sharp` and a known concave fold classifies `crease` (not swapped) —
   this is the part most likely to have a sign-convention bug on first pass.
3. Then run the full pipeline through Bonsai's `Create Drawing` operator in the debug-build
   Blender + `bonsai_test` profile (see memory: Blender test profile) to confirm the classes
   survive `merge_linework_and_add_metadata` end-to-end into the cached SVG, and visually
   confirm the CSS renders outline/sharp/crease/boundary edges distinctly and (by default)
   suppresses `flush` edges — reproducing the icosphere comparison from the GitHub issue as the
   acceptance check.
4. Toggle `svg_emit_flush_edges` on and confirm `flush` edges appear per their new CSS rule, and
   confirm this is visually distinguishable from the pre-existing, unrelated `.hidden`
   dashed-line convention (don't let the two get confused in review).
5. No automated Python test currently exists for SVG serializer output (`grep` for
   `SvgSerializer`/`serializers.svg` under `src/ifcopenshell-python/test/` returns nothing) —
   this feature is verified visually/manually per the above; do not invent a new automated SVG
   diff test as part of this change unless the user asks for one separately.