Browser-BIM (cad): semantisches Modell, abgeleitete 2D/3D-Sichten, Zeichenwerkzeuge
Standalone-Browser-Port von DOSSIER. Enthaelt das semantische Modell mit Plan-/3D-Ableitung, Zeichen- und Editierwerkzeuge, Rhino-artiges Befehlssystem, dockbares Panel-System, Resource-Manager, DXF/.lin/.pat-Import, i18n (de/en) sowie Projektdokumentation und Probe-Harness.
This commit is contained in:
@@ -0,0 +1,54 @@
|
||||
# Kontextmenü & Anzeige-Modi — 1:1 wie DOSSIER
|
||||
|
||||
> Quelle: DOSSIER `src/components/ContextMenu.jsx` + `DrawingLevelsApp.jsx`/Ebenen-Panel.
|
||||
> Maus-Schema (unsere Festlegung): **Mitte = navigieren** (Plan Pan / 3D Orbit, Shift+Mitte Pan) ·
|
||||
> **Links = Auswahl** · **Rechts = Kontextmenü** · **Rad = Zoom**.
|
||||
|
||||
## ContextMenu-Komponente (generisch, wiederverwendbar)
|
||||
`ContextMenu({ x, y, items, onClose, title })`
|
||||
- **item**: `{ label, icon?, onClick, disabled?, danger?, shortcut?, divider? }`
|
||||
- Fixed-Position mit Rand-Clamp (4px); min-width 200px; Radius 13px; weicher Schatten;
|
||||
Mount-Animation `scale(.94) translateY(-5px)` 100ms; Item-Hover = `--accent-dim`;
|
||||
`danger` = rote Schrift; `divider` = 1px Trenner; Titel oben (caps, 10px, muted).
|
||||
- **Schließen:** Klick außerhalb · Escape · erneuter Rechtsklick · nach Item-Klick.
|
||||
- z-index ~300 (unter Modals).
|
||||
|
||||
## Ebenen-Kontextmenü (Rechtsklick auf Ebenen-Zeile)
|
||||
1. **Ebeneneinstellungen…** (`settings`) — Ebenen-Dialog *(Rhino-spez. → vorerst Stub)*
|
||||
2. — Trenner —
|
||||
3. **Sub-Ebene hinzufügen…** (`add`)
|
||||
4. **Selektion hierher übertragen** (`move_down`) *(braucht Auswahl → später)*
|
||||
5. — Trenner —
|
||||
6. **Duplizieren** (`content_copy`) — Klon mit Suffix „ KOPIE"
|
||||
7. **Eigenschaften kopieren** (`colorize`) — Farbe + Linienstärke
|
||||
8. **Eigenschaften einfügen** (`format_paint`) — disabled wenn Clipboard leer
|
||||
9. — Trenner —
|
||||
10. **Löschen** (`delete`, danger) — disabled wenn ≤1 Ebene
|
||||
Titel = Ebenenname/-code.
|
||||
|
||||
## Zeichnungsebenen-Kontextmenü (Rechtsklick auf Geschoss/Schnitt/Zeichnung)
|
||||
1. **Einstellungen…** (`settings`)
|
||||
2. — Trenner —
|
||||
3. **Duplizieren** (`content_copy`) — Klon mit Suffix „ Kopie"
|
||||
4. — Trenner —
|
||||
5. **Löschen** (`delete`, danger) — disabled wenn ≤1 Ebene
|
||||
Titel = Name.
|
||||
|
||||
## „+"-Menü (Zeichnungsebenen)
|
||||
**Geschoss** (`layers`) · **Schnitt / Ansicht** (`content_cut`) · — · **Zeichnung** (`edit_note`)
|
||||
|
||||
## Anzeige-Modi (Dropdown oben im Panel) — **5 Modi** (für Ebenen UND Zeichnungsebenen)
|
||||
| Wert | Label | Verhalten |
|
||||
|---|---|---|
|
||||
| `all_force` | **Alle anzeigen** | alle erzwungen sichtbar; Augen gedimmt; Klick aufs Auge → wechselt zu „Ausgewählte" |
|
||||
| `all` | **Ausgewählte** | sichtbar nach per-Zeile-Flag |
|
||||
| `active` | **Nur aktive** | nur aktive sichtbar; andere stark gedimmt |
|
||||
| `grey` | **Andere grau** | aktive normal, andere 45% (Sichtbarkeits-Flags gelten) |
|
||||
| `grey_locked` | **Andere grau & gesperrt** | wie grey + andere gesperrt |
|
||||
Regel: Klick aufs Auge in `all_force`/`active` schaltet automatisch auf `all`.
|
||||
*(Hinweis: Panel-System-Workflow hatte vorerst nur 3 Modi — beim Kontextmenü-Build auf diese 5 angleichen.)*
|
||||
|
||||
## Migration (was sofort geht / was Stub bleibt)
|
||||
- Sofort: ContextMenu-Komponente 1:1; Duplizieren, Eigenschaften kopieren/einfügen, Löschen,
|
||||
+Menü, 5 Anzeige-Modi (alles reine JSON-State-Operationen).
|
||||
- Stub/später: „Ebeneneinstellungen…"/„Einstellungen…" (Dialog), „Sub-Ebene hinzufügen", „Selektion hierher übertragen".
|
||||
@@ -0,0 +1,760 @@
|
||||
# Aktive Zeichen- und Bearbeitungs-Werkzeuge
|
||||
|
||||
Status: Entwurf. Dieses Dokument spezifiziert das **Tool-System** für das aktive
|
||||
Erzeugen von Modell-Elementen durch Zeichnen im Grundriss: Wände (Achs-Polylinie
|
||||
→ `Wall` eines `WallType`) sowie reine 2D-Geometrie (Linie, Polylinie, Rechteck,
|
||||
Kreis, Bogen, Text). Es definiert die Werkzeug-Zustandsmaschine, die Live-Vorschau
|
||||
(Rubber-Band), das **Snapping** mit Bildschirm-Markern, die Ebenen-/Kategorie-/
|
||||
Stil-Zuordnung neuer Elemente und das neue Element `Drawing2D` samt Ableitung in
|
||||
`generatePlan`.
|
||||
|
||||
Bezugsdokumente: [elements.md](elements.md) (Wand-/Tür-Modell),
|
||||
[resources-graphics.md](resources-graphics.md) (Stil-Auflösung),
|
||||
[plans-output.md](plans-output.md) (Papier-Maßstab, mm-Strichstärken),
|
||||
[context-menu.md](context-menu.md) (Maus-Schema).
|
||||
|
||||
## 0. Architektur-Prinzip (Bezug zum Repo)
|
||||
|
||||
Die App folgt der Regel **ein semantisches Modell ist die einzige Wahrheit; jede
|
||||
Ansicht ist abgeleitet** (CONVENTIONS.md, `App.tsx`). Werkzeuge greifen darum NUR über
|
||||
`setProject` immutabel auf das `Project`-Modell zu; sie schreiben NIE Geometrie
|
||||
direkt in den Plan. Der `PlanView` bleibt eine reine Darstellungs-/Eingabe-
|
||||
Schicht. Das Tool-System setzt genau an der bestehenden Naht in `PlanView` an:
|
||||
|
||||
- **Modell↔Screen.** `PlanView` rechnet bereits Cursor-Pixel → viewBox-Einheiten
|
||||
(`clientToView`) → Modell-Meter (`viewToModel`). Diese Umrechnung ist die
|
||||
Grundlage; Werkzeuge arbeiten ausschließlich in **Modell-Metern** (CONVENTIONS.md:
|
||||
intern alles in Metern). Für Snap-Marker brauchen Werkzeuge zusätzlich die
|
||||
Rückrichtung Modell → viewBox (`toScreen`, existiert bereits) bzw. Modell →
|
||||
Client-Pixel.
|
||||
- **Pointer-Handling.** `PlanView` besitzt heute drei Gesten an der linken Taste/
|
||||
Mitte/rechts: Auswahl/Marquee, Pan, Kontextmenü. Das Tool-System schiebt sich
|
||||
VOR diese Logik: ist ein aktives Zeichenwerkzeug gewählt (≠ `select`), übernimmt
|
||||
das Werkzeug `pointerdown/move/up`; das `select`-Werkzeug delegiert an die heute
|
||||
schon vorhandene Auswahl-/Marquee-Logik (kein Verhaltensbruch).
|
||||
- **Pan/Zoom bleiben immer aktiv.** Mittlere Maustaste (Pan) und Mausrad (Zoom)
|
||||
laufen unverändert weiter, auch während ein Zeichenwerkzeug aktiv ist — sonst
|
||||
kann man beim Zeichnen nicht navigieren.
|
||||
|
||||
## 1. Datenfluss-Überblick
|
||||
|
||||
```
|
||||
TopBar (Werkzeugleiste) --activeTool--> App-State
|
||||
│
|
||||
┌──── activeTool, wallTypeId, defaultCategoryCode ────┐
|
||||
▼ ▼
|
||||
PlanView ── pointerdown/move/up (Modellpunkt) ──> ToolController
|
||||
▲ │
|
||||
Snap-Marker + Rubber-Band-Overlay <── DraftState (Vorschau) ──┘
|
||||
│ │
|
||||
└──────────────── commit ──> onToolCommit(Element) ──> setProject
|
||||
```
|
||||
|
||||
`activeTool` und die Werkzeug-Parameter (aktiver `WallType`, Default-Kategorie)
|
||||
liegen als **View-State** in `App.tsx` — wie `viewType`, `detail`, `selectedWallIds`
|
||||
bereits dort liegen. Der `ToolController` ist **frameworkfrei** (reines TS, kein
|
||||
React-State pro Mausbewegung — analog zu `drag`/`marquee` als `useRef` in
|
||||
`PlanView`), damit die Live-Vorschau ohne Re-Render des ganzen Baums läuft. Nur
|
||||
beim **Commit** wird `setProject` (Re-Render) ausgelöst.
|
||||
|
||||
## 2. Koordinaten & Hilfsfunktionen
|
||||
|
||||
`PlanView` exportiert künftig zwei reine Konverter (heute intern vorhanden),
|
||||
plus die effektive Pixel-pro-Meter-Skala für die Snap-Toleranz:
|
||||
|
||||
```ts
|
||||
// PlanView-intern bereits da; wird als stabile Callbacks nach außen gereicht.
|
||||
type ToModel = (clientX: number, clientY: number) => Vec2; // Pixel → Meter
|
||||
type ToClient = (m: Vec2) => { x: number; y: number }; // Meter → Pixel
|
||||
type PxPerMeter = () => number; // aktuelle meet-Skala * PX_PER_M (Snap-Toleranz)
|
||||
```
|
||||
|
||||
`PxPerMeter` ergibt sich aus `meetScale(view) * PX_PER_M` (beides in `PlanView`
|
||||
vorhanden). Snap-Toleranzen werden in **Bildschirm-Pixeln** definiert (z. B. 10 px)
|
||||
und über `pxPerMeter` in Meter umgerechnet — so ist der Fangradius zoom-unabhängig
|
||||
konstant am Bildschirm.
|
||||
|
||||
## 3. Tool-System
|
||||
|
||||
### 3.1 Werkzeug-Identität und Registry
|
||||
|
||||
```ts
|
||||
export type ToolId =
|
||||
| "select" // Default: Auswahl/Marquee (heutiges Verhalten)
|
||||
| "wall" // Wand-Achs-Polylinie → Wall je Segment
|
||||
| "line" // einzelne 2D-Strecke
|
||||
| "polyline" // offene 2D-Polylinie
|
||||
| "rect" // 2D-Rechteck (zwei Ecken)
|
||||
| "circle" // 2D-Kreis (Zentrum + Radius)
|
||||
| "arc" // 2D-Bogen (3-Punkt oder Zentrum-Start-Ende)
|
||||
| "text"; // 2D-Textmarke
|
||||
|
||||
/** Live-Kontext, den ein Werkzeug bei jedem Schritt erhält. */
|
||||
export interface ToolContext {
|
||||
project: Project;
|
||||
/** Aktives Geschoss/Zeichnungsebene (Ziel der neuen Elemente). */
|
||||
level: DrawingLevel;
|
||||
/** Default-Kategorie-Code für neue Elemente (siehe §6). */
|
||||
defaultCategoryCode: string;
|
||||
/** Aktiver Wandtyp für das Wand-Werkzeug. */
|
||||
activeWallTypeId: string;
|
||||
/** Aktiver Linienstil-Code für 2D-Primitive (Line Manager). */
|
||||
activeLineStyleId: string;
|
||||
/** Snapping-Einstellungen (an/aus je Typ, ortho, grid). */
|
||||
snap: SnapSettings;
|
||||
/** Pixel pro Meter (für Snap-Toleranz in Metern). */
|
||||
pxPerMeter: number;
|
||||
}
|
||||
|
||||
/** Ein an einer Modellposition ausgelöstes Pointer-Ereignis. */
|
||||
export interface ToolPointer {
|
||||
/** Roher Modellpunkt (vor Snapping), in Metern. */
|
||||
raw: Vec2;
|
||||
/** Gesnappter Punkt + Marker-Info (siehe §5). null = kein Snap. */
|
||||
snap: SnapResult | null;
|
||||
/** Effektiver Punkt = snap?.point ?? raw. */
|
||||
point: Vec2;
|
||||
/** Modifikatoren (Shift = Ortho erzwingen, Ctrl = Snap aus, Alt = …). */
|
||||
shift: boolean;
|
||||
ctrl: boolean;
|
||||
alt: boolean;
|
||||
button: number; // 0 links, 2 rechts
|
||||
}
|
||||
|
||||
/** Was ein Werkzeug-Schritt nach außen meldet. */
|
||||
export interface ToolResult {
|
||||
/** Neuer Vorschau-Zustand (Rubber-Band-Geometrie); null = nichts zu zeigen. */
|
||||
draft: ToolDraft | null;
|
||||
/** Bei Abschluss: Mutation, die App über setProject anwendet. */
|
||||
commit?: (p: Project) => Project;
|
||||
/** true → Werkzeug ist fertig und kehrt in seinen Ruhezustand zurück. */
|
||||
done?: boolean;
|
||||
}
|
||||
|
||||
/** Die Werkzeug-Schnittstelle (reine Funktionen über einen internen State). */
|
||||
export interface Tool {
|
||||
id: ToolId;
|
||||
/** UI-Label-Key (i18n), z. B. "tool.wall". */
|
||||
labelKey: string;
|
||||
/** Material-Symbol-Name für die Werkzeugleiste. */
|
||||
icon: string;
|
||||
/** Statuszeilen-Hinweis-Key je Phase (z. B. "tool.wall.firstPoint"). */
|
||||
hintKey: (state: ToolState) => string;
|
||||
|
||||
/** Initialer Ruhezustand. */
|
||||
init(): ToolState;
|
||||
/** Klick/Tap (pointerdown→up ohne Drag, bzw. „setze Punkt"). */
|
||||
onClick(state: ToolState, p: ToolPointer, ctx: ToolContext): [ToolState, ToolResult];
|
||||
/** Bewegung (Hover/Drag): nur Vorschau, nie Commit. */
|
||||
onMove(state: ToolState, p: ToolPointer, ctx: ToolContext): [ToolState, ToolResult];
|
||||
/** Doppelklick/Enter: mehrteilige Werkzeuge abschließen (z. B. Polylinie). */
|
||||
onCommitGesture(state: ToolState, ctx: ToolContext): [ToolState, ToolResult];
|
||||
/** Esc: aktuellen Entwurf verwerfen, zurück in den Ruhezustand. */
|
||||
onCancel(state: ToolState): [ToolState, ToolResult];
|
||||
/** Backspace: letzten gesetzten Punkt zurücknehmen (mehrteilig). */
|
||||
onUndoPoint?(state: ToolState, ctx: ToolContext): [ToolState, ToolResult];
|
||||
}
|
||||
```
|
||||
|
||||
`ToolState` ist je Werkzeug ein Discriminated Union (Beispiel Wand in §4). Der
|
||||
`ToolController` hält genau eine aktive `Tool`-Instanz + deren `ToolState` in
|
||||
einem `useRef` und ist die einzige Stelle, die diese Methoden aufruft.
|
||||
|
||||
### 3.2 Vorschau-Geometrie (Rubber-Band)
|
||||
|
||||
```ts
|
||||
/** Darstellbare Vorschau — dieselben Primitive wie der Plan, plus Marker. */
|
||||
export interface ToolDraft {
|
||||
/** Vorschau-Primitive (gestrichelt/halbtransparent gezeichnet). */
|
||||
preview: Primitive[];
|
||||
/** Bereits gesetzte „feste" Stützpunkte (kleine Quadrate). */
|
||||
vertices: Vec2[];
|
||||
/** Optionaler Maß-/Winkel-Text am Cursor (z. B. "3.20 m, 90°"). */
|
||||
hud?: { at: Vec2; text: string };
|
||||
}
|
||||
```
|
||||
|
||||
Wichtig: Die Vorschau benutzt **dieselben `Primitive`-Typen** wie `generatePlan`
|
||||
(`polygon | line | arc`). Damit kann der Vorschau-Layer mit derselben
|
||||
`PrimitiveShape`-Renderlogik gezeichnet werden (DRY) — nur mit einer
|
||||
Vorschau-CSS-Klasse (gestrichelt, Akzentfarbe). Für die Wand-Vorschau kann das
|
||||
Werkzeug sogar `generatePlan` auf einem **temporären Projekt** (Original + die in
|
||||
Bau befindliche Wand) aufrufen, um echte gehrte Poché live zu zeigen; in der
|
||||
ersten Phase reicht eine einfache Bandvorschau (`wallCorners`).
|
||||
|
||||
### 3.3 Zustandsmaschine (allgemein)
|
||||
|
||||
Jedes Werkzeug ist eine kleine Maschine über `pointerdown → move → up`. Da
|
||||
`PlanView` Pointer-Capture nutzt, kommen `move`/`up` zuverlässig an. Generisches
|
||||
Muster:
|
||||
|
||||
```
|
||||
ruht ──pointerdown──> (Werkzeug setzt 1. Punkt / startet Drag)
|
||||
▲ │
|
||||
│ ├──move──> Vorschau (rubber-band), kein Commit
|
||||
│ │
|
||||
│ (mehrteilig) pointerdown──> Punkt anhängen, Vorschau weiter
|
||||
│ │
|
||||
└──Esc/Cancel─────────────┤
|
||||
▼
|
||||
Doppelklick/Enter/letzter Punkt ──> commit(project) ──> ruht
|
||||
```
|
||||
|
||||
- **Klick-vs-Drag.** Wie heute in `PlanView` (`MARQUEE_THRESHOLD_PX`): unter der
|
||||
Schwelle ist es ein „Punkt setzen" (Klick), darüber ein Drag. Rechteck/Kreis/
|
||||
Linie unterstützen BEIDE Bedienarten: Zwei-Klick (Punkt, Punkt) ODER Drücken-
|
||||
Ziehen-Loslassen. Polyline/Wall sind reine Klickfolgen mit Abschluss per
|
||||
Doppelklick/Enter.
|
||||
- **Esc** verwirft den Entwurf (`onCancel`) und bleibt im selben Werkzeug.
|
||||
Zweites Esc (im Ruhezustand) schaltet zurück auf `select`.
|
||||
- **Rechtsklick** während eines aktiven Entwurfs = „abschließen/abbrechen"
|
||||
(CAD-üblich), KEIN Kontextmenü; im Ruhezustand öffnet Rechtsklick wie bisher
|
||||
das Plan-Kontextmenü.
|
||||
|
||||
### 3.4 Einbettung in PlanView (Pointer-Routing)
|
||||
|
||||
`PlanView` bekommt zwei neue Props:
|
||||
|
||||
```ts
|
||||
interface PlanViewProps {
|
||||
// … bisherige Props …
|
||||
/** Aktives Werkzeug; "select" = bisheriges Verhalten. */
|
||||
activeTool?: ToolId;
|
||||
/**
|
||||
* Werkzeug-Treiber. PlanView ruft diese Callbacks mit fertig gesnappten
|
||||
* Modellpunkten auf und rendert den zurückgegebenen Draft als Overlay.
|
||||
*/
|
||||
toolHandlers?: {
|
||||
onToolDown(p: ToolPointer): void;
|
||||
onToolMove(p: ToolPointer): void;
|
||||
onToolUp(p: ToolPointer): void;
|
||||
onToolDoubleClick(): void;
|
||||
/** liefert die zu zeichnende Vorschau (von App/Controller gehalten). */
|
||||
draft: ToolDraft | null;
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
Routing in `onPointerDown` (Ergänzung der bestehenden Methode):
|
||||
|
||||
```
|
||||
onPointerDown(e):
|
||||
if e.button === 1: → bestehender Pan (unverändert)
|
||||
if e.button === 0:
|
||||
if activeTool === "select": → bestehende Auswahl-/Marquee-Geste
|
||||
else:
|
||||
setPointerCapture
|
||||
p = makeToolPointer(e) // raw → snap → point (§5)
|
||||
toolHandlers.onToolDown(p)
|
||||
if e.button === 2 (rechts):
|
||||
if activeTool !== "select" && entwurf aktiv: toolHandlers.onToolUp({button:2,…}) // abschließen
|
||||
else: bestehendes Kontextmenü
|
||||
```
|
||||
|
||||
`onPointerMove`/`onPointerUp` analog: bei aktivem Zeichenwerkzeug an
|
||||
`onToolMove`/`onToolUp` routen statt an Pan/Marquee. Der Cursor wird auf
|
||||
`crosshair` gesetzt. `makeToolPointer` führt das Snapping aus (§5) und liefert den
|
||||
fertigen `ToolPointer`.
|
||||
|
||||
Die **Snap-Marker** und der **Draft** werden als zusätzliche SVG-Gruppe NACH den
|
||||
Plan-Primitiven, aber vor der Auswahl-Hervorhebung gerendert (immer obenauf,
|
||||
`pointerEvents="none"`). Marker werden in viewBox-Einheiten über `toScreen`
|
||||
positioniert (existiert bereits).
|
||||
|
||||
## 4. Werkzeug: Wand (Wall)
|
||||
|
||||
Das Wand-Werkzeug zeichnet eine **Achs-Polylinie**; jedes Segment wird zu einem
|
||||
eigenständigen `Wall`-Element des aktiven `WallType` auf dem aktiven Geschoss.
|
||||
Aufeinanderfolgende Segmente teilen sich einen Knoten → die bestehende
|
||||
`computeJoins`-Verschneidung (in `generatePlan`) erzeugt automatisch saubere
|
||||
Gehrungen an den Ecken. Kein zusätzlicher Join-Code nötig.
|
||||
|
||||
### 4.1 Zustand
|
||||
|
||||
```ts
|
||||
type WallToolState =
|
||||
| { phase: "idle" }
|
||||
| {
|
||||
phase: "drawing";
|
||||
/** Bisher gesetzte Achs-Knoten (in Metern). */
|
||||
points: Vec2[];
|
||||
/** Aktuelle Cursor-Position (gesnappt) für die Rubber-Band-Vorschau. */
|
||||
cursor: Vec2 | null;
|
||||
};
|
||||
```
|
||||
|
||||
### 4.2 Pseudocode
|
||||
|
||||
```
|
||||
WallTool.onClick(state, p, ctx):
|
||||
if state.phase === "idle":
|
||||
return [{phase:"drawing", points:[p.point], cursor:p.point}, {draft: draftFor([p.point], p.point, ctx)}]
|
||||
else: // weiteren Knoten anhängen
|
||||
pts = [...state.points, p.point]
|
||||
# Ortho/Snap haben p.point bereits ausgerichtet (§5).
|
||||
return [{phase:"drawing", points: pts, cursor: p.point}, {draft: draftFor(pts, p.point, ctx)}]
|
||||
|
||||
WallTool.onMove(state, p, ctx):
|
||||
if state.phase !== "drawing": return [state, {draft:null}]
|
||||
return [{...state, cursor:p.point}, {draft: draftFor(state.points, p.point, ctx)}]
|
||||
|
||||
WallTool.onCommitGesture(state, ctx): // Doppelklick / Enter / Rechtsklick
|
||||
if state.phase !== "drawing" || state.points.length < 2:
|
||||
return [{phase:"idle"}, {draft:null, done:true}]
|
||||
pts = state.points
|
||||
return [{phase:"idle"}, {
|
||||
draft: null, done: true,
|
||||
commit: (proj) => appendWalls(proj, pts, ctx)
|
||||
}]
|
||||
|
||||
WallTool.onCancel(state):
|
||||
return [{phase:"idle"}, {draft:null, done:true}]
|
||||
|
||||
WallTool.onUndoPoint(state):
|
||||
if state.phase==="drawing" && state.points.length>1:
|
||||
return [{...state, points: state.points.slice(0,-1)}, {draft: …}]
|
||||
return [{phase:"idle"}, {draft:null}]
|
||||
```
|
||||
|
||||
`draftFor` baut die Vorschau: feste Segmente zwischen `points` + ein „lebendes"
|
||||
Segment `points[last] → cursor`. Pro Segment werden die vier Band-Eckpunkte über
|
||||
`wallCorners(a, b, thickness)` (vorhanden) berechnet und als Vorschau-`polygon`
|
||||
gezeichnet; zusätzlich ein HUD mit Länge `|b−a|` und Winkel. `thickness =
|
||||
wallTypeThickness(getWallType(...))`.
|
||||
|
||||
### 4.3 Commit ins Modell
|
||||
|
||||
```
|
||||
appendWalls(project, pts, ctx):
|
||||
newWalls = []
|
||||
for i in 0 .. pts.length-2:
|
||||
a = pts[i]; b = pts[i+1]
|
||||
if |b-a| < EPS: continue // Null-Segmente überspringen
|
||||
newWalls.push({
|
||||
id: uniqueId("W"), // siehe §8 (ID-Vergabe)
|
||||
type: "wall",
|
||||
floorId: ctx.level.id, // aktives Geschoss
|
||||
categoryCode: ctx.defaultCategoryCode, // §6
|
||||
start: a, end: b,
|
||||
wallTypeId: ctx.activeWallTypeId,
|
||||
height: ctx.level.floorHeight ?? 2.6, // Geschosshöhe als Default
|
||||
})
|
||||
return { ...project, walls: [...project.walls, ...newWalls] }
|
||||
```
|
||||
|
||||
Hinweise:
|
||||
- **Höhe** erbt die lichte Geschosshöhe (`DrawingLevel.floorHeight`), Fallback 2.6 m.
|
||||
- **Geschossbindung**: Das Wand-Werkzeug ist nur aktiv, wenn `level.kind === "floor"`
|
||||
(sonst gibt es keine Wände). In `drawing`-Ebenen ist das Wand-Werkzeug
|
||||
deaktiviert (nur 2D-Werkzeuge); siehe §6.
|
||||
- Die Wicklung wird NICHT erzwungen — `leftNormal`-Konvention (CONVENTIONS.md) und
|
||||
`computeJoins` arbeiten richtungsunabhängig pro Segment.
|
||||
|
||||
## 5. Snapping
|
||||
|
||||
Snapping läuft in `makeToolPointer` (PlanView) BEVOR der Punkt an das Werkzeug
|
||||
geht. Es prüft mehrere Snap-Quellen, wählt die nächstgelegene innerhalb der
|
||||
Toleranz und liefert sowohl den gefangenen Punkt als auch eine **Marker-Art** für
|
||||
die Bildschirmdarstellung.
|
||||
|
||||
### 5.1 Typen
|
||||
|
||||
```ts
|
||||
export type SnapKind =
|
||||
| "endpoint" // Wand-Achsenende, Polylinien-Knoten, Primitiv-Endpunkt
|
||||
| "midpoint" // Mitte einer Strecke/Wandachse
|
||||
| "intersection" // Schnittpunkt zweier Achsen/Linien
|
||||
| "center" // Kreis-/Bogenzentrum
|
||||
| "quadrant" // Kreis-Quadrantenpunkte (0/90/180/270°)
|
||||
| "onEdge" // nächster Punkt AUF einer Wandachse/Linie (Lot)
|
||||
| "grid" // Rasterpunkt
|
||||
| "ortho" // orthogonal/winkelrastriert zum vorigen Punkt
|
||||
| "extension"; // Verlängerung einer Achse (gestrichelte Hilfslinie)
|
||||
|
||||
export interface SnapResult {
|
||||
point: Vec2; // gefangener Punkt (Meter)
|
||||
kind: SnapKind;
|
||||
/** Quell-Element (für Marker/Hilfslinien), optional. */
|
||||
refA?: Vec2;
|
||||
refB?: Vec2;
|
||||
/** Bildschirm-Distanz Cursor→Snap (px) — für die Auswahl des Besten. */
|
||||
distPx: number;
|
||||
}
|
||||
|
||||
export interface SnapSettings {
|
||||
enabled: boolean; // Master-Schalter (Ctrl invertiert temporär)
|
||||
endpoint: boolean;
|
||||
midpoint: boolean;
|
||||
intersection: boolean;
|
||||
center: boolean;
|
||||
onEdge: boolean;
|
||||
grid: boolean;
|
||||
gridSize: number; // Rasterweite in Metern, z. B. 0.10
|
||||
ortho: boolean; // Shift erzwingt zusätzlich
|
||||
angleStep: number; // Winkelraster in Grad (z. B. 45)
|
||||
tolerancePx: number; // Fangradius am Bildschirm, z. B. 10
|
||||
}
|
||||
```
|
||||
|
||||
### 5.2 Snap-Kandidaten sammeln
|
||||
|
||||
Quellen pro Geschoss (gefiltert auf sichtbare Kategorien, wie der Plan):
|
||||
|
||||
| Snap | Quelle |
|
||||
|------|--------|
|
||||
| endpoint | `wall.start`, `wall.end` aller sichtbaren Wände; Knoten bereits gesetzter Draft-Punkte; `Drawing2D`-Vertices |
|
||||
| midpoint | Mitte jeder Wandachse und jedes 2D-Segments |
|
||||
| intersection | paarweise `lineIntersect` der Wandachsen (nur Paare, deren Boxen sich am Cursor nähern) |
|
||||
| center/quadrant | Kreise/Bögen aus `Drawing2D` |
|
||||
| onEdge | Lotfußpunkt des Cursors auf jede nahe Wandachse/2D-Linie |
|
||||
| grid | Rundung des Cursors auf `gridSize` |
|
||||
| ortho | Ausrichtung relativ zum letzten Draft-Punkt (§5.4) |
|
||||
|
||||
Performance: Kandidaten werden je `move` neu erzeugt, aber **früh nach
|
||||
Bildschirm-Distanz gefiltert** (nur Punkte innerhalb ~`2·tolerancePx`). Bei
|
||||
großen Modellen kann eine grobe Bounding-Box-Vorauswahl je Wand vorgeschaltet
|
||||
werden; in den ersten Phasen genügt lineares Scannen (Wandzahl ist klein).
|
||||
|
||||
### 5.3 Auswahl-Pseudocode
|
||||
|
||||
```
|
||||
computeSnap(rawModel, ctx, draftPoints, lastPoint):
|
||||
if ctrl(): return null # Snap temporär aus
|
||||
s = ctx.snap
|
||||
tolM = s.tolerancePx / ctx.pxPerMeter # px-Toleranz → Meter
|
||||
cands: SnapResult[] = []
|
||||
|
||||
if s.endpoint: cands += endpoints(...) filtered to within tolM
|
||||
if s.midpoint: cands += midpoints(...)
|
||||
if s.intersection: cands += intersections(...)
|
||||
if s.center: cands += centers/quadrants(...)
|
||||
if s.onEdge: cands += perpendicularFeet(...) # niedrigere Priorität
|
||||
|
||||
# Punkt-Snaps haben Vorrang vor Linien-/Raster-Snaps:
|
||||
pick = argmin(cands, by distPx within tolM, tie-break by priority)
|
||||
if pick: rawModel = pick.point
|
||||
|
||||
# Ortho/Winkelraster wirkt RELATIV zum letzten Punkt und ÜBERLAGERT:
|
||||
if (s.ortho || shift()) && lastPoint:
|
||||
rawModel = applyAngleConstraint(lastPoint, rawModel, s.angleStep)
|
||||
# Wenn dabei auch ein Punkt-Snap nahe der Ortho-Linie liegt → bevorzugen.
|
||||
|
||||
if !pick && s.grid:
|
||||
g = snapToGrid(rawModel, s.gridSize)
|
||||
if dist(g, rawModel) within tolM: return {point:g, kind:"grid", …}
|
||||
|
||||
return pick ?? null
|
||||
```
|
||||
|
||||
Prioritätsreihenfolge bei gleichem Abstand: `endpoint > intersection > midpoint >
|
||||
center/quadrant > onEdge > grid`. Ortho/Winkelraster ist eine **Projektion**, kein
|
||||
Punkt-Kandidat: es verschiebt den (ggf. schon gesnappten) Punkt auf die nächste
|
||||
erlaubte Richtung vom letzten Knoten.
|
||||
|
||||
### 5.4 Ortho / Winkelraster
|
||||
|
||||
```
|
||||
applyAngleConstraint(from, to, stepDeg):
|
||||
d = to - from
|
||||
ang = atan2(d.y, d.x)
|
||||
k = round(ang / rad(stepDeg)) * rad(stepDeg)
|
||||
len = |d|
|
||||
return from + (cos(k), sin(k)) * len
|
||||
```
|
||||
|
||||
Mit `stepDeg = 90` ist das klassisches Ortho (H/V); `45` erlaubt Diagonalen.
|
||||
`Shift` erzwingt Ortho temporär unabhängig von der Einstellung.
|
||||
|
||||
### 5.5 Bildschirm-Marker
|
||||
|
||||
Pro aktivem Snap zeichnet `PlanView` ein Marker-Glyph an `toScreen(snap.point)`
|
||||
(`pointerEvents="none"`, eigene CSS-Klassen, papierkonstante Größe via
|
||||
non-scaling):
|
||||
|
||||
- `endpoint` → kleines Quadrat ▫
|
||||
- `midpoint` → Dreieck �△
|
||||
- `intersection` → ✕
|
||||
- `center` → ○, `quadrant` → ◇
|
||||
- `onEdge` → ⟂-Glyph
|
||||
- `grid` → feiner Punkt
|
||||
- `ortho`/`extension` → zusätzlich eine **gestrichelte Hilfslinie** von `refA`
|
||||
(Bezugspunkt) zum Cursor
|
||||
|
||||
Marker erscheinen NUR während ein Zeichenwerkzeug aktiv ist. i18n-Tooltips/Status
|
||||
(„Endpunkt", „Mittelpunkt", …) über `t('snap.endpoint')` etc.
|
||||
|
||||
## 6. Ebene, Kategorie und Stil neuer Elemente
|
||||
|
||||
Neue Elemente brauchen eine **Zeichnungsebene** (DrawingLevel) und eine
|
||||
**Kategorie** (LayerCategory `code`) sowie — bei 2D-Primitiven — einen Stift/
|
||||
Schraffur-Stil.
|
||||
|
||||
### 6.1 Zeichnungsebene (Ziel)
|
||||
|
||||
- Ziel ist **immer das aktive Geschoss/die aktive Zeichnungsebene** (`activeLevelId`
|
||||
in `App.tsx`). Wände nur auf `kind === "floor"`. 2D-Primitive (`Drawing2D`) auf
|
||||
jeder Ebene, also auch auf `kind === "drawing"` (freie 2D-Zeichnung).
|
||||
|
||||
### 6.2 Kategorie (categoryCode)
|
||||
|
||||
- Es gibt eine **aktive Kategorie** als View-State (`activeCategoryCode` in App,
|
||||
neu). Default beim Start: der Code der gewählten Wand-Kategorie (im Sample „20"
|
||||
Wände), bzw. die erste sichtbare Kategorie. Die Statusleiste zeigt heute schon
|
||||
die „aktive Ebene" (`activeLayerName`); diese wird künftig von `activeCategoryCode`
|
||||
gespeist statt nur aus der Auswahl abgeleitet.
|
||||
- Neue Wände: `categoryCode = activeCategoryCode` (z. B. „20").
|
||||
- Neue 2D-Primitive: ebenfalls `activeCategoryCode`. Sinnvoll ist eine eigene
|
||||
2D-/Hilfslinien-Kategorie (z. B. „90 Zeichnung"); diese wird über die
|
||||
Kategorie-Auswahl in der Statusleiste/Werkzeugleiste gesetzt.
|
||||
- Die Kategorie liefert Farbe + Strichstärke (`LayerCategory.color`, `.lw`), genau
|
||||
wie `generatePlan` es heute für Wände via `categoryLwMap` nutzt.
|
||||
|
||||
### 6.3 Stift/Schraffur
|
||||
|
||||
- **Wände** erhalten KEINEN eigenen Stift — ihr Erscheinungsbild kommt aus dem
|
||||
`WallType` (Component → Hatch → LineStyle) und der Kategorie-`lw` (bestehender
|
||||
Pfad in `generatePlan`).
|
||||
- **2D-Primitive** referenzieren optional einen `LineStyle` aus dem Line Manager
|
||||
(`activeLineStyleId`). Ohne expliziten Stil erben sie Farbe/Strichstärke aus der
|
||||
Kategorie (`color`, `lw`). Flächige 2D-Primitive (geschlossenes Rechteck/Kreis/
|
||||
Polyline) können optional eine Schraffur (`hatchId`) tragen.
|
||||
|
||||
## 7. Speicherung der 2D-Primitive: `Drawing2D`
|
||||
|
||||
2D-Geometrie wird als neues Modell-Element `Drawing2D` gespeichert — analog zu
|
||||
`Wall`/`Door` ein semantisches Element, das beim Rendern abgeleitet wird (KEINE
|
||||
vorab erzeugten Primitive im Modell). Damit bleibt die Architektur „Modell →
|
||||
abgeleitete Ansicht" intakt.
|
||||
|
||||
### 7.1 Typ
|
||||
|
||||
```ts
|
||||
/** Geometrie-Form eines 2D-Zeichenelements. */
|
||||
export type Drawing2DGeom =
|
||||
| { shape: "line"; a: Vec2; b: Vec2 }
|
||||
| { shape: "polyline"; pts: Vec2[]; closed: boolean }
|
||||
| { shape: "rect"; min: Vec2; max: Vec2 } // achsparallel
|
||||
| { shape: "circle"; center: Vec2; r: number }
|
||||
| {
|
||||
shape: "arc";
|
||||
center: Vec2;
|
||||
r: number;
|
||||
/** Start-/Endwinkel in Radiant (math. Konvention, CCW positiv). */
|
||||
a0: number;
|
||||
a1: number;
|
||||
}
|
||||
| { shape: "text"; at: Vec2; text: string; height: number; angle: number };
|
||||
|
||||
/** Ein freies 2D-Zeichenelement auf einer Zeichnungsebene. */
|
||||
export interface Drawing2D {
|
||||
id: string;
|
||||
type: "drawing2d";
|
||||
/** Zeichnungsebene (Geschoss ODER freie 2D-Ebene). */
|
||||
levelId: string;
|
||||
/** Grafik-Kategorie (Ebene) — liefert Farbe/Strichstärke als Default. */
|
||||
categoryCode: string;
|
||||
geom: Drawing2DGeom;
|
||||
/** Optionaler Linienstil (Line Manager); sonst Kategorie-Default. */
|
||||
lineStyleId?: string;
|
||||
/** Optionale Schraffur für geschlossene Formen (Hatch Manager). */
|
||||
hatchId?: string;
|
||||
/** Optionale explizite Strichfarbe; sonst Kategorie-Farbe. */
|
||||
color?: string;
|
||||
}
|
||||
```
|
||||
|
||||
Ergänzung am `Project`:
|
||||
|
||||
```ts
|
||||
export interface Project {
|
||||
// … bisher …
|
||||
drawings2d: Drawing2D[]; // NEU
|
||||
}
|
||||
export type Element = Wall | Door | Drawing2D; // erweitert
|
||||
```
|
||||
|
||||
`sampleProject` bekommt ein leeres `drawings2d: []`. Lösch-/Referenz-Regeln:
|
||||
beim Löschen einer Zeichnungsebene werden auch deren `Drawing2D` entfernt (analog
|
||||
zur bestehenden Wand-/Tür-Bereinigung in `deleteLevel`).
|
||||
|
||||
### 7.2 Ableitung in `generatePlan`
|
||||
|
||||
`generatePlan` rendert künftig zusätzlich die `Drawing2D` des Geschosses (gefiltert
|
||||
wie Wände auf sichtbare Kategorien + `categoryDisplay`). Neue Funktion
|
||||
`addDrawing2D(out, project, d, greyed, lwMm)`:
|
||||
|
||||
```
|
||||
addDrawing2D(out, project, d):
|
||||
color = d.color ?? categoryColor(d.categoryCode)
|
||||
weight = lineStyle(d.lineStyleId)?.weight ?? categoryLw(d.categoryCode)
|
||||
dash = lineStyle(d.lineStyleId)?.dash ?? null
|
||||
switch d.geom.shape:
|
||||
"line": out.push({kind:"line", a, b, cls:"draw2d", weightMm:weight, dash})
|
||||
"polyline": for each segment → line-Primitive (closed → Schluss-Segment)
|
||||
"rect": vier Kanten als line-Primitive (oder polygon, falls hatchId)
|
||||
"circle": → als zwei 180°-Bögen (arc-Primitive) ODER neues Primitiv (s. u.)
|
||||
"arc": → arc-Primitive (center/from/to/r aus a0,a1)
|
||||
"text": → neues text-Primitiv (s. u.)
|
||||
```
|
||||
|
||||
Dabei wird, wo möglich, der **vorhandene** `Primitive`-Vorrat (`line`, `arc`,
|
||||
`polygon`) wiederverwendet — die Strichstärke kommt in mm Papier (wie der Rest des
|
||||
Plans), Farbe über eine CSS-Klasse oder ein neues optionales `color`-Feld am
|
||||
`line`-Primitive.
|
||||
|
||||
Zwei `Primitive`-Erweiterungen sind nötig:
|
||||
|
||||
```ts
|
||||
// kreisförmige Vollkurve (Kreis) — sonst muss man sie in zwei Bögen zerlegen:
|
||||
| { kind: "circle"; center: Vec2; r: number; cls: string; weightMm: number;
|
||||
dash?: number[] | null; fill?: string; greyed?: boolean }
|
||||
// Textmarke:
|
||||
| { kind: "text"; at: Vec2; text: string; heightMm: number; angle: number;
|
||||
cls: string; color?: string; greyed?: boolean }
|
||||
```
|
||||
|
||||
`PlanView.renderPrimitive` bekommt entsprechende `case`-Zweige (`<circle>`,
|
||||
`<text>`). Text wird in **Papier-Millimetern** dimensioniert (Höhe → `mmToPx`,
|
||||
non-scaling), damit die Schrifthöhe beim Zoomen papierkonstant bleibt (analog zu
|
||||
Strichstärken in `plans-output.md`).
|
||||
|
||||
Das `arc`-Primitiv zeichnet heute nur Kurzbögen (≤180°, `large-arc=0`). Für
|
||||
beliebige 2D-Bögen wird es um ein `largeArc`-Flag erweitert (aus `|a1−a0|`
|
||||
berechnet); abwärtskompatibel (Default 0).
|
||||
|
||||
## 8. ID-Vergabe & Immutabilität
|
||||
|
||||
- Neue IDs über einen kleinen Helfer `uniqueId(prefix)` (z. B.
|
||||
`\`${prefix}-${Date.now()}-${counter++}\``), konsistent mit der bestehenden
|
||||
Praxis in `App.tsx` (`floor-${Date.now()}` usw.). Wand-Präfix „W", 2D-Präfix
|
||||
„dr2d".
|
||||
- Alle Mutationen laufen über `setProject` immutabel (CONVENTIONS.md / App-Konvention).
|
||||
Der `commit(project)` eines Werkzeugs ist eine reine Funktion `Project →
|
||||
Project`; App ruft `setProject(prev => result.commit(prev))`.
|
||||
|
||||
## 9. App- und PlanView-Verdrahtung (konkret)
|
||||
|
||||
Neuer View-State in `App.tsx`:
|
||||
|
||||
```ts
|
||||
const [activeTool, setActiveTool] = useState<ToolId>("select");
|
||||
const [activeCategoryCode, setActiveCategoryCode] = useState<string>(/* erste Wand-Kat */);
|
||||
const [activeWallTypeId, setActiveWallTypeId] = useState<string>(project.wallTypes[0].id);
|
||||
const [activeLineStyleId, setActiveLineStyleId] = useState<string>(project.lineStyles[0].id);
|
||||
const [snap, setSnap] = useState<SnapSettings>(DEFAULT_SNAP);
|
||||
const toolStateRef = useRef<ToolState>(getTool(activeTool).init());
|
||||
const [draft, setDraft] = useState<ToolDraft | null>(null);
|
||||
```
|
||||
|
||||
Der `ToolController` ist eine kleine Hook/Klasse, die `toolStateRef` hält und die
|
||||
`PlanView.toolHandlers` implementiert:
|
||||
|
||||
```
|
||||
onToolDown(p): [st, res] = tool.onClick(toolStateRef.current, p, ctx)
|
||||
toolStateRef.current = st; setDraft(res.draft)
|
||||
if res.commit: setProject(res.commit)
|
||||
if res.done: toolStateRef.current = tool.init()
|
||||
onToolMove(p): [st, res] = tool.onMove(...); toolStateRef.current=st; setDraft(res.draft)
|
||||
onToolDoubleClick(): [st,res]=tool.onCommitGesture(...); apply commit/done; setDraft(null)
|
||||
```
|
||||
|
||||
Keyboard (global, nur wenn ein Zeichenwerkzeug aktiv ist):
|
||||
`Esc → onCancel`, `Enter → onCommitGesture`, `Backspace → onUndoPoint`. Beim
|
||||
Wechsel von `activeLevelId`/`viewType` wird der laufende Entwurf verworfen (analog
|
||||
zur bestehenden Auswahl-Bereinigung in den `useEffect`s).
|
||||
|
||||
`ctx` (ToolContext) wird in App via `useMemo` aus Project + aktiven Selektionen
|
||||
gebaut und an PlanView/Controller gereicht.
|
||||
|
||||
### 9.1 Werkzeugleiste (TopBar)
|
||||
|
||||
Eine neue Werkzeug-Gruppe in der `TopBar` (links, vor den Ansichts-Toggles), als
|
||||
i18n-beschriftete Icon-Buttons (`t('tool.select')`, `t('tool.wall')`, …). Aktiv-
|
||||
Zustand hervorgehoben. Daneben: Auswahl des aktiven `WallType` (für Wand) und der
|
||||
aktiven Kategorie/des Linienstils (Dropdowns), sowie Snap-Toggles (kleines
|
||||
Snap-Menü mit Checkboxen je `SnapKind`, Grid-Größe, Winkelraster). Wand-/2D-
|
||||
Werkzeuge werden je nach `level.kind` aktiviert/deaktiviert (Tooltip nennt den
|
||||
Grund — wie die bestehenden disabled-Menüpunkte in `App.tsx`).
|
||||
|
||||
### 9.2 i18n-Keys (neu, Auszug)
|
||||
|
||||
```
|
||||
tool.select / tool.wall / tool.line / tool.polyline / tool.rect /
|
||||
tool.circle / tool.arc / tool.text
|
||||
tool.wall.firstPoint / tool.wall.nextPoint / tool.wall.finish
|
||||
snap.endpoint / snap.midpoint / snap.intersection / snap.center /
|
||||
snap.quadrant / snap.onEdge / snap.grid / snap.ortho
|
||||
snap.settings / snap.gridSize / snap.angleStep
|
||||
status.activeWallType / status.activeCategory / status.activeTool
|
||||
```
|
||||
|
||||
Alle sichtbaren Strings über `t(...)` (CONVENTIONS.md). Identifier bleiben englisch.
|
||||
|
||||
## 10. Übrige Werkzeuge (Kurzspezifikation)
|
||||
|
||||
| Werkzeug | Eingabe | Zustand | Commit |
|
||||
|----------|---------|---------|--------|
|
||||
| **Line** | 2 Punkte (Klick-Klick oder Drag) | `{a?}` | `Drawing2D{shape:"line"}` |
|
||||
| **Polyline** | n Punkte, Abschluss Doppelklick/Enter; `closed` per „C" oder Klick auf Start | `{pts}` | `Drawing2D{shape:"polyline"}` |
|
||||
| **Rectangle** | 2 Ecken (Drag oder Klick-Klick) | `{p0?}` | `Drawing2D{shape:"rect"}` (min/max sortiert) |
|
||||
| **Circle** | Zentrum + Radius-Punkt | `{center?}` | `Drawing2D{shape:"circle"}` |
|
||||
| **Arc** | 3 Punkte (Start, durch, Ende) ODER Zentrum-Start-Ende (Modus-Toggle) | `{p0?,p1?}` | `Drawing2D{shape:"arc"}` (a0/a1 aus Punkten) |
|
||||
| **Text** | 1 Punkt → Inline-Eingabefeld (wie `InlineEditor` in App) | `{at?}` | `Drawing2D{shape:"text"}` |
|
||||
|
||||
Alle nutzen dasselbe `Tool`-Interface, dasselbe Snapping und denselben Draft-/
|
||||
Commit-Pfad. Text öffnet beim Setzen des Ankerpunkts ein kleines Overlay-Eingabe-
|
||||
feld (an `toClient(at)` positioniert) und committet bei Enter/Blur.
|
||||
|
||||
3-Punkt-Bogen → Zentrum: Umkreismittelpunkt der drei Punkte (Schnitt der
|
||||
Mittelsenkrechten via `lineIntersect`), `r`, `a0/a1` aus Start-/Endwinkel; Drehsinn
|
||||
aus dem mittleren Punkt.
|
||||
|
||||
## 11. Phasenplan
|
||||
|
||||
**Phase 1 — Gerüst + Select + Wall + Line (MVP).**
|
||||
1. `ToolId`, `Tool`, `ToolContext`, `ToolPointer`, `ToolDraft`, `ToolResult`,
|
||||
`SnapResult`, `SnapSettings`, `Drawing2D`(+`Project.drawings2d`) als Typen.
|
||||
2. `PlanView`: `toScreen`/`viewToModel`/`pxPerMeter` als Callbacks nach außen;
|
||||
Pointer-Routing für `activeTool !== "select"`; Draft-/Marker-Overlay-Rendering;
|
||||
Crosshair-Cursor.
|
||||
3. `ToolController` + App-State (`activeTool`, `activeCategoryCode`,
|
||||
`activeWallTypeId`, `snap`) + Keyboard (Esc/Enter/Backspace).
|
||||
4. **WallTool** voll funktionsfähig (Polylinie → Wände, Live-Band-Vorschau, HUD,
|
||||
Commit via `appendWalls`). Verschneidung kommt automatisch aus `computeJoins`.
|
||||
5. **LineTool** als erstes 2D-Werkzeug; `generatePlan.addDrawing2D` für `line`;
|
||||
`Drawing2D`-Löschung beim Geschoss-Löschen.
|
||||
6. **Snapping Stufe 1**: endpoint + grid + ortho (Shift), mit Bildschirm-Markern.
|
||||
7. TopBar-Werkzeuggruppe (select/wall/line) + WallType-/Kategorie-Auswahl;
|
||||
i18n-Keys; Statusleiste zeigt aktives Werkzeug + Kategorie.
|
||||
8. Verifizieren: `npx tsc -b`, `npm run build`, Screenshot via `scripts/probe.mjs`
|
||||
(Wand zeichnen, Gehrung prüfen).
|
||||
|
||||
**Phase 2 — Snapping vervollständigen + 2D-Grundformen.**
|
||||
- Snap: midpoint, intersection, onEdge (Lot), extension-Hilfslinien, Winkelraster
|
||||
(45°), Snap-Einstellungsmenü in der TopBar.
|
||||
- Werkzeuge: Polyline, Rectangle (inkl. optionaler Schraffur für geschlossene
|
||||
Formen). `Primitive`-Erweiterung nur für tatsächlich gebrauchte Formen.
|
||||
|
||||
**Phase 3 — Kurven + Text.**
|
||||
- `Primitive` um `circle` (+ `arc` `largeArc`) und `text` erweitern; PlanView-
|
||||
Renderzweige; Text papierkonstant.
|
||||
- Werkzeuge: Circle, Arc (3-Punkt), Text (Inline-Eingabe). Snap: center/quadrant.
|
||||
|
||||
**Phase 4 — Bearbeitung (Folge-Doku).**
|
||||
- Grips/Editieren bestehender Elemente (Wand-Enden ziehen, 2D-Vertices verschieben),
|
||||
Verschieben/Kopieren/Rotieren der Auswahl, numerische Direkteingabe von
|
||||
Länge/Winkel im HUD. Baut auf demselben Snapping + Draft-Pfad auf. (Eigenes
|
||||
Design-Dokument; hier nur als Ausblick.)
|
||||
|
||||
## 12. Architektur-Garantien (Checkliste)
|
||||
|
||||
- Modell bleibt einzige Wahrheit; Werkzeuge schreiben nur `Project`, nie Plan-
|
||||
Primitive. Ansichten (Plan/3D) leiten ab.
|
||||
- Alle Bezeichner englisch; alle UI-Texte über `t(...)`; Einheiten in Metern,
|
||||
Anzeige via `formatM`; Strichstärken/Texthöhen in mm Papier (non-scaling).
|
||||
- Native-App-Verhalten: kein Browser-Kontextmenü während des Zeichnens; keine
|
||||
Textauswahl (außer Text-Eingabefeld); Pan/Zoom immer verfügbar.
|
||||
- DRY: Vorschau nutzt dieselben `Primitive` + Renderlogik wie der Plan; Snapping
|
||||
und Commit-Pfad sind werkzeugübergreifend geteilt.
|
||||
</content>
|
||||
</invoke>
|
||||
@@ -0,0 +1,424 @@
|
||||
# Design — Bauteile (Elements)
|
||||
|
||||
> Teil der Standalone-Architektur — siehe [../../ARCHITECTURE.md](../../ARCHITECTURE.md).
|
||||
> Output/Pläne: [plans-output.md](plans-output.md). Ressourcen/Stile:
|
||||
> [resources-graphics.md](resources-graphics.md).
|
||||
|
||||
Dieses Dokument legt die **Daten**, die **Generierung** (3D-Geometrie + Plan-
|
||||
Symbolik) und das **Grip-Editing** je Bauteil fest und übersetzt DOSSIERs
|
||||
`elemente.py` (7244 LOC, Monolith) in **kleine Bauteil-Module** (`src/model/
|
||||
elements/wall.ts`, `opening.ts`, …). Bezeichner englisch, Prosa deutsch, Meter.
|
||||
|
||||
DOSSIERs Architektur dort: pro Element eine **Achse/Outline-Source** (editierbar)
|
||||
+ ein **auto-generiertes Volumen** (`wand_axis`+`wand_volume`, Outline+Brep).
|
||||
Browser-Äquivalent: das **semantische Element ist die Source**; Geometrie wird per
|
||||
`generate*()` **abgeleitet** (nie persistiert). Das ist sauberer als DOSSIERs
|
||||
zwei-Objekt-Modell und kennt kein Cache-Stale.
|
||||
|
||||
---
|
||||
|
||||
## 0. Gemeinsames Fundament
|
||||
|
||||
```ts
|
||||
// src/model/elements/base.ts
|
||||
interface ElementBase {
|
||||
id: string;
|
||||
type: ElementType; // "wall" | "window" | "door" | "slab" | "stair" | "roof"
|
||||
// | "column" | "beam" | "space" | "draw2d"
|
||||
floorId: string; // Zeichnungsebene (Geschoss); bei gehosteten via Host
|
||||
categoryCode: string; // Ebene (Grafik-Kategorie), z.B. "20"
|
||||
styleId?: string; // optionaler Element-Override-Stil (resources-graphics.md)
|
||||
name?: string;
|
||||
}
|
||||
```
|
||||
|
||||
**Geometrie-Konvention** (aus CONVENTIONS.md, im Spike etabliert): Wand-Normale
|
||||
`n = leftNormal(u) = (-u.y, u.x)`; bei CCW-Wicklung zeigt `+n` nach innen.
|
||||
Schichten werden außen (`-T/2`) → innen (`+T/2`) gestapelt (`generatePlan.addWallPoche`,
|
||||
`Viewport3D.addWallMeshes`).
|
||||
|
||||
**Detailgrad** (LoD) — DOSSIERs `darstellung` (`auto|einfach|standard|detail`):
|
||||
```ts
|
||||
type DetailLevel = "coarse" | "medium" | "fine"; // einfach | standard | detail
|
||||
// Auflösung: Element-Wert "auto" → Dokument-/Snapshot-Wert; sonst Element-Wert.
|
||||
function resolveDetail(el: ElementBase, doc: { detailLevel: DetailLevel }): DetailLevel
|
||||
```
|
||||
≙ DOSSIER `_resolve_oeff_darstellung` + `get_aktive_darstellung`. Steuert, *wie
|
||||
viel* Symbolik gezeichnet wird (1:500 Rechteck → 1:50 Glas/Sims/Schwenkbogen).
|
||||
|
||||
**Generierungs-Signaturen** (jedes Modul exportiert beides):
|
||||
```ts
|
||||
function build3d(project, el, ctx): THREE.Object3D // Volumen (Schichten/Brep)
|
||||
function generatePlan(project, el, ctx, lod): Primitive[] // Schnittflächen + Symbol
|
||||
// ctx trägt baseElevation, joins, sichtbare Codes, resolver für Components/Styles
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 1. Wand (Wall) — mehrschichtig
|
||||
|
||||
### 1.1 Daten
|
||||
```ts
|
||||
interface Wall extends ElementBase {
|
||||
type: "wall";
|
||||
start: Vec2; end: Vec2; // Achse (Centerline) im Grundriss [im Spike]
|
||||
wallTypeId: string; // → WallType.layers (außen→innen)
|
||||
height: number;
|
||||
reference: "mid" | "left" | "right"; // Referenzlage der Achse (DOSSIER _wand_referenz)
|
||||
baseOffset?: number; // UK relativ zu OKFF (default 0)
|
||||
topOffset?: number; // OK-Override (default = floorHeight)
|
||||
jointRole?: "auto" | "through" | "butt"; // T-Stoss-Rolle (DOSSIER wand_joint_rolle)
|
||||
// Mehrsegment-Wände (Polyline): optional axisPoints statt start/end
|
||||
axisPoints?: Vec2[];
|
||||
}
|
||||
```
|
||||
`reference` verschiebt die Achse auf Außenkante/Mitte (DOSSIER
|
||||
`_wall_offsets_from_referenz`): hilft beim Modellieren *und* beim Import fremder
|
||||
Pläne (ROADMAP §11). Offsets: `mid → [+T/2, -T/2]`, `left → [0, -T]`, `right → [+T, 0]`.
|
||||
|
||||
### 1.2 Generierung — 3D + Plan (Status: im Spike, einschichtig→mehrschichtig ✅)
|
||||
Beide Sichten extrudieren/füllen **dasselbe gehrte Band-Polygon** pro Schicht.
|
||||
Heute schon vorhanden:
|
||||
- `geometry.clippedBand(start, end, offA, offB, startCut, endCut)` — Band mit
|
||||
Gehrungsschnitt.
|
||||
- `generatePlan.addWallPoche` — pro Schicht ein gefülltes Polygon (Component-Fill +
|
||||
Schraffur), Öffnungen ausgespart.
|
||||
- `Viewport3D.addLayerPrism` — dasselbe Polygon via `ExtrudeGeometry`.
|
||||
|
||||
### 1.3 Wand-Verschneidung (Joins) — Risiko #1
|
||||
|
||||
**Status: L-Ecken-Gehrung ✅** (`joins.computeJoins` → `miterLine`, robust gegen
|
||||
Wicklung + ungleiche Dicken). **Offen: Prioritäts-T-/X-Stöße** bei mehrschichtigen
|
||||
Wänden.
|
||||
|
||||
DOSSIERs gelöste Logik (`elemente._t_junction_layer_overrides`, `_wand_should_apply_t_miter`),
|
||||
die wir portieren:
|
||||
|
||||
1. **Knoten finden:** Endpunkte auf Gitter runden (`roundKey`, existiert),
|
||||
gruppieren. `==1` freies Ende, `==2` L-Ecke (Gehrung, ✅), `>2` T/X.
|
||||
2. **Through-Wand bestimmen:** an einem T-Stoß läuft genau **eine** Wand durch.
|
||||
Auswahl nach `jointRole` (DOSSIER-Regel), sonst nach Component-`joinPriority`:
|
||||
```
|
||||
my.role="through" → ich laufe durch (kein Miter)
|
||||
my.role="butt" → ich stoße an (Miter)
|
||||
beide "auto" → höhere joinPriority = Through-Wand
|
||||
```
|
||||
3. **Schicht-Durchdringung (Backbone):** **nur das Material mit der höchsten
|
||||
gemeinsamen `joinPriority`** in *beiden* Wänden läuft durch und unioniert
|
||||
(T-Form). Beispiel ROADMAP §2d: Beton (800) läuft mittig durch; Putze (100)
|
||||
verbinden sich seitlich, gehen aber nirgends durch den Beton. Alle Nicht-
|
||||
Backbone-Schichten der anstoßenden Wand mitern an der Through-Außenkante
|
||||
(`standard_miter`). Ergebnis: gleichfarbige Außenlagen bilden automatisch
|
||||
saubere L-Stöße.
|
||||
|
||||
```ts
|
||||
// joins.ts — Erweiterung der bestehenden API
|
||||
interface WallCuts { startCut: Line|null; endCut: Line|null;
|
||||
// neu: pro-Schicht Overrides am T-Stoss
|
||||
layerExtensions?: number[]; // wie weit jede Schicht in Through-Body drillt
|
||||
layerMiters?: (Line|null)[]; // pro-Schicht Mitre (null = Backbone, läuft durch)
|
||||
}
|
||||
function computeJoins(project, walls): Map<string, WallCuts> // erweitert
|
||||
```
|
||||
|
||||
**Implementierungsplan (stufenweise, Risiko #1):**
|
||||
- (a) ✅ L-Gehrung bleibt.
|
||||
- (b) T-Stoß ohne Schichten: Backbone = ganze Wand; Through union, Stem mitert.
|
||||
- (c) T-Stoß mit Schichten: Backbone-Material-Logik wie oben (Port von
|
||||
`_t_junction_layer_overrides`).
|
||||
- (d) X-Stoß: paarweise als zwei T behandeln.
|
||||
- **Booleans:** Union/Extension der Backbone-Säule via **OpenCascade.js/Manifold**
|
||||
im Worker (`workers/geometry.worker.ts`), nur für 3D + exakten B-Rep-Export; der
|
||||
2D-Plan bleibt rein analytisch (Polygon-Clipping, kein Kernel) — schnell.
|
||||
- **Validierung:** Screenshot-Probe der T-Ecke (Beton durch, Putz seitlich).
|
||||
|
||||
### 1.4 Grip-Editing (Risiko #L, Phase 3–4)
|
||||
DOSSIER: Display-Conduit zeichnet dicke Marker an Achs-Endpunkten, MouseCallback
|
||||
fängt Klick → `GetPoint` mit Snap → `_replace_axis_vertex` → Volumen regeneriert
|
||||
(`wand_grips.py`). Browser-Port:
|
||||
- **Marker:** SVG-Kreise (r ≈ 7 px) an Endpunkten/Knicks der *selektierten* Wand,
|
||||
als Overlay über dem Plan (unabhängig von Ebenen-Sichtbarkeit) — exakt DOSSIERs
|
||||
Conduit-Idee.
|
||||
- **Hit-Test:** Pointer-Distanz < 14 px (DOSSIER `_HIT_RADIUS_PX`).
|
||||
- **Drag:** `pointerdown` auf Marker → Live-Preview-Linien zu Nachbar-Vertices →
|
||||
Snap (Endpunkt/Ortho/Raster) → `pointerup` → `store.apply(p => wall.start = newPt)`.
|
||||
Abgeleitete Sichten (Plan + 3D) re-derivieren reaktiv — kein manuelles Regen.
|
||||
- Funktioniert für Line (2 Grips) und Polyline (jeder Knick ein Grip), wie DOSSIER.
|
||||
|
||||
---
|
||||
|
||||
## 2. Öffnungen (Window / Door) — gehostet, LoD
|
||||
|
||||
### 2.1 Daten
|
||||
```ts
|
||||
interface OpeningBase extends ElementBase {
|
||||
hostWallId: string; // Host-Wand (Geschoss ergibt sich daraus) [im Spike]
|
||||
position: number; // Abstand entlang Wandachse vom Wand-Start (m)
|
||||
width: number; height: number;
|
||||
reference: "mid" | "left" | "right"; // Lage des Klickpunkts in der Öffnung
|
||||
detailLevel: DetailLevel | "auto";
|
||||
frame?: { width: number; depth: number; pos: "outer"|"mid"|"inner"; offset: number };
|
||||
outerSide: "left" | "right"; // welche Wandseite ist außen
|
||||
}
|
||||
interface Window extends OpeningBase {
|
||||
type: "window";
|
||||
sill: number; // Brüstungshöhe
|
||||
sashes: 1|2|3|4; // Flügelzahl
|
||||
sillProfileOut?: "none"|"narrow"|"standard"|"wide"; // Sims außen (DOSSIER _OEFF_SIMS_STYLES)
|
||||
sillProfileIn?: "none"|"narrow"|"standard"|"wide";
|
||||
glass: boolean;
|
||||
}
|
||||
interface Door extends OpeningBase {
|
||||
type: "door";
|
||||
swing: "left" | "right"; // Anschlagseite [im Spike]
|
||||
hinge: "start" | "end"; // Scharnierpfosten [im Spike]
|
||||
openAngle: number; // Plan-Öffnungswinkel 0–180 (default 90)
|
||||
doorType: "normal" | "wall-opening"; // Wandöffnung = ohne Blatt
|
||||
frameType: "casing" | "block"; // Zarge | Blockrahmen
|
||||
lintel?: "none"|"inner"|"outer"|"both";// Sturzlinien-Anzeige (DOSSIER _OEFF_STURZ)
|
||||
}
|
||||
```
|
||||
Felder 1:1 aus DOSSIERs `_OEFF_*`-Keys + `_OEFF_STYLE_FIELDS`. Presets (Fenster
|
||||
Standard/Gross/Bandlage, Tür Innen/Eingang/Verglast, Wandöffnung) als
|
||||
Style-Katalog (resources-graphics.md), seed wie `_OEFF_DEFAULT_STYLES`.
|
||||
|
||||
### 2.2 Host-Beziehung (Risiko #2)
|
||||
Die Öffnung kennt ihre Wand (`hostWallId`); ihre Geometrie wird **relativ zur
|
||||
Wandachse** berechnet (`opening.axisFrame(wall, position)` → Punkt + Tangente +
|
||||
Normale, ≙ DOSSIER `_oeff_axis_frame`). Verschiebt sich die Wand, folgt die
|
||||
Öffnung automatisch (sie hält keinen absoluten Punkt). Beim Plan/3D wird die
|
||||
Wand an `[position, position+width]` ausgespart — steht im Spike (`addWallPoche`
|
||||
Segmentierung, `addWallMeshes` Sturz).
|
||||
|
||||
### 2.3 Generierung nach LoD
|
||||
| LoD | Plan-Symbol | 3D |
|
||||
|---|---|---|
|
||||
| **coarse** (1:200/500) | Öffnung als Lücke + dünne Linie | Aussparung, kein Rahmen |
|
||||
| **medium** (1:100) | + Rahmenlinien, Tür-Schwenkbogen (`addDoorSymbol` ✅), Sturz gestrichelt | Aussparung + einfacher Rahmen-Quader |
|
||||
| **fine** (1:50) | + Glas-Doppellinie, Sims, Flügel-Teilung, Anschlag | Rahmen + Blatt + Glas (transparent) + Sims (DOSSIER `_OEFF_PIECE_DEFS`) |
|
||||
|
||||
- **Tür-Schwenkbogen:** im Spike (`generatePlan.addDoorSymbol` — Blatt + Arc).
|
||||
Ausbau: `openAngle`, lichte vs. volle Breite je LoD (Port von
|
||||
`_make_tuer_swing_curves`).
|
||||
- **3D-Stücke** (Rahmen/Glas/Flügel/Sims/Sturz) ≙ DOSSIER `_make_oeffnung_pieces`
|
||||
/ `_OEFF_PIECE_DEFS` — jeweils eigene Component (Farbe + Transparenz: Glas
|
||||
α≈0.88, IOR 1.5). Pieces landen auf Unter-Ebenen von `21 Türen/Fenster`.
|
||||
|
||||
---
|
||||
|
||||
## 3. Decke / Boden (Slab) — mit Aussparungen
|
||||
|
||||
### 3.1 Daten
|
||||
```ts
|
||||
interface Slab extends ElementBase {
|
||||
type: "slab";
|
||||
boundary: Vec2[]; // geschlossener Umriss (CCW)
|
||||
slabTypeId: string; // mehrschichtig (analog WallType)
|
||||
openings?: Vec2[][]; // Aussparungen: Treppenauge, Schacht, Kamin (DOSSIER aussp)
|
||||
ukOverride?: number; okOverride?: number; // UK/OK statt auto (Abhängung, schräge Brüstung)
|
||||
}
|
||||
```
|
||||
|
||||
### 3.2 Generierung
|
||||
- **Z-Auflösung:** `okOverride ?? (baseElevation_oberes_Geschoss)`,
|
||||
`ukOverride ?? (ok - thickness)` — Port von `_resolve_decke_z`. Decke sitzt
|
||||
standardmäßig zwischen zwei Geschossen.
|
||||
- **3D:** `boundary` als `THREE.Shape`, Aussparungen als `shape.holes` (`THREE.Path`),
|
||||
`ExtrudeGeometry` über die Schichten (≙ `_make_decke_volume(outline, holes)`).
|
||||
- **Plan:** im Schnitt unter `cutHeight` meist nur Kante; Aussparungs-Ränder als
|
||||
Linien; geschnittene Decke (in Schnitt-Ansicht) bekommt Schraffur.
|
||||
- **Aussparung↔Decke:** Aussparung als geschlossene Curve, die räumlich in der
|
||||
Decke liegt (`_find_decke_containing_point` / `_find_aussparungen_for_decke`).
|
||||
Bei uns: `Slab.openings` direkt im Slab — keine separate Source nötig (einfacher
|
||||
als DOSSIERs Parent-Child).
|
||||
|
||||
---
|
||||
|
||||
## 4. Treppe (Stair) — Typen, Lauflinie, geschossübergreifend
|
||||
|
||||
### 4.1 Daten
|
||||
```ts
|
||||
interface Stair extends ElementBase {
|
||||
type: "stair";
|
||||
kind: "straight" | "l-shaped" | "spiral"; // gerade | L | Wendel (DOSSIER _TREPPE_ARTEN)
|
||||
run: Vec2[]; // Lauflinien-Stützpunkte (gerade: 2; L: 3; Wendel: Zentrum+Start)
|
||||
width: number;
|
||||
reference: "mid" | "left" | "right"; // Lage der Lauflinie zur Treppe
|
||||
steps: number; // Anzahl Steigungen
|
||||
mode: "solid" | "flat" | "slab-edge"; // massiv | flach | Plattenrand
|
||||
runSlabThickness?: number; // Lauf-Plattendicke
|
||||
floorEndId?: string; // Zielgeschoss (geschossübergreifend, Risiko #6)
|
||||
heightOverride?: number; ukOverride?: number;
|
||||
rules?: { riser:[lo,hi,on]; tread:[lo,hi,on]; stepGo:[lo,hi,on] }; // SIA-Komfortregeln
|
||||
lockRiser?: { value: number }; // Schrittmass-Lock (S fix, N passt sich an)
|
||||
// Plan-Symbol-Flags (DOSSIER _KEY_TREPPE_SHOW_*)
|
||||
show?: { treads; runLine; outline; breakLine };
|
||||
upperDashed?: boolean; // obere Stufen gestrichelt (über Schnitthöhe)
|
||||
arrowStyle?: "classic"|"filled"|"double"|"line";
|
||||
}
|
||||
```
|
||||
|
||||
### 4.2 Generierung
|
||||
- **Steigung/Auftritt:** `riser = height/steps`; `tread` aus Lauflinienlänge /
|
||||
(steps−1). SIA-Komfort: `2·riser + tread ∈ [0.60, 0.65]` (DOSSIER
|
||||
`_TREPPE_SOLL_DEFAULT`). Lock: ist `lockRiser` gesetzt, wird `steps` neu
|
||||
berechnet statt `riser` zu ändern.
|
||||
- **3D je `kind`:** gerade → Stapel von Tritt-Quadern oder massive Rampe;
|
||||
L → zwei Läufe + Podest (`podestMin`); Wendel → um Zentrum rotierte Tritte
|
||||
(Port `_make_treppe_*_preview` / Volume-Funktionen). `mode` steuert massiv vs.
|
||||
Lauf-Platte.
|
||||
- **Geschossübergreifend (Risiko #6):** Höhe = `(baseElevation[floorEndId] -
|
||||
baseElevation[floorId])` falls `floorEndId` gesetzt; sonst Geschosshöhe. Treppe
|
||||
taucht dann in beiden Geschoss-Grundrissen auf (mit Schnitt an `cutHeight`).
|
||||
- **Plan-Symbol (normgerecht):** Lauflinie mit **Auf-/Abpfeil** (`arrowStyle`),
|
||||
Stufenkanten, Bruchlinie an `cutHeight` (untere durchgezogen, obere gestrichelt
|
||||
via `upperDashed`), Außenkante. ≙ DOSSIERs 2D-Treppensymbol; liegt auf Ebene
|
||||
`40 Treppen`/`41 Treppen-2D`.
|
||||
|
||||
### 4.3 Grip-Editing
|
||||
Lauflinien-Stützpunkte als Grips (wie Wand-Vertices, §1.4); Ziehen ändert
|
||||
Geometrie + Stufenzahl reaktiv.
|
||||
|
||||
---
|
||||
|
||||
## 5. Dach (Roof)
|
||||
|
||||
### 5.1 Daten
|
||||
```ts
|
||||
interface Roof extends ElementBase {
|
||||
type: "roof";
|
||||
outline: Vec2[]; // Grundriss-Umriss
|
||||
roofType: "mono" | "gable" | "hip" | "mansard"; // Pult|Sattel|Walm|Mansarde
|
||||
thickness: number;
|
||||
slope: number; // Grad (Hauptneigung)
|
||||
eaveIndex?: number; // Index der Traufkante (Pult)
|
||||
ridge?: "long" | "short"; // Firstrichtung (Sattel)
|
||||
// Mansarde:
|
||||
slopeLower?: number; kinkHeight?: number;
|
||||
mansardVariant?: "hip" | "gable" | "hip-gable";
|
||||
}
|
||||
```
|
||||
|
||||
### 5.2 Generierung
|
||||
Port von DOSSIERs `_make_pultdach/_satteldach/_walmdach/_mansardendach*` +
|
||||
`_thicken_roof_inward`. Aufwand M–L (Mansarde später). Reihenfolge: Pult →
|
||||
Sattel → Walm → Mansarde. 3D als Brep/Mesh über OpenCascade.js (Worker), da
|
||||
Schräg-Verschneidung Booleans braucht. Plan: Firstlinien + Traufe + ggf.
|
||||
Höhenkoten.
|
||||
|
||||
---
|
||||
|
||||
## 6. Tragwerk (Column / Beam)
|
||||
|
||||
### 6.1 Daten
|
||||
```ts
|
||||
interface ProfileDef {
|
||||
shape: "square"|"rect"|"round"|"i-beam"|"tube"; // DOSSIER _TRAG_PROFILE
|
||||
b?: number; h?: number; d?: number; t?: number; // Breite/Höhe/Durchm./Wanddicke
|
||||
angle: number; // Rotation um Z
|
||||
}
|
||||
interface Column extends ElementBase { type:"column"; point: Vec2; profile: ProfileDef;
|
||||
uk?: number; ok?: number; }
|
||||
interface Beam extends ElementBase { type:"beam"; axis:[Vec2,Vec2]; profile: ProfileDef;
|
||||
zTop?: number; // hängt unter Decken-OK (zTop = ok der Decke)
|
||||
}
|
||||
```
|
||||
|
||||
### 6.2 Generierung
|
||||
- **Querschnitt:** `profileCurve(shape, b,h,d,t, angle)` (Port `_trag_profile_curve`)
|
||||
→ für Stütze entlang Z extrudieren (`_make_stuetze_volume`), für Träger entlang
|
||||
der Achse (`_make_traeger_volume`, Profil in der Schnitt-Ebene).
|
||||
- **Träger achs-basiert unter Decke:** `zTop` default = OK der darüberliegenden
|
||||
Decke → Unterzug folgt automatisch (weniger Update-Fehler, ROADMAP §11).
|
||||
- Stützen liegen auf `25 Stützen`, Träger auf `35 Träger`.
|
||||
|
||||
---
|
||||
|
||||
## 7. Raum (Space) — SIA-416 + Stempel
|
||||
|
||||
### 7.1 Daten
|
||||
```ts
|
||||
interface Space extends ElementBase {
|
||||
type: "space";
|
||||
boundary: Vec2[]; // geschlossener Umriss
|
||||
number?: string; spaceName?: string; function?: string;
|
||||
sia?: "" | "HNF"|"NNF"|"VF"|"FF"|"GF"|"AGF"; // SIA-416-Klasse
|
||||
persons?: number; // Personenbelegung (Brandschutz)
|
||||
areaRounding: "exact"|"0.01"|"0.1"|"0.5"|"1";
|
||||
stamp: StampConfig; // Raumstempel-Layout (s.u.)
|
||||
fill?: string; // Füll-Hatch-Id (optional)
|
||||
}
|
||||
interface StampConfig { // ≙ DOSSIER Stempel-Builder
|
||||
layout: FieldId[][]; // Zeilen × Felder, z.B. [["number","name"],["function"],["area"]]
|
||||
font; bold; italic; textHeight; textMode:"fixed"|"scale"; align:"left"|"mid"|"right";
|
||||
offset: Vec2; // Stempel-Position relativ zum Centroid (User-Move)
|
||||
}
|
||||
type FieldId = "number"|"name"|"function"|"area"|"sia";
|
||||
```
|
||||
|
||||
### 7.2 Generierung & Bilanz
|
||||
- **Fläche:** Shoelace-Formel über `boundary`, gerundet nach `areaRounding`
|
||||
(`_resolve_raum_rundung`). Umfang analog.
|
||||
- **Stempel:** als SVG-Text-Block aus `layout`-Zeilen am Centroid + `offset`
|
||||
(User kann verschieben; Offset persistiert wie DOSSIER `stamp_dx/dy`).
|
||||
`textMode:"scale"` → Texthöhe in Paper-mm × Massstab (plans-output.md).
|
||||
- **SIA-Färbung:** über die **Overrides-Engine** (regelbasiert), nicht hartcodiert
|
||||
— DOSSIER `_build_sia_preset_rules` erzeugt 4 Regeln `userString sia == hnf|nnf|vf|ff`
|
||||
→ Farbe + Solid-Hatch. Bei uns: ein Override-Preset „SIA-416" (resources-graphics.md),
|
||||
das auf `space.sia` matcht. Toggle = Preset aktivieren.
|
||||
- **SIA-Bilanz + CSV:** `panels/SiaBalance.tsx` summiert Flächen je Klasse je
|
||||
Geschoss → Tabelle + CSV-Export (`HNF/NNF/VF/FF/GF/AGF`). Pflicht für
|
||||
CH-Flächennachweis (ROADMAP ⭐).
|
||||
|
||||
---
|
||||
|
||||
## 8. Werkzeuge (Tools) — ersetzt Rhino-Command-Aliases
|
||||
|
||||
DOSSIER hat pro Bauteil ein Command-Alias (`rhino/aliases/cmd/wand.py`, `tuer.py`,
|
||||
`treppe.py`, …) das `GetPoint`-Interaktionen fährt. Browser: ein **Tool-Interface**
|
||||
mit Pointer-Handlern + Snap.
|
||||
|
||||
```ts
|
||||
interface Tool {
|
||||
id: ToolId;
|
||||
onPointerDown(pt: Vec2, snap: SnapResult, state): void;
|
||||
onPointerMove(pt: Vec2, snap: SnapResult, state): Primitive[]; // Live-Preview
|
||||
onPointerUp(pt: Vec2, snap: SnapResult, state): void;
|
||||
commit(store): void; // ruft store.apply()
|
||||
}
|
||||
```
|
||||
|
||||
| Tool | DOSSIER-Alias | Kurzbeschrieb |
|
||||
|---|---|---|
|
||||
| `wall` | `cmd/wand` | Achse zeichnen (Linie/Polyline), Dicke/Referenz/Typ aus „last used" |
|
||||
| `door`/`window` | `cmd/tuer`,`fenster` | Punkt auf Wandachse → hosten (Snap an Wand) |
|
||||
| `slab` | `cmd/decke` | Umriss klicken; Aussparung als Loch |
|
||||
| `stair` | `cmd/treppe` | Lauflinie + Breite + Stufen |
|
||||
| `roof` | `cmd/dach` | Umriss + Typ + Neigung |
|
||||
| `column`/`beam` | `cmd/stuetze`,`traeger` | Punkt / Achse + Profil |
|
||||
| `space` | `cmd/raum` | Umriss → Fläche auto, Stempel |
|
||||
| `draw2d` | `cmd/symbol`,`stempel` | Linie/Polyline/Rect/Kreis/Bogen/Text auf `60 Plangrafik` |
|
||||
| `pipette` | `cmd/pipette` | Stil/Typ von Element übernehmen |
|
||||
|
||||
**Snap-Engine** (`tools/snap.ts`): Endpunkt, Mitte, Schnitt, senkrecht, Raster,
|
||||
Ortho — ersetzt Rhinos OSnap. T-Snap an andere Wandachsen (Port
|
||||
`_t_snap_to_wand_axis`, `_snap_endpoint_to_other_wand_axis`) sorgt für saubere
|
||||
Knoten.
|
||||
|
||||
---
|
||||
|
||||
## 9. Element-Übersicht (BIM-Tree)
|
||||
`panels/ElementTree.tsx`: Baum Geschoss → Bauteiltyp → Element, mit Suche und
|
||||
Shift-Klick = Zoom (DOSSIER ELEMENTE-ÜBERSICHT). Inhaltsverzeichnis bei 100+
|
||||
Elementen — reine Ableitung aus `project.elements`.
|
||||
|
||||
---
|
||||
|
||||
## 10. Reihenfolge der Umsetzung (verweist auf ROADMAP-Phasen)
|
||||
|
||||
1. **Phase 1:** Wand mehrschichtig ✅ + L-Gehrung ✅ → **Prio-T-Stoß** (§1.3);
|
||||
Tür/Fenster gehostet (§2); Decke + Aussparung (§3); Wand-Referenzlage (§1.1);
|
||||
Element-Übersicht (§9).
|
||||
2. **Phase 2:** Treppe (§4), Dach (§5), Tragwerk (§6), SIA-Räume + Stempel (§7),
|
||||
Stil-Kataloge.
|
||||
3. **Phase 3–4:** Grip-Editing (§1.4/§4.3), exakte B-Rep-Booleans im Worker.
|
||||
@@ -0,0 +1,498 @@
|
||||
# Design — Ebenen-Darstellung (Layer Display Settings)
|
||||
|
||||
> Teil der Standalone-Architektur — siehe [../../ARCHITECTURE.md](../../ARCHITECTURE.md).
|
||||
> Ressourcen/Stile: [resources-graphics.md](resources-graphics.md). Output/Pläne:
|
||||
> [plans-output.md](plans-output.md). Kontextmenü/Inline-Editor:
|
||||
> [context-menu.md](context-menu.md).
|
||||
|
||||
Dieses Dokument spezifiziert die **per-Ebene Darstellungseinstellungen** auf der
|
||||
`LayerCategory` (Grafik-Kategorie) und den dazugehörigen Editor
|
||||
„Ebeneneinstellungen…", der aus dem Ebenen-Kontextmenü geöffnet wird.
|
||||
|
||||
Heute trägt jede `LayerCategory` nur eine flache Strichstärke (`lw`), eine `color`
|
||||
und eine optionale `hatch` (ein freier String, der nirgends aufgelöst wird). Das
|
||||
reicht nicht: Eine Ebene soll — wie in Vectorworks/DOSSIER — einen vollständigen
|
||||
**Stift (PEN)** und eine vollständige **Standard-Schraffur (HATCH)** definieren,
|
||||
die beim Rendern angewandt werden. Bezeichner englisch, Prosa/UI-Text deutsch
|
||||
(CONVENTIONS.md).
|
||||
|
||||
---
|
||||
|
||||
## 1. Zielbild
|
||||
|
||||
Jede Ebene definiert zwei Darstellungs-Aspekte, die in den Grundriss-Generator
|
||||
einfließen:
|
||||
|
||||
- **PEN** — Linienstil der Ebene: `type` (durchgezogen / gestrichelt / …),
|
||||
`color` und `lw` (Strichstärke in mm Papier). Steuert alle Umriss-/Symbol-Linien
|
||||
der Elemente dieser Ebene (Wand-Umriss, Tür-Symbol, Referenzlinie).
|
||||
- **HATCH** — Standard-Schraffur der Ebene: `pattern`, `scale`, `angle` und die
|
||||
`lineWeight` der Musterlinien. Wird angewandt, wo ein Element keine eigene
|
||||
Schraffur aus einem `Component` mitbringt (z. B. einschichtige/„grob"-Flächen,
|
||||
reine 2D-Zeichnungsobjekte einer Ebene).
|
||||
|
||||
Beides folgt dem Architektur-Prinzip: **Darstellung wird beim Rendern aufgelöst,
|
||||
nie in die Geometrie eingebacken.**
|
||||
|
||||
---
|
||||
|
||||
## 2. Reference vs. Inline — Entscheidung
|
||||
|
||||
Es gibt drei Modelle, ein Datum für PEN/HATCH einer Ebene zu halten:
|
||||
|
||||
1. **Pure inline** — die Ebene trägt `{type,color,lw}` und `{pattern,scale,angle,
|
||||
lineWeight}` direkt. Einfach, aber: kein Wiederverwenden, kein zentrales
|
||||
Ändern; widerspricht der Ressourcen-Architektur (resources-graphics.md §1:
|
||||
„alles verweist per id, zentral änderbar").
|
||||
2. **Pure reference** — die Ebene trägt nur `lineStyleId` / `hatchId`. Konsistent,
|
||||
zentral, aber unflexibel: Eine Ebene kann z. B. nicht „den Stil X, aber in
|
||||
ihrer eigenen Farbe" wollen, ohne einen Klon-Stil anzulegen.
|
||||
3. **Reference + optionale per-Ebene Overrides** (EMPFOHLEN) — die Ebene
|
||||
**verweist** auf eine `LineStyle`- bzw. `HatchStyle`-Ressource und darf
|
||||
**einzelne Felder lokal überschreiben**. Das ist exakt das DOSSIER/Vectorworks-
|
||||
Muster: ein Stil als Basis, regelbasierte/lokale Overrides obendrauf
|
||||
(resources-graphics.md, `overrides.py`).
|
||||
|
||||
### Empfehlung: Reference + optionale Overrides
|
||||
|
||||
Begründung:
|
||||
|
||||
- **Zentrale Pflege bleibt erhalten:** Ändert man den Linienstil „Wand stark" im
|
||||
Line Manager, ziehen alle Ebenen nach, die ihn referenzieren und das jeweilige
|
||||
Feld nicht überschreiben.
|
||||
- **Lokale Freiheit ohne Stil-Wildwuchs:** Eine Ebene kann punktuell `color` oder
|
||||
`lw` anpassen (häufigster Fall: gleiche Strichart, andere Farbe), ohne einen
|
||||
fast identischen Stil zu duplizieren.
|
||||
- **Migrationsfähig:** Die heutige flache `{color, lw}` der Ebene wird zu reinen
|
||||
Overrides über einem neutralen Basis-Stil — verlustfrei (siehe §6).
|
||||
- **Konsistent mit der bestehenden Kette:** `Component → Hatch → LineStyle`
|
||||
verweist bereits per id; Ebenen reihen sich nahtlos ein.
|
||||
|
||||
Die Overrides sind **sparse**: nur gesetzte Felder überschreiben. Ein leeres
|
||||
Override-Objekt (oder `undefined`) bedeutet „komplett dem Stil folgen".
|
||||
|
||||
---
|
||||
|
||||
## 3. Datenmodell (TS)
|
||||
|
||||
### 3.1 LineStyle erweitern um `type`
|
||||
|
||||
`LineStyle` trägt heute schon `weight`, `color`, `dash`. Wir machen die
|
||||
Strichart explizit benennbar (statt nur via `dash`-Array), damit der Editor ein
|
||||
sauberes Dropdown anbietet und `dash` daraus ableiten kann.
|
||||
|
||||
```ts
|
||||
/** Benannte Strichart eines Stifts (für UI-Dropdown). */
|
||||
export type LineKind = "solid" | "dashed" | "dotted" | "dashdot";
|
||||
|
||||
/** mm-Strichmuster je Strichart (relativ zur Papier-mm). */
|
||||
export const LINE_DASH: Record<LineKind, number[] | null> = {
|
||||
solid: null,
|
||||
dashed: [0.6, 0.4],
|
||||
dotted: [0.1, 0.25],
|
||||
dashdot: [0.6, 0.25, 0.1, 0.25],
|
||||
};
|
||||
|
||||
export interface LineStyle {
|
||||
id: string;
|
||||
name: string;
|
||||
/** NEU: benannte Strichart; `dash` wird daraus abgeleitet, falls nicht gesetzt. */
|
||||
kind: LineKind;
|
||||
/** Strichstärke in Millimetern (≙ Rhino PlotWeight). */
|
||||
weight: number;
|
||||
color: string;
|
||||
/** Strichmuster in mm; `null` = durchgezogen. Optional — sonst aus `kind`. */
|
||||
dash: number[] | null;
|
||||
}
|
||||
```
|
||||
|
||||
> Hinweis: `kind` ist additiv; bestehende `LineStyle`-Daten setzen es per Migration
|
||||
> aus `dash` (§6).
|
||||
|
||||
### 3.2 PEN- und HATCH-Override-Typen
|
||||
|
||||
```ts
|
||||
/**
|
||||
* Per-Ebene Stift (PEN). Verweist auf einen LineStyle; einzelne Felder dürfen
|
||||
* lokal überschrieben werden. Alle Override-Felder optional (sparse).
|
||||
*/
|
||||
export interface LayerPen {
|
||||
/** Basis-Linienstil (Line Manager). */
|
||||
lineStyleId: string;
|
||||
/** Lokale Overrides — nur gesetzte Felder gewinnen. */
|
||||
override?: {
|
||||
kind?: LineKind;
|
||||
color?: string;
|
||||
/** Strichstärke in mm Papier. */
|
||||
lw?: number;
|
||||
};
|
||||
}
|
||||
|
||||
/**
|
||||
* Per-Ebene Standard-Schraffur (HATCH). Verweist auf einen HatchStyle; einzelne
|
||||
* Felder dürfen lokal überschrieben werden. `enabled=false` = Ebene hat keine
|
||||
* Default-Schraffur (Umriss-only).
|
||||
*/
|
||||
export interface LayerHatch {
|
||||
/** Aktiv? false = keine Default-Schraffur dieser Ebene. */
|
||||
enabled: boolean;
|
||||
/** Basis-Schraffur (Hatch Manager). */
|
||||
hatchId: string;
|
||||
/** Lokale Overrides — nur gesetzte Felder gewinnen. */
|
||||
override?: {
|
||||
pattern?: HatchPattern;
|
||||
scale?: number;
|
||||
/** Drehung in Grad. */
|
||||
angle?: number;
|
||||
color?: string;
|
||||
/** Strichstärke der Musterlinien in mm Papier. */
|
||||
lineWeight?: number;
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
### 3.3 LayerCategory erweitern
|
||||
|
||||
```ts
|
||||
export interface LayerCategory {
|
||||
code: string;
|
||||
name: string;
|
||||
visible: boolean;
|
||||
locked: boolean;
|
||||
|
||||
// ── NEU: vollständige Darstellung ──────────────────────────────────────────
|
||||
/** Stift der Ebene (PEN) — Linien aller Elemente dieser Ebene. */
|
||||
pen: LayerPen;
|
||||
/** Standard-Schraffur der Ebene (HATCH). */
|
||||
hatch: LayerHatch;
|
||||
|
||||
/** Unterkategorien (Baum). */
|
||||
children?: LayerCategory[];
|
||||
|
||||
// ── DEPRECATED (nur Übergang; siehe Migration §6) ──────────────────────────
|
||||
/** @deprecated → pen.override.color. */
|
||||
color?: string;
|
||||
/** @deprecated → pen.override.lw. */
|
||||
lw?: number;
|
||||
}
|
||||
```
|
||||
|
||||
`color` und `lw` bleiben als optionale, deprecatete Felder bestehen, bis alle
|
||||
Lesepfade auf den Resolver (§4) umgestellt sind, und werden dann entfernt. Die
|
||||
Panel-Swatch (`LayersPanel`) liest künftig die **aufgelöste** Stift-Farbe.
|
||||
|
||||
---
|
||||
|
||||
## 4. Resolver — vom Modell zur Render-Entscheidung
|
||||
|
||||
Der Resolver löst PEN/HATCH einer Ebene gegen die Ressourcen-Bibliotheken auf und
|
||||
wendet die Overrides an. Er ist die **einzige** Stelle, an der „Stil + Override"
|
||||
zusammenfließen; Generator und Panel rufen nur ihn.
|
||||
|
||||
### 4.1 Aufgelöste Render-Typen
|
||||
|
||||
`HatchRender` existiert bereits in `generatePlan.ts`. Wir ergänzen ein paralleles
|
||||
`PenRender` und exportieren beide Resolver aus einem neuen Modul
|
||||
`src/model/layerStyle.ts` (damit Panel und Generator teilen).
|
||||
|
||||
```ts
|
||||
/** Aufgelöster Stift einer Ebene — alles, was die Linie zu zeichnen braucht. */
|
||||
export interface PenRender {
|
||||
color: string;
|
||||
/** Strichstärke in mm Papier. */
|
||||
lw: number;
|
||||
/** Strichmuster in mm Papier; null = durchgezogen. */
|
||||
dash: number[] | null;
|
||||
}
|
||||
|
||||
// HatchRender: bereits in generatePlan.ts definiert (pattern, scale, angle,
|
||||
// color, lineWeight, dash). Wird nach layerStyle.ts gezogen und re-exportiert.
|
||||
```
|
||||
|
||||
### 4.2 Resolver-Funktionen (Pseudocode)
|
||||
|
||||
```ts
|
||||
function resolvePen(project: Project, layer: LayerCategory): PenRender {
|
||||
const ls = getLineStyle(project, layer.pen.lineStyleId); // wirft, falls fehlend
|
||||
const o = layer.pen.override ?? {};
|
||||
const kind = o.kind ?? ls.kind;
|
||||
return {
|
||||
color: o.color ?? ls.color,
|
||||
lw: o.lw ?? ls.weight,
|
||||
// Override-kind setzt das dash neu; sonst Stil-dash bzw. aus kind abgeleitet.
|
||||
dash: o.kind ? LINE_DASH[o.kind] : (ls.dash ?? LINE_DASH[ls.kind]),
|
||||
};
|
||||
}
|
||||
|
||||
function resolveLayerHatch(project: Project, layer: LayerCategory): HatchRender | null {
|
||||
if (!layer.hatch.enabled) return null; // Ebene ohne Default-Schraffur
|
||||
const h = getHatch(project, layer.hatch.hatchId); // wirft, falls fehlend
|
||||
const o = layer.hatch.override ?? {};
|
||||
// Musterlinien-Stärke: Override > LineStyle der Schraffur > Default 0.13 mm.
|
||||
const baseLs = h.lineStyleId ? getLineStyle(project, h.lineStyleId) : null;
|
||||
return {
|
||||
pattern: o.pattern ?? h.pattern,
|
||||
scale: o.scale ?? h.scale,
|
||||
angle: o.angle ?? h.angle,
|
||||
color: o.color ?? h.color,
|
||||
lineWeight: o.lineWeight ?? baseLs?.weight ?? 0.13,
|
||||
dash: baseLs?.dash ?? null,
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
Beide bauen eine `Map<code, …>` über den ganzen Baum, analog zur heutigen
|
||||
`categoryLwMap`:
|
||||
|
||||
```ts
|
||||
export function penMap(project: Project): Map<string, PenRender> {
|
||||
const m = new Map<string, PenRender>();
|
||||
for (const c of flattenCategories(project.layers)) m.set(c.code, resolvePen(project, c));
|
||||
return m;
|
||||
}
|
||||
export function layerHatchMap(project: Project): Map<string, HatchRender | null> {
|
||||
const m = new Map<string, HatchRender | null>();
|
||||
for (const c of flattenCategories(project.layers))
|
||||
m.set(c.code, resolveLayerHatch(project, c));
|
||||
return m;
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 5. Einfluss auf `generatePlan`
|
||||
|
||||
Heute (generatePlan.ts):
|
||||
|
||||
- `categoryLwMap(project.layers)` liefert nur `lw` je Code; die Umriss-Strichstärke
|
||||
kommt daraus, **Farbe** der Umrisse ist fest `POCHE_STROKE`.
|
||||
- Schraffur kommt ausschließlich aus dem `Component` der jeweiligen Schicht
|
||||
(`resolveHatch(project, comp.hatchId)`); die Ebenen-`hatch` wird **nicht** genutzt.
|
||||
|
||||
Änderungen (minimal-invasiv, additiv):
|
||||
|
||||
### 5.1 Pens ersetzen `lwByCode`
|
||||
|
||||
```ts
|
||||
const pens = penMap(project); // statt categoryLwMap
|
||||
const layerHatches = layerHatchMap(project);
|
||||
…
|
||||
const pen = pens.get(wall.categoryCode) ?? FALLBACK_PEN; // {color, lw, dash}
|
||||
```
|
||||
|
||||
`addWallPoche` und `addDoorSymbol` bekommen statt `wallLwMm: number` /
|
||||
`doorLwMm: number` jeweils das ganze `pen: PenRender`:
|
||||
|
||||
- **Wand-Umrisslinie:** `stroke: pen.color` (statt fix `POCHE_STROKE`),
|
||||
`strokeWidthMm: pen.lw * OUTLINE_DETAIL_FACTOR[detail]`, `dash: pen.dash`.
|
||||
→ Das `Primitive` „polygon" braucht ein optionales `dash?: number[] | null`
|
||||
(Schichtfugen bleiben durchgezogen; nur die Umriss-Kontur nutzt `pen.dash`).
|
||||
- **Schichtfugen:** behalten `POCHE_STROKE` und ihre dünne `LAYER_LINE_MM`
|
||||
(interne Hilfslinien sind bewusst neutral, nicht stift-gefärbt).
|
||||
- **Tür-Symbol / Referenzlinie:** `cls` bleibt, aber `weightMm` aus `pen.lw`,
|
||||
und die PlanView darf die Stift-Farbe nutzen (`door-leaf` etc. erhalten optional
|
||||
ein `stroke`-Feld am line/arc-Primitive; ansonsten greift die CSS-Klasse wie
|
||||
bisher).
|
||||
|
||||
### 5.2 Default-Schraffur der Ebene
|
||||
|
||||
Die Ebenen-Schraffur greift dort, wo **keine Component-Schraffur** vorliegt:
|
||||
|
||||
- **`detail === "grob"`** (eine Sammelfläche, heute `NO_HATCH`): statt `NO_HATCH`
|
||||
nun `layerHatches.get(wall.categoryCode) ?? NO_HATCH`. So bekommt die grobe
|
||||
Poché die Standard-Schraffur der Ebene (z. B. ein leichtes Diagonalmuster),
|
||||
falls die Ebene eine definiert; sonst bleibt sie ungeschraffiert.
|
||||
- **mittel/fein, mehrschichtig:** unverändert — die Component-Schraffur je Schicht
|
||||
hat Vorrang (spezifischer als die Ebene). Die Ebenen-Schraffur ist der
|
||||
*Fallback*, nicht der Default-Override.
|
||||
- **Reine 2D-Zeichnungsobjekte** (künftige `drawing`-Ebenen-Elemente ohne
|
||||
Component): nutzen direkt `resolveLayerHatch` als ihre Füllschraffur.
|
||||
|
||||
Auflöse-Reihenfolge der Schraffur einer gezeichneten Fläche:
|
||||
|
||||
```
|
||||
Component.hatch > LayerCategory.hatch (enabled) > keine Schraffur
|
||||
```
|
||||
|
||||
### 5.3 Geänderte Signaturen (Zusammenfassung)
|
||||
|
||||
```ts
|
||||
// vorher: addWallPoche(out, project, wall, doors, cuts, greyed, detail, wallLwMm)
|
||||
function addWallPoche(out, project, wall, doors, cuts, greyed, detail,
|
||||
pen: PenRender, layerHatch: HatchRender | null): void
|
||||
|
||||
// vorher: addDoorSymbol(out, wall, door, greyed, detail, doorLwMm)
|
||||
function addDoorSymbol(out, wall, door, greyed, detail, pen: PenRender): void
|
||||
```
|
||||
|
||||
`Primitive` (polygon) erhält optional `dash?: number[] | null`; line/arc erhalten
|
||||
optional `stroke?: string`, damit Pen-Farbe durchschlagen kann (CSS-Klasse bleibt
|
||||
Default).
|
||||
|
||||
---
|
||||
|
||||
## 6. Editor „Ebeneneinstellungen…"
|
||||
|
||||
Geöffnet wie heute über `layerMenuItems → openLayerEditor(code)` →
|
||||
`setEditor({ kind: "layer", code, x, y })`. Der bestehende `InlineEditor`-Rahmen
|
||||
(dunkel, am Anker, Esc/Außenklick schließt) und die `EditorField`-Zeilen bleiben;
|
||||
der Inhalt wächst von 3 Feldern auf zwei kompakte Abschnitte **PEN** und **HATCH**.
|
||||
|
||||
Da der Editor jetzt mehr Felder trägt, wird er als **kompakte Sektions-Form**
|
||||
gestaltet (zwei Gruppen mit Trenn-Überschrift), gemäß CONVENTIONS.md UI-Konventionen
|
||||
(saubere Form, keine wiederholten Beschriftungen, DOSSIER-Stil, alles via `t()`).
|
||||
|
||||
### 6.1 Aufbau
|
||||
|
||||
```
|
||||
┌ Ebene 20 ───────────────── ×
|
||||
│ Name [ Wände ]
|
||||
│
|
||||
│ ── Stift (PEN) ──────────────
|
||||
│ Linienstil [ Wand stark ▾ ] ← Dropdown über project.lineStyles
|
||||
│ Strichart [ durchgezogen ▾ ] ← override.kind (leer = "vom Stil")
|
||||
│ Farbe [■] [↺] ← override.color; ↺ = Override entfernen
|
||||
│ Stärke [ 0.35 ] mm [↺] ← override.lw
|
||||
│
|
||||
│ ── Schraffur (HATCH) ────────
|
||||
│ [✓] aktiv
|
||||
│ Schraffur [ Beton ▾ ] ← Dropdown über project.hatches
|
||||
│ Muster [ vom Stil ▾ ] ← override.pattern
|
||||
│ Maßstab [ 1.00 ] [↺]
|
||||
│ Drehung [ 45 ] ° [↺]
|
||||
│ Farbe [■] [↺]
|
||||
│ Linienst. [ 0.13 ] mm [↺]
|
||||
└──────────────────────────────
|
||||
```
|
||||
|
||||
- **Override-Semantik im UI:** Jedes Override-Feld zeigt entweder „vom Stil"
|
||||
(Override leer → Platzhalter mit dem aufgelösten Stil-Wert als Hint) oder einen
|
||||
konkreten Wert. Ein kleiner **Reset-Knopf `↺`** je Override-Feld löscht das
|
||||
Override (setzt es zurück auf `undefined` → Feld folgt wieder dem Stil).
|
||||
- **Live, kein Bestätigen:** wie der heutige Editor — jede Änderung ruft sofort
|
||||
`patchCategory(code, patch)`.
|
||||
- **i18n:** alle Labels über `t()`. Neue Keys (Beispiele):
|
||||
`editor.pen`, `editor.lineStyle`, `editor.lineKind`, `editor.color`,
|
||||
`editor.lineWeight`, `editor.hatch`, `editor.hatchEnabled`, `editor.pattern`,
|
||||
`editor.scale`, `editor.rotation`, `editor.fromStyle`, `editor.resetOverride`.
|
||||
Strichart-/Muster-Werte: `lineKind.solid`, `lineKind.dashed`, …,
|
||||
`hatchPattern.solid`, `hatchPattern.diagonal`, … . Menü-Label bleibt
|
||||
`ctx.layerSettings`.
|
||||
|
||||
### 6.2 Patch-Helfer
|
||||
|
||||
`patchCategory(code, patch: Partial<LayerCategory>)` bleibt die Schnittstelle.
|
||||
Für die verschachtelten Overrides nutzt der Editor schmale Helfer (im App-Scope),
|
||||
die sparse mergen und leere Overrides auf `undefined` kollabieren:
|
||||
|
||||
```ts
|
||||
function setPenOverride(cat: LayerCategory, patch: Partial<LayerPen["override"]>) {
|
||||
const next = pruneEmpty({ ...cat.pen.override, ...patch });
|
||||
patchCategory(cat.code, { pen: { ...cat.pen, override: next } });
|
||||
}
|
||||
function setHatchOverride(cat, patch) { /* analog für cat.hatch.override */ }
|
||||
// pruneEmpty: entfernt undefined-Felder; gibt undefined zurück, wenn leer.
|
||||
```
|
||||
|
||||
`setLineStyleId` / `setHatchId` setzen nur die Referenz; `hatch.enabled` ist ein
|
||||
Checkbox-Patch.
|
||||
|
||||
### 6.3 „Eigenschaften kopieren / einfügen"
|
||||
|
||||
Der bestehende `layerClipboard` (heute `{ color, lw }`) wird auf die volle
|
||||
Darstellung erweitert: `{ pen, hatch }` (die Override-tragenden Strukturen, ohne
|
||||
`code/name/visible/locked`). „Kopieren" liest `{ pen, hatch }` der Quelle,
|
||||
„Einfügen" patcht sie auf das Ziel. So überträgt sich der komplette Stift +
|
||||
Schraffur einer Ebene auf eine andere.
|
||||
|
||||
---
|
||||
|
||||
## 7. Migration bestehender Beispieldaten
|
||||
|
||||
Bestehende Projekte/Sample-Daten haben `LayerCategory { color, lw, hatch?: string }`
|
||||
und `LineStyle { weight, color, dash }` (ohne `kind`). Eine reine Lese-Zeit-
|
||||
Migration (`migrateProject(project)`), idempotent, beim Laden:
|
||||
|
||||
1. **LineStyle.kind ableiten** — aus `dash`:
|
||||
```
|
||||
dash == null || dash.length === 0 → "solid"
|
||||
sonst, wenn min(dash) sehr klein → "dotted" (heuristisch)
|
||||
sonst → "dashed"
|
||||
```
|
||||
(Eine genaue Zuordnung ist nicht nötig; `dash` bleibt führend, `kind` ist nur
|
||||
für das Dropdown.)
|
||||
|
||||
2. **Neutralen Basis-Linienstil sicherstellen** — falls die Bibliothek noch keinen
|
||||
generischen „Standard"-Stift hat, einen `lineStyle` mit
|
||||
`{ id: "ls-default", name: "Standard", kind: "solid", weight: <Ebenen-lw>, color: "#000", dash: null }`
|
||||
anlegen. (Pro Ebene wird der Stift referenziert; die Ebenen-spezifischen
|
||||
`color`/`lw` wandern in das **Override**, nicht in den Stil — so bleibt der
|
||||
Stil wiederverwendbar.)
|
||||
|
||||
3. **Pro LayerCategory `pen` bauen:**
|
||||
```ts
|
||||
pen = {
|
||||
lineStyleId: "ls-default",
|
||||
override: pruneEmpty({ color: cat.color, lw: cat.lw }),
|
||||
}
|
||||
```
|
||||
Damit ist die Darstellung **pixelgenau wie vorher** (gleiche Farbe, gleiche lw),
|
||||
nur jetzt über die Resolver-Kette.
|
||||
|
||||
4. **Pro LayerCategory `hatch` bauen** — aus dem alten `hatch?: string`:
|
||||
- War `hatch` ein gültiger `HatchStyle.id` → `{ enabled: true, hatchId: hatch }`.
|
||||
- War es ein Pattern-Name oder leer/unbekannt → `{ enabled: false, hatchId:
|
||||
<erste Hatch-id der Bibliothek> }` (Referenz muss existieren, aber inaktiv).
|
||||
So entsteht **keine** unbeabsichtigte Schraffur (Default heute: keine).
|
||||
|
||||
5. **Deprecated-Felder belassen** für eine Übergangsphase; nach Umstellung aller
|
||||
Lesepfade (`generatePlan`, `LayersPanel`-Swatch, Clipboard) in einem zweiten
|
||||
Schritt `color`/`lw` aus `LayerCategory` und der alte `hatch: string` entfernen.
|
||||
|
||||
Migration ist **idempotent**: Liegt `pen`/`hatch` bereits vor, wird die Ebene
|
||||
unverändert durchgereicht.
|
||||
|
||||
---
|
||||
|
||||
## 8. Build-Plan (phasiert)
|
||||
|
||||
**Phase 1 — Datenmodell & Resolver (keine UI-Sichtbarkeit).**
|
||||
- `LineKind` + `LINE_DASH`, `LineStyle.kind`, `LayerPen`, `LayerHatch`,
|
||||
`LayerCategory.pen/hatch` in `types.ts`.
|
||||
- `src/model/layerStyle.ts`: `PenRender`, `resolvePen`, `resolveLayerHatch`,
|
||||
`penMap`, `layerHatchMap`; `HatchRender` hierher ziehen + re-exportieren.
|
||||
- `migrateProject()` (Schritte §7) + Aufruf beim Laden/Seed.
|
||||
- `npx tsc -b` grün.
|
||||
|
||||
**Phase 2 — Generator umstellen.**
|
||||
- `generatePlan` nutzt `penMap`/`layerHatchMap` statt `categoryLwMap`.
|
||||
- `Primitive`-polygon `dash?`, line/arc `stroke?` ergänzen; `addWallPoche`/
|
||||
`addDoorSymbol`-Signaturen auf `PenRender` + `HatchRender|null`.
|
||||
- Ebenen-Default-Schraffur in „grob" und für Schicht-lose Flächen verdrahten.
|
||||
- Visuell prüfen via `node scripts/probe.mjs` (Geometrie unverändert, Farben/lw
|
||||
identisch zur Migration).
|
||||
|
||||
**Phase 3 — Panel.**
|
||||
- `LayersPanel`-Swatch liest aufgelöste Stift-Farbe (`resolvePen(...).color`).
|
||||
|
||||
**Phase 4 — Editor.**
|
||||
- `InlineEditor`-Inhalt für `kind: "layer"` auf die PEN/HATCH-Sektionen erweitern
|
||||
(§6), mit Dropdowns über `project.lineStyles` / `project.hatches`, Reset-Knöpfen,
|
||||
neuen i18n-Keys.
|
||||
- `layerClipboard` auf `{ pen, hatch }` erweitern; Kopieren/Einfügen anpassen.
|
||||
|
||||
**Phase 5 — Aufräumen.**
|
||||
- Deprecatete `color`/`lw`/`hatch: string` aus `LayerCategory` entfernen, sobald
|
||||
kein Lesepfad sie mehr nutzt; Sample-Daten direkt im neuen Format ablegen.
|
||||
|
||||
---
|
||||
|
||||
## 9. Offene Punkte / bewusst nicht jetzt
|
||||
|
||||
- **Pro-Geschoss-Overrides der Ebene** (eine Ebene anders je `DrawingLevel`):
|
||||
nicht in dieser Iteration; das Schema gilt geschossübergreifend (types.ts).
|
||||
Falls später nötig, als zweite Override-Ebene über demselben Resolver.
|
||||
- **Regelbasierte Overrides** (resources-graphics.md, `overrides.py`): orthogonal;
|
||||
würden nach der Ebenen-Auflösung greifen.
|
||||
- **Linienstil-Endkappen/Joins** und feinere Dash-Skalierung: bleiben in der
|
||||
PlanView (Darstellung), nicht im Modell.
|
||||
@@ -0,0 +1,338 @@
|
||||
# Design — Pläne & Output
|
||||
|
||||
> Teil der Standalone-Architektur — siehe [../../ARCHITECTURE.md](../../ARCHITECTURE.md).
|
||||
> Bauteile: [elements.md](elements.md). Ressourcen/Stile: [resources-graphics.md](resources-graphics.md).
|
||||
|
||||
Hier gewinnen wir (ROADMAP §3, Phase 3 ⭐): **schöne, normgerechte 2D-Pläne**,
|
||||
automatisch aus dem Modell abgeleitet, druckfertig als Vektor-PDF. Dieses Dokument
|
||||
übersetzt DOSSIERs `schnitte.py`, `massstab.py`, `ausschnitte.py`, `kamera.py`,
|
||||
`dimensionen.py`, `layouts.py` in Browser-Module. Bezeichner englisch, Prosa
|
||||
deutsch, Meter.
|
||||
|
||||
---
|
||||
|
||||
## 1. Ansichtstypen = Kamera-Projektion + optionaler Schnitt
|
||||
|
||||
Vereinheitlichtes Modell (ROADMAP §2c, im Spike als `DrawingLevelKind` angelegt):
|
||||
|
||||
| Typ | Projektion | Schnitt | Erzeugung |
|
||||
|---|---|---|---|
|
||||
| **Grundriss** | Ortho Top | horizontal auf `okff + cutHeight` | symbolisch aus Footprint (Pfad A) |
|
||||
| **Schnitt** | Ortho Front (Richtung) | vertikale Schnittebene + Tiefe | 3D-Projektion/HLR (Pfad B) |
|
||||
| **Ansicht** | Ortho Front (Richtung) | kein Schnitt (Fassade außen) | 3D-Projektion/HLR (Pfad B) |
|
||||
| **Perspektive** | 3D perspektivisch | — | Three.js direkt |
|
||||
|
||||
```ts
|
||||
type ViewType = "plan" | "section" | "elevation" | "perspective";
|
||||
interface DerivedView { // was der Viewport gerade zeigt
|
||||
type: ViewType;
|
||||
levelId?: string; // Geschoss (plan) bzw. Schnitt/Ansicht (DrawingLevel)
|
||||
camera: CameraState;
|
||||
cut?: CutSpec; // Clipping-Spezifikation (s.u.)
|
||||
detailLevel: DetailLevel;
|
||||
}
|
||||
interface CutSpec {
|
||||
planes: { point: Vec3; normal: Vec3 }[]; // 1 (plan/elevation) oder 2 (section: cut+back)
|
||||
}
|
||||
```
|
||||
|
||||
**Zwei Wege zum Plan** (zentrale Architektur-Erkenntnis, ROADMAP §3) — wir bauen
|
||||
**beide**:
|
||||
- **A) Grundriss = symbolisch** aus den Parametern (`plan/generatePlan.ts`, im
|
||||
Spike). Schnell, exakt, vektorbasiert. Kein Mesh-Schnitt.
|
||||
- **B) Schnitt & Ansicht = 3D-Projektion mit Hidden-Line-Removal** (`plan/
|
||||
generateSection.ts`, §4). Durch das zusammengebaute Gebäude.
|
||||
|
||||
---
|
||||
|
||||
## 2. Schnitt & Ansicht — Datenmodell & Aktivierung
|
||||
|
||||
DOSSIER speichert Schnitte als Zeichnungsebenen-Eintrag (`type:"schnitt"`) mit
|
||||
`linePts/dirSign/depthBack/cutAtLine/heightMin/heightMax/projection`
|
||||
(`schnitte.create_schnitt_entry`). Im Spike sind die Felder als `DrawingLevel`
|
||||
(`kind:"section"|"elevation"`, `linePoints`, `directionSign`) angelegt — wir
|
||||
ergänzen:
|
||||
|
||||
```ts
|
||||
interface SectionLevel extends DrawingLevel { // kind: "section" | "elevation"
|
||||
linePoints: [Vec2, Vec2];
|
||||
directionSign: 1 | -1; // Blickrichtung (Pfeil im Plan)
|
||||
depthBack: number; // Tiefe hinter der Schnittlinie (default 8)
|
||||
cutAtLine: boolean; // true=Schnitt (cut+back), false=Ansicht (nur back)
|
||||
heightMin: number; heightMax: number;
|
||||
projection: "parallel" | "perspective";
|
||||
}
|
||||
```
|
||||
|
||||
**Aktivierung** (Port `schnitte.activate_schnitt`):
|
||||
1. `view_dir` = senkrecht zur Linie in XY, Richtung = `directionSign`.
|
||||
2. **3D-Vorschau:** `THREE.Plane`s setzen —
|
||||
- Cut (nur `cutAtLine`): auf der Linie, Normale `+view_dir`.
|
||||
- Back (immer): um `depthBack` in `+view_dir` versetzt, Normale `−view_dir`.
|
||||
- via `renderer.localClippingEnabled = true`, `material.clippingPlanes`.
|
||||
3. **Kamera:** `OrthographicCamera`, Position `mid − view_dir·dist`, Target `mid`,
|
||||
Up `+Z`; Zoom auf BBox (`linePoints` + Höhenbereich + `depthBack`). Bei
|
||||
`perspective`: `PerspectiveCamera` + FOV.
|
||||
4. **Vektor-Ergebnis:** HLR (§4).
|
||||
|
||||
**2D-Plan-Symbol** (Schnittmarke im Grundriss, Port `make_schnitt_symbol`): Linie
|
||||
+ Endpfeile in `view_dir`, Beschriftung. Bleibt im Grundriss sichtbar (liegt auf
|
||||
einer eigenen Ebene, z.B. `18 Schnittlinien`). **Doppelklick** auf das Symbol
|
||||
aktiviert den Schnitt (`onDoubleClick` auf das SVG-Symbol → `setActiveLevel(id)`,
|
||||
≙ DOSSIER `_SchnittDoubleClickHandler`).
|
||||
|
||||
**Grip-Editing der Schnittlinie:** Endpunkte als Grips im Grundriss; Ziehen
|
||||
aktualisiert `linePoints` + Symbol + (falls aktiv) Clipping — ohne Re-Zoom der
|
||||
3D-View (DOSSIER `skip_view`-Flag-Äquivalent: Drag aktualisiert nur die Clip-
|
||||
Ebenen, nicht die Kamera).
|
||||
|
||||
---
|
||||
|
||||
## 3. Massstab (Scale) — pro Viewport, Auto-DPI
|
||||
|
||||
### 3.1 Mathematik (Port `massstab._compute_scale`, identisch im Browser)
|
||||
```
|
||||
frustumWidth_world = ortho-Kamera-Breite in Modell-Einheiten (Meter)
|
||||
frustumWidth_mm = frustumWidth_world * 1000 (Meter→mm)
|
||||
screenWidth_mm = canvasWidthCssPx * 25.4 / dpi
|
||||
N (1:N) = frustumWidth_mm / screenWidth_mm
|
||||
```
|
||||
- **Nur bei Orthografie** sinnvoll; in Perspektive zeigt die UI „—" (wie DOSSIER).
|
||||
- **DPI:** Browser kennt das nativ — `dpi = 96 * window.devicePixelRatio` (CSS
|
||||
definiert 1 px = 1/96 inch). Das ersetzt DOSSIERs CoreGraphics-JXA-Detection
|
||||
komplett und ist exakter. Optional manuell kalibrierbar (Eingabe in den
|
||||
Settings), persistiert pro Projekt.
|
||||
- **Massstab setzen** (1:N → Zoom): `frustumWidth_world = screenWidth_mm · N /
|
||||
1000`; bei `THREE.OrthographicCamera` `camera.zoom = canvasWidthCssPx /
|
||||
(frustumWidth_world / metersPerPixelAtZoom1)` bzw. direkt `left/right` setzen.
|
||||
|
||||
```ts
|
||||
// plan/scale.ts
|
||||
function computeScale(view: { frustumWidthWorld; canvasCssWidthPx; dpi }): number|null // 1:N
|
||||
function applyScale(camera: THREE.OrthographicCamera, n: number, canvasCssWidthPx, dpi): void
|
||||
const SCALE_PRESETS = [1,5,10,20,25,50,100,200,500,1000]; // 1:N Dropdown
|
||||
```
|
||||
|
||||
### 3.2 Massstabs-abhängige Skalierung (DOSSIER-Stärke)
|
||||
Bei 1:N müssen **Strichstärken** und **Schraffuren** lesbar bleiben:
|
||||
- **Plotweight → SVG stroke-width:** `strokeWidthPx = lwMm / 25.4 · dpi`
|
||||
(Welt-unabhängig; die Linie ist im Plan immer z.B. 0.25 mm dick). DOSSIER
|
||||
skaliert dafür die PlotWeights (`_apply_scaled_lineweights`); im SVG-Modell
|
||||
rechnen wir die mm-Strichstärke direkt in Pixel — **viel einfacher**, da SVG
|
||||
von Natur aus papierbezogen ist.
|
||||
- **Schraffur-Skalierung:** DOSSIER nutzt `factor = sqrt(N)/10` (1:100 ⇒ 1.0,
|
||||
1:50 ⇒ 0.71, 1:500 ⇒ 2.24; `apply_scaled_hatches`). Port: SVG `<pattern>`-
|
||||
`patternTransform="scale(factor)"` bzw. `patternUnits` so wählen, dass das Muster
|
||||
die gewünschte Paper-Dichte hat. Formel 1:1 übernehmen.
|
||||
- **Linetype-Dash:** `stroke-dasharray` in mm→px, ebenfalls papierbezogen.
|
||||
|
||||
> **Kernvorteil gegenüber DOSSIER:** Weil der Plan **SVG/Paper-Space** ist,
|
||||
> entfällt das fragile Welt↔Bildschirm-Plotweight-Rescaling (DOSSIER `write_plotweight`,
|
||||
> `read_plotweight`, Print-Display-Toggle). Strichstärke und Maßlinien sind direkt
|
||||
> in mm definiert und werden 1:1 gedruckt.
|
||||
|
||||
---
|
||||
|
||||
## 4. Schnitt/Ansicht-Projektion (HLR) — Risiko #4
|
||||
|
||||
Vertikale Schnitte/Ansichten brauchen **echte 3D-Projektion mit verdeckten
|
||||
Kanten** durch das zusammengebaute Gebäude.
|
||||
|
||||
```ts
|
||||
// plan/generateSection.ts (läuft im Web Worker via Comlink)
|
||||
interface SectionRequest { meshes: SerializedBrep[]; cut: CutSpec; camera: CameraState; }
|
||||
interface SectionResult {
|
||||
cutLines: Primitive[]; // Schnittkanten (dick) — geschnittene Bauteile
|
||||
cutFaces: Primitive[]; // Schnittflächen → Component-Schraffur (Poché)
|
||||
visibleLines: Primitive[]; // sichtbare Projektion (dünn)
|
||||
hiddenLines?: Primitive[]; // verdeckte (gestrichelt, optional)
|
||||
}
|
||||
function generateSection(req: SectionRequest): SectionResult
|
||||
```
|
||||
|
||||
- **Kernel:** **OpenCascade.js** `HLRBRep_Algo` / `HLRBRep_HLRToShape` (B-Rep →
|
||||
sichtbare/verdeckte Kanten). Eingabe = die Bauteil-Breps (Wände/Decken/Treppen…),
|
||||
Projektionsrichtung aus `camera`. Alternativ Mesh-basiert (langsamer, weniger
|
||||
sauber).
|
||||
- **Schnittflächen-Schraffur (Section-Style):** wo die Cut-Plane ein Bauteil
|
||||
durchschneidet, entsteht eine Fläche → mit der Component-Schraffur füllen
|
||||
(resources-graphics.md). ≙ DOSSIER `SectionStyle` (Hatch + Schnittkante +
|
||||
Silhouette), nur dass wir es als SVG-Fill rendern statt als Rhino-Layer-Property.
|
||||
- **Performance:** schwer → **Worker + Cache**. Cache-Key =
|
||||
hash(sichtbare Element-IDs + Geometrie-Hash + CutSpec + camera). Nur neu rechnen,
|
||||
wenn sich relevante Eingaben ändern (ROADMAP Risiko #4). Geschnittene vs. dahinter
|
||||
liegende Geometrie über die Back-Plane begrenzen (`depthBack`).
|
||||
- **Stufenweise:** (a) Ansicht ohne Verdeckung (einfache Projektion) → (b) HLR
|
||||
sichtbar → (c) verdeckte Kanten gestrichelt → (d) Schnittflächen-Poché.
|
||||
|
||||
---
|
||||
|
||||
## 5. Ausschnitte (View-Snapshots)
|
||||
|
||||
Navigation über 50+ Ansichten ohne Ordner-Wildwuchs (DOSSIER `ausschnitte.py`).
|
||||
Ein Snapshot speichert **Kamera + Sichtbarkeit + Massstab + Darstellung + Overrides**.
|
||||
|
||||
```ts
|
||||
// in Project: viewSnapshots: ViewSnapshot[]
|
||||
interface ViewSnapshot {
|
||||
id; name; folder?: string;
|
||||
camera: CameraState; // pos/target/up/parallel/fov + frustumWidth (Zoom!)
|
||||
scale: number; // 1:N (DOSSIER speichert "1:50"-String)
|
||||
detailLevel: DetailLevel; // LoD-Override (DOSSIER darstellung)
|
||||
visibility: VisibilityState; // pro Geschoss + pro Ebene visible/locked
|
||||
layerCombinationId?: string; // ODER Verweis auf Layer-Kombi (live) — s.u.
|
||||
overrides?: { presetId?: string; enabled: boolean };
|
||||
}
|
||||
interface CameraState { position; target; up; parallel; fov?; frustumWidth?; }
|
||||
```
|
||||
|
||||
- **Save:** aktuellen `ui`-Zustand einfrieren (Port `_capture`: Kamera inkl.
|
||||
Frustum-Breite für exakten Zoom-Restore, Layer-Sichtbarkeit, Massstab, LoD).
|
||||
- **Restore:** Snapshot → `ui` + ggf. `project`-Sichtbarkeit anwenden (Port
|
||||
`_restore`): Kamera, Sichtbarkeit (oder referenzierte Layer-Kombi), LoD,
|
||||
optional Overrides-Preset. Da alles im Store liegt, ist das ein einfacher
|
||||
State-Set — kein Multi-Panel-Force-Send-Tanz wie in DOSSIER.
|
||||
- **Ordner, Umbenennen, Duplizieren, Settings-Drawer** wie DOSSIER (`_duplicate`,
|
||||
`_set_field`, `_open_settings_window` → React-Drawer statt Eto-Form).
|
||||
|
||||
### 5.1 Layer-Kombinationen (Presets)
|
||||
```ts
|
||||
interface LayerCombination { id; name; visibility: VisibilityState; }
|
||||
```
|
||||
Bauphasen/Varianten/MEP per Klick (DOSSIER `_save_preset`/`apply_layer_preset_by_name`).
|
||||
Snapshot kann **live** auf eine Kombi verweisen (folgt Änderungen) **oder**
|
||||
eingefroren den `visibility`-Stand halten — genau DOSSIERs Wahl (`layerCombination`
|
||||
vs. `layers`).
|
||||
|
||||
---
|
||||
|
||||
## 6. Kamera-Presets & Norden-Rotation ⭐
|
||||
|
||||
Port `kamera.py`. Schnelle Ansichtswechsel + Georeferenzierung (Swisstopo, Phase 4).
|
||||
|
||||
```ts
|
||||
// viewport/camera.ts
|
||||
function setCardinal(cam, dir: "N"|"E"|"S"|"W", northAngle: number): void
|
||||
function setIso(cam, octant: "NE"|"SE"|"SW"|"NW"|..., northAngle: number): void
|
||||
function setTop(cam, northAngle: number): void // Plan-Norden zeigt nach oben
|
||||
// northAngle = Grad im Uhrzeigersinn von +Y (DOSSIER dossier_north_angle, default 0)
|
||||
const north = (deg) => ({ x: Math.sin(rad(deg)), y: Math.cos(rad(deg)) });
|
||||
interface CameraPreset { id; name; camera: CameraState; } // benutzerdefiniert, gespeichert
|
||||
```
|
||||
- **Norden-Rotation:** alle Kardinal-/Iso-Richtungen werden um `northAngle`
|
||||
rotiert (Port `set_cardinal_view`, `_set_iso`, `set_top_view`). `northAngle`
|
||||
liegt im `Project` (georeferenziert zu swissBUILDINGS).
|
||||
- **Benutzer-Presets:** speichern/laden wie DOSSIER (`_load_presets`/`_save_presets`).
|
||||
|
||||
---
|
||||
|
||||
## 7. Bemaßung (Dimensions)
|
||||
|
||||
Port `dimensionen.py`. Maße werden **aus dem Modell abgeleitet** (Wand-Dicken,
|
||||
Geschoss-Höhen, Öffnungen) + manuelle Maßketten.
|
||||
|
||||
```ts
|
||||
interface Dimension {
|
||||
id; floorId; categoryCode; // liegt auf einer Ebene
|
||||
kind: "linear" | "chain" | "aligned" | "level"; // Einzel|Kette|ausgerichtet|Höhenkote
|
||||
refs: DimRef[]; // Bezugspunkte (frei ODER an Element gebunden)
|
||||
offset: number; // Abstand der Maßlinie vom Objekt
|
||||
style: DimStyleId; // Pfeile, Texthöhe, Einheiten
|
||||
}
|
||||
type DimRef = { point: Vec2 } | { elementId: string; anchor: "start"|"end"|"jamb"|... };
|
||||
```
|
||||
- **Auto-Bemaßung** (Phase 3): Außenketten (Gebäude-Hülle), Achsketten (Achsraster),
|
||||
Öffnungs-Ketten — aus der Geometrie generiert, dann editierbar.
|
||||
- **9-Punkt-Objekt-Info** (DOSSIER ROADMAP §11): Bounding-Box-Maße lesen +
|
||||
Element via Greifen verschieben/skalieren/rotieren — direkt im Plan.
|
||||
- **Rich-Text-Indizes** (Bold/Hoch-/Tiefstellung) für Maßzahlen — als SVG
|
||||
`<tspan>` mit `baseline-shift` (resources-graphics.md §Rich-Text).
|
||||
- **Massstabsbezug:** Texthöhe/Pfeilgröße in **Paper-mm**, rendern × Massstab —
|
||||
konsistent mit §3.2.
|
||||
|
||||
---
|
||||
|
||||
## 8. Plansätze (Sheets) & PDF-Export
|
||||
|
||||
DOSSIER nutzt Rhinos `RhinoPageView` + `Detail`-Viewports + `FilePdf`
|
||||
(`layouts.py`). Browser-Äquivalent: eigenes Sheet-Modell + SVG → PDF.
|
||||
|
||||
### 8.1 Datenmodell
|
||||
```ts
|
||||
interface Sheet {
|
||||
id; name; folder?;
|
||||
paper: "A0"|"A1"|"A2"|"A3"|"A4"|"Letter"; landscape: boolean;
|
||||
viewports: SheetViewport[];
|
||||
titleBlock?: TitleBlock; // Titelblock (Projekt/Plan/Massstab/Datum)
|
||||
}
|
||||
interface SheetViewport { // ≙ DOSSIER Detail + gebundener Ausschnitt
|
||||
id; rect: { x; y; w; h }; // Position auf dem Blatt (mm)
|
||||
source: { kind: "level"; levelId } | { kind: "snapshot"; snapshotId };
|
||||
scale: number; // 1:N
|
||||
clipToRect: boolean;
|
||||
}
|
||||
const PAPER_MM = { A0:[841,1189], A1:[594,841], A2:[420,594], A3:[297,420],
|
||||
A4:[210,297], Letter:[216,279] }; // Port PAPER_SIZES_MM
|
||||
```
|
||||
|
||||
### 8.2 Sheet-Editor
|
||||
`sheets/SheetEditor.tsx`: Blatt als SVG in mm, Viewports per Drag platzieren/
|
||||
skalieren, Quelle (Geschoss/Snapshot) + Massstab zuweisen. Ein Viewport rendert
|
||||
den abgeleiteten Plan/Schnitt **bei seinem Massstab** in sein `rect` (≙ DOSSIER
|
||||
`apply_snapshot_to_detail`). Bei Änderung der Quelle re-derivieren (live), kein
|
||||
manuelles Re-Sync nötig (DOSSIER war Snapshot-Mode).
|
||||
|
||||
### 8.3 Detail↔Ausschnitt-Bindung
|
||||
`SheetViewport.source.snapshotId` ist die Bindung (DOSSIER `_BIND_KEY`). „Alle
|
||||
aktualisieren" = alle Viewports neu rendern; weil rein abgeleitet, ist das
|
||||
automatisch. Umbenennen synchronisiert Titelblock + Schnitt-Symbol (DOSSIER
|
||||
Detail↔Ausschnitt-Sync).
|
||||
|
||||
### 8.4 PDF-Export (Vektor, Multi-Page, @DPI)
|
||||
Port `layouts._export_pdf`, aber **vektorbasiert** (DOSSIER rasterte via
|
||||
`ViewCaptureToFile` @DPI — wir bleiben Vektor → schärfer, kleiner):
|
||||
|
||||
```ts
|
||||
// sheets/exportPdf.ts
|
||||
async function exportSheetsPdf(sheets: Sheet[], opts: { vector: boolean }): Promise<Blob>
|
||||
```
|
||||
- **Vektor-Pfad (bevorzugt):** jeder Sheet-Viewport rendert seinen Plan als SVG;
|
||||
SVG → PDF via **`svg2pdf.js` + `jsPDF`** (oder `pdf-lib` mit eigenem Pfad-
|
||||
Emit). Eine PDF-Seite pro Sheet, Größe = `PAPER_MM`. Strichstärken/Schraffuren
|
||||
sind bereits in mm (§3.2) → 1:1 druckbar.
|
||||
- **Raster-Fallback** (Perspektiven/3D-Inhalte): Three.js `renderer` → Canvas →
|
||||
PNG @DPI → in PDF-Seite (`px = mm/25.4·dpi`, Port der DOSSIER-Pixelrechnung).
|
||||
- **Speichern:** Blob → File System Access API (`showSaveFilePicker`) / Download.
|
||||
|
||||
---
|
||||
|
||||
## 9. Primitive & SVG-Serializer (gemeinsame Basis)
|
||||
|
||||
Alle Pläne (Grundriss, Schnitt, Ansicht, Sheet-Viewport) sprechen dieselbe
|
||||
`Primitive`-Sprache (heute in `generatePlan.ts`), erweitert um Schraffur/Text:
|
||||
|
||||
```ts
|
||||
type Primitive =
|
||||
| { kind:"polygon"; pts:Vec2[]; fill:string; stroke:string; strokeWidthMm:number; hatchId?:string }
|
||||
| { kind:"line"; a:Vec2; b:Vec2; styleId:string } // styleId → LineStyle (mm, dash)
|
||||
| { kind:"arc"; center:Vec2; from:Vec2; to:Vec2; r:number; styleId:string }
|
||||
| { kind:"text"; at:Vec2; text:string; heightMm:number; align; font; rich?:RichRun[] }
|
||||
| { kind:"symbol"; at:Vec2; symbolId:string; scale:number; angle:number }; // Symbol-Bibliothek
|
||||
interface Plan { primitives: Primitive[]; bounds: Rect; }
|
||||
```
|
||||
- **SVG-Serializer** (`plan/primitives.ts`): Primitive → SVG-Elemente.
|
||||
`strokeWidthMm` → px via `mm·dpi/25.4`; `hatchId` → `<pattern>`-Referenz;
|
||||
`styleId` → `stroke`/`stroke-dasharray`. Derselbe Serializer für Bildschirm
|
||||
*und* PDF.
|
||||
- **DXF-Export** (Phase 4): dieselben Primitive → DXF-Entities (`dxf`-Writer-lib).
|
||||
|
||||
---
|
||||
|
||||
## 10. Umsetzungs-Reihenfolge (verweist auf ROADMAP-Phasen)
|
||||
|
||||
1. **Phase 1 (MVP):** Grundriss-Generator ✅ ausbauen (Schraffuren, LoD), Live-
|
||||
Grundriss neben 3D, Basis-Bemaßung; Massstab pro Viewport (§3).
|
||||
2. **Phase 3 ⭐:** Schnitt/Ansicht via HLR (§4, Worker), Auto-Bemaßung (§7),
|
||||
Ausschnitte + Layer-Kombinationen (§5), Kamera-Presets + Norden (§6),
|
||||
Sheets + Vektor-PDF (§8).
|
||||
3. **Phase 4:** DXF-Export (§9), Detail↔Ausschnitt-Sync-Politur.
|
||||
@@ -0,0 +1,293 @@
|
||||
# Design — Ressourcen & Grafik
|
||||
|
||||
> Teil der Standalone-Architektur — siehe [../../ARCHITECTURE.md](../../ARCHITECTURE.md).
|
||||
> Bauteile: [elements.md](elements.md). Output/Pläne: [plans-output.md](plans-output.md).
|
||||
|
||||
Die **Stil-Schicht**: verwaltete Ressourcen-Bibliotheken (Vectorworks-Stil),
|
||||
regelbasierte Overrides, Symbol-/Text-Bibliotheken und Detailgrad-Steuerung. Sie
|
||||
wird **beim Rendern angewandt, nie in die Geometrie eingebacken** (ROADMAP §2b).
|
||||
Dieses Dokument übersetzt DOSSIERs `styles.py`/`gestaltung.py`, `mass_style.py`,
|
||||
`overrides.py`, `library.py`, `text_create.py`. Bezeichner englisch, Prosa
|
||||
deutsch.
|
||||
|
||||
---
|
||||
|
||||
## 1. Resource Manager — verwaltete Bibliotheken
|
||||
|
||||
Drei Bibliotheken im `Project.resources`-Block; **alles verweist per id**, zentral
|
||||
änderbar (ROADMAP §2d). Verweis-Kette: 2D-Objekte/Ebenen → LineStyle/Hatch;
|
||||
Hatch → LineStyle; Component → Hatch (+3D-Material).
|
||||
|
||||
```ts
|
||||
interface Resources {
|
||||
lineStyles: LineStyle[];
|
||||
hatches: Hatch[];
|
||||
components: Component[];
|
||||
}
|
||||
|
||||
interface LineStyle { // Line Manager
|
||||
id; name;
|
||||
weight: number; // Strichstärke in mm (≙ Rhino PlotWeight)
|
||||
color: string; // hex
|
||||
dash: number[]; // Strichmuster in mm ([] = durchgezogen)
|
||||
}
|
||||
|
||||
interface Hatch { // Hatch Manager
|
||||
id; name;
|
||||
pattern: PatternId; // "solid" | "diagonal" | "insulation" | "concrete" | ...
|
||||
scale: number; // Grundmaßstab des Musters
|
||||
angle: number; // Grad
|
||||
lineStyleId: string; // Linien der Schraffur → Line Manager
|
||||
}
|
||||
|
||||
interface Component { // Component Manager (= DOSSIER-Material, erweitert)
|
||||
id; name;
|
||||
hatchId: string; // Schnitt-Schraffur → Hatch Manager
|
||||
color3d: string; // 3D-Diffusfarbe
|
||||
texture3d?: TextureRef; // optionale PBR-Textur (Phase 3)
|
||||
pbr?: { roughness; metalness; opacity; ior }; // Material-Bibliothek (ROADMAP §11)
|
||||
joinPriority: number; // Verschneidungs-Rang (DOSSIER _MATERIAL_PRIO als Daten)
|
||||
}
|
||||
```
|
||||
|
||||
**Migration vom heutigen Stand:** Der Spike hat `Material { color, planFill, hatch }`
|
||||
und `Layer { materialId, thickness, priority }`. Ziel: `Material → Component`
|
||||
(`color→color3d`, `planFill→` Fill aus `hatch.pattern==solid`+Farbe, `hatch`-Enum
|
||||
→ `hatchId`), `Layer.priority → Component.joinPriority` (Priorität wandert vom
|
||||
Layer zum Component, damit man sie nur einmal pflegt — siehe elements.md §1.3).
|
||||
|
||||
### 1.1 Manager-UI
|
||||
`managers/ComponentManager.tsx`, `HatchManager.tsx`, `LineManager.tsx` — je eine
|
||||
Liste mit CRUD + Vorschau (Three-Sphere für Component-3D, SVG-Swatch für
|
||||
Hatch/Line). **Seeds** beim ersten Projekt (DOSSIER-Defaults):
|
||||
- LineStyles: 0.13 / 0.18 / 0.25 / 0.35 / 0.50 mm (aus `DEFAULT_LAYER_SCHEMA`-lw).
|
||||
- Hatches: `solid`, `diagonal`, `concrete`, `insulation` (Dämmung).
|
||||
- Components: Stahlbeton (prio 800), Beton (800), Mauerwerk (600), Ziegel (550),
|
||||
Holzständer (400), Dämmung (200), Putz (100) — exakt DOSSIER `_MATERIAL_PRIO`
|
||||
(elements.md §1.3). Plus Glas (transparent), Holz-Türblatt (DOSSIER
|
||||
`_OEFF_PIECE_DEFS`).
|
||||
|
||||
### 1.2 Render-Anwendung
|
||||
- **3D:** Component → `MeshStandardMaterial` (`color3d`/`pbr`), pro `componentId`
|
||||
gecacht (`viewport/scene.ts`).
|
||||
- **Plan/Schnitt:** geschnittene Schicht → Polygon mit `fill` (Component-Farbe) +
|
||||
`<pattern>` aus `hatchId`. Pattern als SVG `<pattern>` mit `patternTransform`
|
||||
für Massstab (plans-output.md §3.2). Der Hatch nutzt seinen `lineStyleId` für
|
||||
die Musterlinien.
|
||||
|
||||
---
|
||||
|
||||
## 2. Mehrschichtige Aufbauten ↔ Ressourcen
|
||||
`WallType.layers[].componentId` / `SlabType.layers[].componentId` verweisen auf
|
||||
Components. 3D und Plan lesen dieselben Schichten (elements.md §1). Die
|
||||
**Prioritäts-Verschneidung** (Risiko #1) liest `Component.joinPriority`:
|
||||
höhere Priorität läuft am Stoß durch (Backbone), niedrigere stößt seitlich an —
|
||||
Algorithmus in elements.md §1.3 (Port DOSSIER `_t_junction_layer_overrides`).
|
||||
|
||||
---
|
||||
|
||||
## 3. Stile & Element-Override (Selektions-Attribute)
|
||||
|
||||
DOSSIERs GESTALTUNG-Panel (`styles.py`) setzt Farbe/Lineweight/Linetype/Hatch auf
|
||||
die *Selektion*. Browser-Äquivalent — zwei Ebenen, in Render-Reihenfolge:
|
||||
|
||||
```
|
||||
ByLayer (Ebenen-Default) → Element-Style (styleId) → Override-Regeln → gerendert
|
||||
```
|
||||
|
||||
```ts
|
||||
// Effektiver Stil eines Elements (resolve beim Rendern, nie persistiert)
|
||||
interface EffectiveStyle { color; lineStyleId; hatchId?; }
|
||||
function resolveStyle(project, el, doc): EffectiveStyle {
|
||||
// 1) Default aus LayerCategory(categoryCode)
|
||||
// 2) überschrieben durch el.styleId (Element-Override, optional)
|
||||
// 3) überschrieben durch passende Override-Regeln (§4)
|
||||
}
|
||||
```
|
||||
|
||||
- **Wall-/Opening-Stil-Kataloge** (Presets, ROADMAP §11): benannte Sätze von
|
||||
Default-Werten (Wandtyp + Farbe + lw; Öffnung mit Rahmen/Sims/…). 1-Klick-
|
||||
Anwendung, globaler Stilwechsel. Speicherung: pro Projekt + cross-Projekt
|
||||
(LocalStorage), Seed wie DOSSIER `_OEFF_DEFAULT_STYLES` (elements.md §2.1).
|
||||
- **LoD-bewusste Stil-UI** (DOSSIER ROADMAP §11): das Stil-Panel zeigt nur
|
||||
passende Controls je Geometrietyp (keine Füll-Optionen bei einer 3D-/Linien-
|
||||
Auswahl). `panels/StylePanel.tsx` schaltet Felder nach `selection`-Typ.
|
||||
- **Pipette:** Stil/Typ von einem Element auf ein anderes übernehmen (DOSSIER
|
||||
`cmd/pipette`).
|
||||
|
||||
---
|
||||
|
||||
## 4. Regelbasierte Overrides (Engine)
|
||||
|
||||
Port `overrides.py` (ArchiCAD Graphical Overrides / Vectorworks
|
||||
Datenvisualisierung). Im Browser **viel einfacher**, weil Overrides reine
|
||||
**Render-Transformationen** sind — kein UserString-Backup/Restore nötig (DOSSIER
|
||||
musste Originalwerte sichern, weil es echte Rhino-Objekte mutierte; wir mutieren
|
||||
nichts).
|
||||
|
||||
```ts
|
||||
interface OverrideConfig { enabled: boolean; rules: OverrideRule[]; activePresetId?: string; }
|
||||
interface OverrideRule {
|
||||
id; name; enabled: boolean;
|
||||
conditions: Condition[]; conditionsLogic: "and" | "or";
|
||||
actions: { color?: string; lineWeight?: number; lineStyleId?: string;
|
||||
hatchId?: string; hatchScale?: number };
|
||||
}
|
||||
interface Condition {
|
||||
type: "category" | "userField" | "name" | "elementType"; // ≙ layer_name/user_string/object_name
|
||||
operator: "equals"|"notEquals"|"contains"|"startsWith"|"endsWith";
|
||||
value: string;
|
||||
key?: string; // nur für userField (z.B. "sia")
|
||||
}
|
||||
```
|
||||
|
||||
**Auswertung** (Port `_compose_overrides`):
|
||||
```ts
|
||||
function composeOverrides(el, project, cfg): Partial<Actions> {
|
||||
// additive: Actions aller matchenden, aktiven Regeln kombinieren;
|
||||
// bei Konflikt für dieselbe Property gewinnt die Regel WEITER OBEN (kleinerer Index).
|
||||
}
|
||||
```
|
||||
- **Anwendung:** `resolveStyle` (§3) ruft `composeOverrides` — Override liegt
|
||||
über Element-Style. Reines Read beim Rendern → kein `apply_all`/`restore_all`,
|
||||
kein Backup, **keine reversibilität nötig**. Toggle `enabled` rendert neu.
|
||||
- **Live:** Da abgeleitet, schlägt jede Modell-/Regel-Änderung sofort durch (kein
|
||||
`install_listeners`/`AddRhinoObject`-Hook wie DOSSIER).
|
||||
- **Presets & Templates** (cross-Projekt): Preset = Satz Regeln, Template =
|
||||
einzelne Regel; LocalStorage statt `~/Library/.../override_presets.json`
|
||||
(`save_preset`/`load_preset`/`list_rule_templates` → `resources/overridePresets.ts`).
|
||||
- **SIA-416-Preset** (elements.md §7): vier Regeln `userField sia == HNF|NNF|VF|FF`
|
||||
→ Farbe + Solid-Hatch, Port `_build_sia_preset_rules`. Aktivieren = Preset
|
||||
`activePresetId` setzen.
|
||||
|
||||
```ts
|
||||
// resources/overrides.ts
|
||||
function composeOverrides(el, project, cfg): Partial<OverrideAction>
|
||||
function setActivePreset(project, presetId): Project // immutabel
|
||||
const PRESETS_NS = "cad.presets.overrides"; // LocalStorage
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 5. Symbol-Bibliothek
|
||||
|
||||
Port `library.py` + `cmd/symbol`. Wiederverwendbare 2D-Symbole (Möbel, Sanitär,
|
||||
Bäume, Nordpfeil, Pflanzen) für den Plan.
|
||||
|
||||
```ts
|
||||
interface Symbol {
|
||||
id; name; category: string; // "furniture" | "sanitary" | "vegetation" | "annotation"
|
||||
svgPath: string; // Pfad-/Gruppen-Markup im Symbol-Koordinatensystem (m)
|
||||
defaultScale: number;
|
||||
}
|
||||
interface SymbolInstance extends ElementBase { // type:"draw2d", subtype:"symbol"
|
||||
symbolId: string; at: Vec2; scale: number; angle: number;
|
||||
}
|
||||
```
|
||||
- **Speicherung:** mitgelieferte Symbole als statische Assets (SVG); Nutzer-
|
||||
Symbole im Projekt + cross-Projekt (LocalStorage). DOSSIER nutzt Block-
|
||||
Definitionen; bei uns SVG-Definition + Instanz-Transform (`<use>`-artig).
|
||||
- **Picker:** `panels/SymbolPicker.tsx` (≙ DOSSIER `SymbolPicker.jsx`) — Grid mit
|
||||
Vorschau, Drag in den Plan; Instanz auf Ebene `60 Plangrafik` (bzw. `22 Möbel`).
|
||||
- **Render:** `Primitive{ kind:"symbol", ... }` → SVG `<g transform>` mit dem
|
||||
Symbol-Markup (plans-output.md §9).
|
||||
|
||||
---
|
||||
|
||||
## 6. Text & Rich-Text-Annotationen
|
||||
|
||||
Port `text_create.py` + `text_editor.py`. Formatierte Beschriftungen auf Canvas.
|
||||
|
||||
```ts
|
||||
interface TextElement extends ElementBase { // type:"draw2d", subtype:"text"
|
||||
at: Vec2; runs: RichRun[];
|
||||
heightMm: number; // Paper-mm (rendern × Massstab) ODER Modell-m
|
||||
heightMode: "paper" | "model"; // DOSSIER raum_txt_modus fix|masstab
|
||||
font: string; align: "left"|"mid"|"right"; angle: number;
|
||||
mask?: boolean; // Hintergrund-Maskierung (verdeckt Linien darunter)
|
||||
frame?: boolean; // Rahmen um den Text
|
||||
}
|
||||
interface RichRun {
|
||||
text: string;
|
||||
bold?; italic?; super?; sub?; // Hoch-/Tiefstellung (Maß-Indizes)
|
||||
}
|
||||
interface TextStyle { id; name; font; heightMm; bold; italic; } // Text-Presets
|
||||
```
|
||||
- **Render:** `<text>` mit `<tspan>` pro Run; `super/sub` via `baseline-shift` +
|
||||
kleinerer `font-size`; `mask` via weißem `<rect>` darunter; `frame` via `<rect>`.
|
||||
- **Editor:** Inline-Rich-Text-Editor (contentEditable oder leichter Custom-Editor)
|
||||
→ `RichRun[]`. Fonts aus einer kuratierten Web-Font-Liste + System-Fonts
|
||||
(DOSSIER `_list_system_fonts` mit Preferred-Liste DM Mono/Krungthep/…); im
|
||||
Browser via `document.fonts` / `queryLocalFonts()` (wo verfügbar) + gebündelte
|
||||
Web-Fonts.
|
||||
- **Massstabsbezug:** `heightMode:"paper"` → Texthöhe in mm, gerendert × Massstab
|
||||
(plans-output.md §3) — Beschriftung bleibt bei jedem Massstab lesbar.
|
||||
|
||||
---
|
||||
|
||||
## 7. Detailgrad (Level of Detail)
|
||||
|
||||
Querschnittsthema (ROADMAP §2b „Modelldarstellungen"). Drei Stufen, Dokument-/
|
||||
Snapshot-weiter Override mit Per-Element-Ausnahme — DOSSIER
|
||||
`darstellung`/`aktive_darstellung`.
|
||||
|
||||
```ts
|
||||
type DetailLevel = "coarse" | "medium" | "fine"; // einfach | standard | detail
|
||||
// Auflösung (Port _resolve_oeff_darstellung):
|
||||
function resolveDetail(el, doc): DetailLevel {
|
||||
const v = el.detailLevel ?? "auto";
|
||||
return v === "auto" ? doc.detailLevel : v; // doc-Level hat IMMER konkreten Wert
|
||||
}
|
||||
```
|
||||
- **Dokument-Ebene:** `Project.detailLevel` (Default `coarse`/einfach = 1:100,
|
||||
DOSSIER `_DARSTELLUNG_DEFAULT_GLOBAL`). In der TopBar global umschaltbar; ein
|
||||
ViewSnapshot kann ihn pro Ansicht überschreiben (plans-output.md §5).
|
||||
- **Wirkung:** jedes Bauteil-`generatePlan`/`build3d` liest den aufgelösten LoD und
|
||||
zeichnet entsprechend (elements.md: Tür coarse=Lücke, fine=Glas/Schwenkbogen/
|
||||
Sims). Kritisch für Mixed-Scale-Pläne (1:50 Detail neben 1:200 Übersicht).
|
||||
- **Schnitt-Schraffur** koppelt an LoD: grob ggf. nur Umriss, fein voll schraffiert.
|
||||
|
||||
---
|
||||
|
||||
## 8. Section-Style (3D-Schnittflächen)
|
||||
Port DOSSIER `_apply_section_style` (`layer_builder.py`). Wo die Schnittebene ein
|
||||
Bauteil durchschneidet: Schnittfläche bekommt die **Component-Schraffur**, die
|
||||
Schnittkante einen dicken Rand, optional eine Silhouette.
|
||||
|
||||
```ts
|
||||
interface SectionStyle { // pro Component (oder Ebene) ableitbar
|
||||
hatchId?: string; hatchScale; hatchAngle;
|
||||
boundaryShow: boolean; boundaryLineStyleId; boundaryWidthScale;
|
||||
fillBackground: boolean;
|
||||
}
|
||||
```
|
||||
- **3D-Viewport:** Three.js hat keinen nativen „Schnittflächen-Cap". Cap-Geometrie
|
||||
selbst erzeugen: Schnittpolygon der Cut-Plane mit den Breps → Fläche mit
|
||||
Hatch-Material (oder Stencil-Cap-Technik). Phase 4.
|
||||
- **2D-Schnitt (SVG):** `generateSection` (plans-output.md §4) liefert `cutFaces`
|
||||
→ mit `SectionStyle.hatchId` füllen. Das ist der Hauptweg; der 3D-Cap ist Bonus.
|
||||
|
||||
---
|
||||
|
||||
## 9. Was Browser hier einfacher macht (vs. DOSSIER)
|
||||
|
||||
| DOSSIER-Aufwand | entfällt im Browser, weil … |
|
||||
|---|---|
|
||||
| UserString-Backup/Restore bei Overrides (`_backup_original`/`_restore_original`) | Overrides sind reine Render-Reads — nichts wird mutiert |
|
||||
| Hatch-Curve-Link über Sticky (`gestaltung_curve_hatch`, Pending-TTL) | Schraffur ist eine Eigenschaft des Polygons, kein separates Objekt |
|
||||
| Plotweight-Welt↔Bildschirm-Rescaling (`write/read_plotweight`) | Strichstärke ist in mm im SVG-Paper-Space (plans-output.md §3.2) |
|
||||
| `install_listeners` für Live-Override-Reapply | reaktiver Store re-rendert automatisch |
|
||||
| SectionStyle-API-Reflection über Rhino-Versionen | wir definieren das Rendering selbst (SVG/Three) |
|
||||
| Cross-doc Presets als Dateien im User-Home | LocalStorage + Export/Import |
|
||||
|
||||
---
|
||||
|
||||
## 10. Umsetzungs-Reihenfolge (verweist auf ROADMAP-Phasen)
|
||||
|
||||
1. **Phase 1:** Component/Hatch/Line-Manager (§1) + `resolveStyle` (§3) +
|
||||
LoD-Grundgerüst (§7) + LoD-bewusste Stil-UI.
|
||||
2. **Phase 2:** Stil-Kataloge (Wände/Öffnungen), Material-Seeds mit `joinPriority`.
|
||||
3. **Phase 3:** Overrides-Engine + SIA-Preset (§4), Symbol-Bibliothek (§5),
|
||||
Rich-Text (§6), PBR-Material-Bibliothek; massstabsabhängige Hatch-/Linetype-
|
||||
Skalierung (plans-output.md §3.2).
|
||||
4. **Phase 4:** Section-Style 3D-Cap (§8).
|
||||
@@ -0,0 +1,370 @@
|
||||
# Handoff — Rhino-artiges Befehlssystem + Modellier-Werkzeuge
|
||||
|
||||
> Für die Instanz, die das Befehlssystem (Tab-getriggert) und die Rhino-artigen
|
||||
> Modellierfunktionen baut. Stand: 2026-06-30. Zuerst lesen: `CONVENTIONS.md`,
|
||||
> `ROADMAP.md`, `HANDOVER.md`, `docs/design/drawing-tools.md`. Volle Autonomie,
|
||||
> selbst bestätigen (Memory `proceed-autonomously`, `wire-dont-stub`, `prefer-agents`).
|
||||
|
||||
Dieses Dokument hat drei Teile:
|
||||
1. **Was schon steht** (worauf du aufbaust — exakte Dateien/Typen/Actions).
|
||||
2. **Rhino-Referenz** (Interaktionsmodell, das nachzubilden ist).
|
||||
3. **Konkreter Bauplan für DIESE Codebase** (Architektur, Dateien, Reihenfolge).
|
||||
|
||||
---
|
||||
|
||||
## TL;DR — die Kernidee
|
||||
|
||||
Es gibt **kein** Befehlssystem, keine Command-Line, keinen Tab-Handler. Das baust du
|
||||
greenfield. **Aber:** Das Werkzeug-System ist bereits eine saubere Pure-Function-Registry
|
||||
(`src/tools/`) mit generischem Controller in `App.tsx`, und die Mutations-Schicht
|
||||
(`projectSlice`) ist umfassend. Ein neues Modellier-Tool steckst du durch Hinzufügen eines
|
||||
`Tool`-Objekts ein — **PlanView muss dafür nicht angefasst werden**.
|
||||
|
||||
Das Befehlssystem ist im Kern eine **State-Machine-Engine über prompt → pick/type →
|
||||
options**, plus eine **Command-Line-UI** (Statusleiste), plus ein **Koordinaten-Parser**.
|
||||
Befehle dispatchen auf bestehende Store-Actions + `setActiveTool`/`setProject`.
|
||||
|
||||
**Wichtigster konzeptioneller Sprung:** Die heutigen Tools haben je eine *eigene*
|
||||
ad-hoc-Phasenlogik (`onClick`/`onMove`). Rhino-Feel verlangt eine **gemeinsame
|
||||
Prompt/Option/Numerik-Engine**, die alle Befehle teilen. Plane das als Verallgemeinerung
|
||||
des bestehenden `Tool`-Interfaces, nicht als Parallelwelt daneben (sonst zwei Eingabe-Pfade,
|
||||
die divergieren).
|
||||
|
||||
---
|
||||
|
||||
# TEIL 1 — Was schon steht (Baufundament)
|
||||
|
||||
Stack: React 18 + TS + Vite, `three` 0.169 (nur 3D-Display). Einheiten intern **Meter**.
|
||||
Eigener winziger Store (`useSyncExternalStore`, kein Redux/Zustand). Identifier englisch,
|
||||
UI-Text deutsch via `t()`. Strict tsc (`noUnusedLocals` → ungenutzte Vars brechen den Build).
|
||||
|
||||
## 1.1 Werkzeug-System — `src/tools/`
|
||||
- **`Tool`-Interface** `src/tools/types.ts:139` — reine Funktionen über internen `ToolState`
|
||||
(Discriminated Union je Tool). Handler geben `[nextState, ToolResult]` zurück. Tools
|
||||
schreiben NIE Plan-Primitive; sie geben `commit(project) => project` zurück.
|
||||
- `ToolId` `types.ts:11`: `"select" | "wall" | "line" | "polyline" | "rect"`.
|
||||
- `ToolContext` `types.ts:72`: `{ project, level, defaultCategoryCode, activeWallTypeId, activeLineStyleId }`.
|
||||
- `ToolPointer` `types.ts:85`: `{ raw, snap, point (=snap?.point ?? raw), shift, ctrl, alt, button }`.
|
||||
- `ToolResult` `types.ts:121`: `{ draft, commit?, done? }`. `ToolDraft` `types.ts:109`:
|
||||
`{ preview: DraftShape[], vertices: Vec2[], snap?, hud?: {at,text} }`.
|
||||
- **Registry** `src/tools/tools.ts:375`: `TOOLS: Record<ToolId,Tool>`, `getTool(id)` `:384`,
|
||||
`TOOL_ORDER` `:389`. Implementiert: select (Platzhalter), wall, line, polyline, rect.
|
||||
- `uniqueId(prefix)` `types.ts:188` — ID-Generator.
|
||||
|
||||
## 1.2 Controller / Verdrahtung — alles in `App.tsx` (NICHT in den Tool-Dateien)
|
||||
- Aktives Tool: `const [activeTool,setActiveTool]=useState<ToolId>("select")` `App.tsx:197`.
|
||||
- Laufender Zustand in **Ref** `toolStateRef` `App.tsx:205` (kein Re-Render je Mausschritt).
|
||||
Live-Vorschau `const [draft,setDraft]` `App.tsx:206`.
|
||||
- **Controller** `runToolStep(kind,raw,pxPerMeter,mods)` `App.tsx:350`: baut `ToolContext`
|
||||
(`toolCtx` `:294`), snappt via `snapFor` `:322` (→ `computeSnap`), baut `ToolPointer`,
|
||||
ruft `tool.onClick/onMove`, speichert State in Ref, `applyToolResult` `:339` wendet
|
||||
draft/commit/done an. `toolHandlers` `App.tsx:419` verbindet PlanView↔Controller.
|
||||
- Tool-Tasten `App.tsx:448`: Esc=Abbruch/zurück-zu-select, Enter=Commit-Geste, Backspace=Punkt zurück.
|
||||
|
||||
## 1.3 Semantisches Modell — `src/model/types.ts`
|
||||
- `type Element = Wall | Door | Drawing2D` `:251`. `Vec2={x,y}`. **Kein Slab/Stair-Typ.**
|
||||
- `Project` `:254`: `{ ..., wallTypes[], drawingLevels[], layers[], walls[], doors[], drawings2d[] }`.
|
||||
- `Wall` `:150`: `{ id,type:"wall", floorId, categoryCode, start, end, wallTypeId, height, color? }`
|
||||
(Mittellinie + mehrschichtiger `WallType`).
|
||||
- **Plan-Primitive `Drawing2DGeom`** `:200` — die Geom-Typen existieren bereits ALLE:
|
||||
`line | polyline | rect | circle | arc | text`. Aber Tools erzeugen heute nur line/polyline/rect,
|
||||
und `drawingVertices` (Grips) kennt nur diese drei. **circle/arc/text sind im Typ da, aber
|
||||
nicht durchgängig gerendert/editierbar** — Lücke, kein Neubau nötig.
|
||||
- `Drawing2D` `:209`: `{ id,type:"drawing2d", levelId, categoryCode, geom, lineStyleId?, hatchId?, color?, fillColor?, weightMm? }`.
|
||||
|
||||
## 1.4 Geometrie — `src/model/geometry.ts`
|
||||
`sub,add,scale,len,normalize`; `leftNormal(a)={x:-a.y,y:a.x}` `:17` (Wand-Normale-Konvention);
|
||||
`cross`, `lineIntersect(a,da,b,db)`, `along`, `wallBand`, `wallCorners` `:70`, `clippedBand` `:87`.
|
||||
`src/model/joins.ts`: `computeJoins(project,walls)` `:44` (nur L-Ecken gehrt; T/X eckig).
|
||||
**Für Offset/Trim/Fillet (Rhino-Kern) gibt es NOCH KEIN 2D-Geometrie-Kernel** — Kurven/Kurven-
|
||||
Schnitt, Polylinien-Offset usw. musst du ergänzen (siehe Bauplan §3.4).
|
||||
|
||||
## 1.5 Store — `src/state/`
|
||||
- `createStore` `store.ts:51` über `useSyncExternalStore`. **Actions leben IM State**
|
||||
(`useStore(s=>s.action)`, referenzstabil). `RootState = Project & Selection & View & Layout`
|
||||
`appStore.ts:21`. Exports `useStore`, `getState`, `setState`.
|
||||
- **projectSlice**: `project` + `setProject(next|(p)=>p)`. Mutationen u.a. `addFloor`,
|
||||
`addCategory`, `setElementColor/Weight/Fill`, `resizeElement`, `moveGripOf`, `moveElementByOf`,
|
||||
`moveEdgeOf`, `commitTransformOn`. **Es gibt keine generische „addWall/addDrawing2d"-Action** —
|
||||
Tools committen via `setProject`. (Beim Befehlssystem ggf. saubere Actions ergänzen.)
|
||||
- **Aktive Zeichenebene + aktive Kategorie liegen im viewSlice**, NICHT in selection:
|
||||
`activeLevelId` `viewSlice.ts:46`/`setActiveLevelId`, `activeCategoryCode` `:42`/`setActiveCategoryCode`.
|
||||
- selectionSlice: `selectedWallIds[]`, `selectedDrawingId` + Setter/`clearSelection`.
|
||||
|
||||
## 1.6 Views, Eingabe, Koordinaten — `src/plan/PlanView.tsx` (SVG-Vektor)
|
||||
- Modell → `Plan`-Primitive via `generatePlan` `src/plan/generatePlan.ts:203`. `Primitive` =
|
||||
`polygon|line|arc` (polygons tragen `wallId`/`drawingId` für Hit-Test).
|
||||
- **Transform (entscheidend):** `PX_PER_M=90` `:20`; `toScreen(p)={x:p.x*90,y:-p.y*90}` `:31`
|
||||
(fixer Welt-Ursprung 0,0; Y flippt). Invers `viewToModel` `:440`. SVG `viewBox`=State `view`;
|
||||
Pan/Zoom ändern nur `view`, nie das Modell↔Screen-Mapping.
|
||||
- **`rawModelAt(clientX,clientY)`** `:446` = aktuelle Mauswelt-Position in Meter (der Eine-Aufruf,
|
||||
den ein Tool/Befehl braucht). `currentPxPerMeter()` `:488`.
|
||||
- **Pointer-Events** alle am `<svg>` `:910`: down `:553`, move `:625`, up `:715`, wheel `:820`,
|
||||
dblclick `:847`, contextmenu `:857`. Schema: Mitte=Pan, Links=Select/Marquee/Tool, Rechts=Menü.
|
||||
Bei `toolActive` `:268` routen Links-Events zu `toolHandlers`. **PlanView meldet bereits
|
||||
`(rawModelAt, currentPxPerMeter, toolMods)` nach oben** — neue Tools brauchen hier NICHTS.
|
||||
- **Snapping** `src/tools/snapping.ts`: `computeSnap(input)` `:88` — endpoint/midpoint/intersection/
|
||||
onEdge/grid/ortho mit Prioritätstabelle. Wird in App (`snapFor`) konsumiert, nicht in PlanView.
|
||||
`applyAngleConstraint` für Ortho. `SnapSettings`/`DEFAULT_SNAP` in `tools/types.ts:36/55`.
|
||||
- 3D `src/viewport/Viewport3D.tsx` (three.js, Raycaster): nur Anzeige+Auswahl, **keine
|
||||
Zeichenwerkzeuge**. 3D-Authoring = eigene spätere Phase (Raycast auf Arbeitsebene).
|
||||
|
||||
## 1.7 Tastatur / globale Eingabe — **kein Dispatch-System**
|
||||
- `main.tsx:38` globaler `contextmenu`→preventDefault; `:42` blockt Ctrl/Cmd+A außerhalb Inputs;
|
||||
`isTextEntry(el)` `:24`.
|
||||
- App-useEffects mit `window.addEventListener("keydown")`: Tool-Tasten `:448`, Delete `:604`,
|
||||
Transform-Shortcuts m/s/d + u/i/o/p `:637`. **Jeder Guard wiederholt inline den
|
||||
INPUT/TEXTAREA/contentEditable-Check** — es gibt keine geteilte Keymap. Dein Tab-Handler +
|
||||
Command-Input kommt als neuer globaler `keydown` dazu (siehe §3.2).
|
||||
|
||||
## 1.8 UI-Shell + i18n
|
||||
- `App.tsx` (~2200 Z., enthält noch ToolController/Grips/Transform). JSX `:1043`: TopBar → body
|
||||
(Dock links, Content-View-Router, TransformBar, Dock rechts, Floating) → StatusBar →
|
||||
ResourceManager → ContextMenu → InlineEditor. Panel-Daten via `PanelHostContext` (`baseHost`
|
||||
`App.tsx:729`, Typ `host.ts`).
|
||||
- `StatusBar.tsx` — Footer: links `hint` (Tool-Hinweis), rechts X/Y, Einheit, Massstab 1:N, Zoom,
|
||||
aktives Geschoss, aktive Ebene. **Bester Ort für die Command-Line** (Rhino hat sie klassisch unten).
|
||||
- **i18n** `src/i18n/`: `t(key,params?)` `index.ts:67`, `useT()` `:84`. Flaches `as const`-Dict,
|
||||
Punkt-Namespaces (`tool.*`,`snap.*`,`transform.*`,`status.*`…). `de.ts` (Quelle, ~309 Keys) +
|
||||
`en.ts`; `TranslationKey=keyof typeof de` erzwingt Parität. **Neue Keys IMMER in beide Dateien.**
|
||||
Keine hartcodierten JSX-Strings.
|
||||
|
||||
## 1.9 Verifizieren
|
||||
- `npx tsc -b` · `npm run build` · Dev `npm run dev` (Vite 5173, `host:true`).
|
||||
- Screenshot `node scripts/probe.mjs` → `scripts/probe.png` (Puppeteer headless, `deviceScaleFactor:2`,
|
||||
URL via `PROBE_URL`). Viele task-Probes existieren (`probe-tools.mjs`, `probe-line.mjs`,
|
||||
`probe-transform.mjs` …) — gute Vorlagen, um Tools/Befehle programmatisch zu treiben.
|
||||
**Screenshot ansehen + Geometrie prüfen**, nicht nur „kompiliert".
|
||||
|
||||
---
|
||||
|
||||
# TEIL 2 — Rhino-Referenz (das Interaktionsmodell)
|
||||
|
||||
## 2.1 Die Command-Line ist das Rückgrat
|
||||
**Alles ist ein Befehl**, und die Command-Line **hört immer zu**: Tastenanschläge gehen an die
|
||||
Command-Line, wenn sie nicht von einem Feld konsumiert werden. Kein „Tool aktiv vs. Eingabe aktiv".
|
||||
Die Zeile hat gleichzeitig drei Rollen: **Eingabe** (Befehl/Wert tippen), **Prompt**
|
||||
(„Start of line", „Next point"), **Optionen** (eckige, klickbare Inline-Optionen).
|
||||
|
||||
## 2.2 Befehl aufrufen
|
||||
- Namen tippen, z. B. `Line`. **Präfix-Autocomplete** (case-insensitiv): `L`→`Li`→`Lin` zeigt
|
||||
Kandidatenliste mit Best-Match. **Tab/Pfeile** akzeptieren Vorschlag, **Enter/Leertaste** führt aus.
|
||||
- **Aliase**: nutzerdefinierte Kürzel → Makro (z. B. `L`→`!_Line`, `cp`→`!_Copy`). Werden VOR
|
||||
Autocomplete gematcht. (Minimal: Einzelbuchstabe→Befehl.)
|
||||
|
||||
## 2.3 Enter / Leertaste / Rechtsklick (leicht falsch gemacht)
|
||||
- **Enter = Leertaste** in der Command-Line. Beide: Befehl ausführen / Default akzeptieren /
|
||||
mehrteiligen Befehl **beenden** / bei **leerer** Zeile **letzten Befehl wiederholen**.
|
||||
- **Rechtsklick im Viewport = Enter.** Also: Rechtsklick beendet Polyline UND wiederholt bei
|
||||
leerer Zeile den letzten Befehl. → `lastCommand` speichern, bei Leer-Enter/Rechtsklick neu starten.
|
||||
|
||||
## 2.4 Inline-Optionen (klickbare Klammern)
|
||||
```
|
||||
Start of line ( BothSides=No Chamfer Mode=Distance ):
|
||||
```
|
||||
- Jede Option **klickbar UND tippbar** (genug Buchstaben zur Eindeutigkeit + Enter).
|
||||
- **Toggle** `Name=Value` flippt beim Klick. **Value**-Option fragt Unterwert ab. **Action**-Option
|
||||
(ohne `=`) verzweigt sofort.
|
||||
- Optionen sind **innerhalb des Befehls persistent**, viele **über Aufrufe hinweg** (letzte
|
||||
Offset-Distanz, Array-Anzahl, Fillet-Radius merken). **Zuletzt benutzte Optionswerte je Befehl
|
||||
persistieren** — Nutzer erwarten das.
|
||||
|
||||
## 2.5 Sub-Prompts = State-Machine
|
||||
Befehle laufen Prompts ab. `Line`: „Start of line:" → Punkt → „End of line:" → Punkt → fertig.
|
||||
`Polyline`: „Start" → „Next point ( Close Undo ):" → … → **Enter** beendet. Prompt-Text ist
|
||||
sichtbar und lehrreich („Next point. Press Enter when done") — literal nachbilden.
|
||||
|
||||
## 2.6 Transparente/verschachtelbare Befehle
|
||||
Manche Befehle (Zoom/Pan, Osnap-Toggle, alles mit `'`-Präfix) laufen **innerhalb** eines anderen,
|
||||
ohne ihn abzubrechen, und kehren zum Original-Prompt zurück. → Command-Runner braucht einen **Stack**.
|
||||
|
||||
## 2.7 Koordinaten- & Numerik-Eingabe (Herz der Präzision)
|
||||
| Eingabe | Bedeutung |
|
||||
|---|---|
|
||||
| `5,3` / `5,3,2` | absolut X,Y(,Z) |
|
||||
| `r5,3` | **relativ** zum letzten Punkt (das `r`-Idiom) |
|
||||
| `<45` | Winkel-Constraint auf 45°, dann Maus/Distanz |
|
||||
| `5<45` | **polar**: Distanz 5 unter 45° vom letzten Punkt |
|
||||
| Zahl tippen während Drag | **Distanz-Lock**: Richtung per Maus, Länge per Zahl+Enter (meistgenutzte Geste) |
|
||||
| Zahl + **Tab** | Lock umschalten (Länge fix → Winkel folgt Maus, oder umgekehrt) |
|
||||
Das Feld parst **kontextabhängig**: Befehlsname / Optionsbuchstabe / Koordinate / nackte Zahl —
|
||||
je nach Befehlszustand. Das Live-Tool muss **einen primären Skalar** (Länge/Radius/Distanz)
|
||||
exponieren, an den eine getippte Zahl bindet.
|
||||
|
||||
## 2.8 Osnaps + Ortho + Gumball
|
||||
- **Osnaps** (persistente Toggles): End, Mid, Cen, Int, Perp, Near, Quad, Tan, Point. Pro Mausschritt
|
||||
gegen nahe Geometrie geprüft (Pixel-Toleranz), Marker+Label am Cursor; liefert **exakte
|
||||
Modellkoordinate** (nie Roh-Maus, wenn Snap aktiv). One-Shot-Osnap überschreibt für den nächsten Pick.
|
||||
- **Ortho** (F8): Winkelraster (90°/konfigurierbar), **Shift** togglet temporär. **Grid Snap** (F9).
|
||||
**SmartTrack**: temporäre Hilfslinien aus zuletzt gehoverten Punkten.
|
||||
- **Gumball**: On-Object-Widget (Pfeile=Move, Bögen=Rotate, Handles=Scale); Handle klicken →
|
||||
Zahl tippen für exakten Transform. Direkt-Manipulations-Gegenstück zu getippten Befehlen.
|
||||
|
||||
> Präzisionsmodell = **(Snap ODER getippte Koordinate) × (Ortho/Winkel-Constraint) ×
|
||||
> (Distanz-Constraint)**, in EINEM Pick komponierbar.
|
||||
|
||||
## 2.9 Auswahl-Modell (links/rechts-Regel exakt)
|
||||
- Klick = wählen; Shift+Klick add; Ctrl+Klick remove.
|
||||
- **Links→rechts = Window** (nur voll umschlossene; **durchgezogenes** Rechteck).
|
||||
- **Rechts→links = Crossing** (auch berührte; **gestricheltes** Rechteck). Richtung bestimmt
|
||||
Modus — starke Konvention, exakt nachbilden.
|
||||
- **SelLast** (zuletzt erzeugte/gewählte erneut wählen) ist enorm nützlich („erzeugen, dann sofort
|
||||
bewegen"). Min. `SelLast`, `SelAll`, `SelNone`, `Invert`.
|
||||
|
||||
## 2.10 Befehls-Prompt-Sequenzen (Kurz)
|
||||
2D: **Line** (2 Pkt) · **Polyline** (Close/Undo, Enter beendet) · **Rectangle** (Ecke+Ecke, oder
|
||||
Breite/Höhe tippen; 3Point/Center) · **Circle** (Center+Radius; 2P/3P/Tan) · **Arc** (Center-Start-End /
|
||||
3Point) · **Offset** (Kurve wählen → Seite klicken/Distanz tippen; Distanz persistent) ·
|
||||
**Fillet/Chamfer** (Kurve1→Kurve2, Radius/Distances persistent) · **Trim** (Schneider wählen→Enter→
|
||||
wegzuschneidendes Stück klicken) · **Split** · **Extend** · **Join** · **Explode** ·
|
||||
**Move/Copy/Rotate/Scale/Mirror** (Auswahl→Basispunkt→Ziel; Copy-Option) · **ArrayRect/ArrayPolar** ·
|
||||
**Group/Ungroup**.
|
||||
3D (braucht CSG, später): **ExtrudeCrv** (geschlossene Kurve→Solid, Cap) · **Box** · **Boolean
|
||||
Union/Difference/Intersection** · **Cap** · **Gumball-Face-Drag = PushPull** · Loft/Sweep/Revolve.
|
||||
|
||||
---
|
||||
|
||||
# TEIL 3 — Bauplan für DIESE Codebase
|
||||
|
||||
> Ziel: nutzbarer 2D-Architektur-Drafter mit Rhino-Feel, dann einfaches Massing. Halte das
|
||||
> ROADMAP-Prinzip: **ein semantisches Modell → Sichten abgeleitet**; Extrusionshöhe ist eine
|
||||
> Eigenschaft, nie eingebackene Geometrie.
|
||||
|
||||
## 3.0 Kuratierungs-Prinzip (WICHTIG — Nutzer-Vorgabe)
|
||||
**NICHT den ganzen Rhino-Katalog stumpf portieren.** Wir bauen ein **Wohnbau-BIM**, keinen
|
||||
NURBS-Allzweck-Modeller. Nimm nur, was dem Wohnbau-Workflow dient; lass den Rest weg, bis er
|
||||
konkret gebraucht wird. Faustregel: *Brauche ich das, um ein Einfamilienhaus zu zeichnen und
|
||||
daraus Pläne zu ziehen?* Wenn nein → weglassen.
|
||||
|
||||
**Bewusst WEGLASSEN (vorerst):** Loft / Sweep1+2 / Revolve (Sonderformen, kaum Wohnbau) ·
|
||||
freie NURBS-Kurven (`Curve`/`InterpCrv` Grad>1, Deformable, FromFoci) · Ellipse · Tangent/
|
||||
Bisector/4Point-Linienvarianten · SmartTrack (nett, nicht kritisch) · der volle `Sel*`-Zoo
|
||||
(nur SelLast/SelAll/SelNone/Invert) · Knot/Vertex/Tan-Osnaps. Alle leicht später additiv
|
||||
nachrüstbar — kein Grund, sie jetzt mitzuschleppen.
|
||||
|
||||
**Booleans sind KEIN „nice to have später"** — sie werden gebraucht, **sobald Tür/Fenster als
|
||||
echte 3D-Öffnung** kommen (heute schneidet `Door` nur eine Plan-Lücke, kein 3D-Boolean, siehe
|
||||
HANDOVER). Darum: CSG/Booleans an die **Tür/Fenster-Phase koppeln** und dann reinnehmen — nicht
|
||||
ans Ende schieben. ABER (das ist der „nicht stumpf"-Teil):
|
||||
> Für **rechteckige** Öffnungen in extrudierten Wänden braucht es **keinen allgemeinen
|
||||
> Boolean-Kernel**. Eine analytische **Wand-minus-Box-Subtraktion** (Öffnung als parametrische
|
||||
> Aussparung im Wand-Solid) ist einfacher, robuster und für 95 % Wohnbau ausreichend. Den
|
||||
> allgemeinen CSG-Boolean (`rhino3dm`) erst ziehen, wenn schräge/runde/verschnittene Fälle
|
||||
> wirklich auftreten. Also: **Öffnungen zuerst analytisch, allgemeine Booleans erst bei Bedarf.**
|
||||
|
||||
## 3.1 Leitentscheidung: Engine verallgemeinern, nicht parallel bauen
|
||||
Baue eine gemeinsame **Command-Engine**, die das bestehende `Tool`-Interface erweitert/ablöst,
|
||||
sodass es **einen** Eingabepfad gibt (Maus + Tastatur + Command-Line speisen dieselbe Maschine).
|
||||
Konkret: ein `Command`-Modell, das je Schritt einen **Prompt** (Text), erwartete **Eingabearten**
|
||||
(Punkt | Zahl | Option | Auswahl) und **Optionen** beschreibt. Die heutigen Tools werden zu
|
||||
Befehlen dieser Engine (wall/line/polyline/rect lassen sich 1:1 portieren — ihre Phasenlogik ist
|
||||
schon eine Mini-State-Machine).
|
||||
|
||||
**Warum nicht das alte Tool-Interface unangetastet lassen und Command-Line nur draufsetzen?**
|
||||
Weil die Command-Line getippte Koordinaten/Optionen in denselben Schritt einspeisen muss, in dem
|
||||
die Maus pickt. Zwei getrennte Pfade divergieren garantiert (Snapping, Constraints, HUD doppelt).
|
||||
|
||||
## 3.2 Neue Dateien (Vorschlag)
|
||||
- `src/commands/engine.ts` — Command-Runner: aktiver Befehl, Prompt-Stack (für transparente
|
||||
Befehle §2.6), `lastCommand`-Wiederholung, Routing von Maus-Pick / getippter Eingabe / Option-Klick
|
||||
in den aktuellen Schritt. Hält `CommandState`.
|
||||
- `src/commands/types.ts` — `Command`-Interface (Verallgemeinerung von `Tool`): Schritte mit
|
||||
`prompt: TranslationKey`, `accepts: ("point"|"number"|"option"|"selection")[]`, `options: CmdOption[]`,
|
||||
`onInput(state,input,ctx): [state, CommandResult]`. `CommandResult` wie `ToolResult` (+`commit`).
|
||||
- `src/commands/parseInput.ts` — Koordinaten-Parser (§2.7): `5,3` · `r5,3` · `5<45` · `<45` ·
|
||||
nackte Zahl (Distanz-Lock) · Optionsbuchstabe. Liefert eine Discriminated Union, die die Engine
|
||||
in einen Modellpunkt/Constraint auflöst (mit `lastPoint` für `r`/polar).
|
||||
- `src/commands/registry.ts` — `COMMANDS: Record<string,Command>` + Aliase + Autocomplete (Präfix).
|
||||
- `src/ui/CommandLine.tsx` — die Command-Line-UI **in/über der Statusleiste** (`StatusBar.tsx`):
|
||||
zeigt Prompt + klickbare Optionen + Texteingabe; Autocomplete-Dropdown. Tab fokussiert sie.
|
||||
- (später) `src/geometry/kernel2d.ts` — 2D-Kernel für Offset/Trim/Fillet/Schnitt (§3.4).
|
||||
- (viel später) `src/geometry/solid3d.ts` o. `rhino3dm`-Anbindung für Massing/Booleans (§3.5).
|
||||
|
||||
## 3.3 Verdrahtung (minimal-invasiv)
|
||||
- **Globaler Tab-Handler**: neuer `window.keydown` in App (gleicher Guard wie `App.tsx:448` —
|
||||
INPUT/TEXTAREA/contentEditable überspringen). Tab → Command-Line fokussieren/öffnen. Jeder
|
||||
getippte Buchstabe ohne aktives Tool startet den Befehlsmodus (Rhino „hört immer zu" — optional
|
||||
in Phase 2; Phase 1 reicht Tab).
|
||||
- **Command-Line → Engine → Store**: Befehle dispatchen auf `setActiveTool` (für tool-artige) bzw.
|
||||
direkt auf Store-Actions / `setProject`. Nutze `getState()/setState()` (referenzstabil) aus
|
||||
`appStore.ts`.
|
||||
- **Pick-Eingabe**: die Engine konsumiert dieselben `(rawModelAt, currentPxPerMeter, toolMods)`,
|
||||
die PlanView schon hochmeldet (`ToolHandlers`). `computeSnap` für Punktfang wiederverwenden.
|
||||
→ PlanView braucht im Idealfall **keine Änderung** (höchstens: Window/Crossing-Marquee-Visual
|
||||
durchgezogen vs. gestrichelt nach Drag-Richtung, §2.9 — heute evtl. nur ein Modus).
|
||||
- **Prompt/HUD**: Prompt-Text in die Statusleiste (`StatusBar` `hint` existiert schon). Distanz/
|
||||
Winkel-HUD am Cursor existiert in `ToolDraft.hud`.
|
||||
|
||||
## 3.4 Reihenfolge (Tiers — strikt 2D zuerst)
|
||||
**Tier 0 — Substrat (VOR jedem Befehl; das ist der „Feel"):**
|
||||
1. Command-Runner + Command-Line-UI (Prompt → pick/type → Optionen; Enter/Space/Rechtsklick =
|
||||
bestätigen/beenden/wiederholen; `lastCommand`).
|
||||
2. Koordinaten-Parser (`x,y` · `rdx,dy` · `dist<angle` · nackte-Zahl-Lock).
|
||||
3. Osnaps (End/Mid/Cen/Int/Perp/Near) — `computeSnap` ist da, ggf. Cen/Perp/Near ergänzen.
|
||||
4. Ortho (90°/45°, Shift-Toggle) + Grid-Snap — teils vorhanden (`applyAngleConstraint`).
|
||||
5. Auswahl: Klick, Shift/Ctrl add/remove, **Window vs. Crossing** (durchgezogen/gestrichelt,
|
||||
links/rechts-Regel).
|
||||
|
||||
**Tier 1 — 2D-Pflicht (reines SVG/2D), grobe Baufolge:**
|
||||
6. **Line** (validiert die ganze pick/snap/constrain-Schleife) → 7. **Polyline** (Close/Undo) →
|
||||
8. **Rectangle** (Ecke + Center/3Point) → 9. **Circle** (Center+Radius). Diese vier portieren die
|
||||
heutigen Tools auf die Engine + numerische Eingabe.
|
||||
10. **Move** → 11. **Copy** (wiederholend) → 12. **Offset** (persistente Distanz — DAS Architektur-
|
||||
Primitiv) → 13. **Trim** + **Split** → 14. **Join** + **Explode**. **Undo/Redo** durchgängig
|
||||
annehmen (heute? — prüfen; ggf. Command-History/Undo-Stack im Store ergänzen).
|
||||
|
||||
**Tier 2 — 2D stark nützlich:** Rotate/Scale/Mirror (Copy-Option) · Fillet/Chamfer · Arc ·
|
||||
Extend · ArrayRect/ArrayPolar · Group/Ungroup · Gumball(2D) · Sel*-Helfer (min. SelLast).
|
||||
|
||||
**Tier 3 — Massing + Öffnungen (an Tür/Fenster-Phase gekoppelt):**
|
||||
- **Öffnungen zuerst analytisch:** Tür/Fenster als parametrische Aussparung im Wand-Solid
|
||||
(Wand-Extrude minus Öffnungs-Box) — KEIN allgemeiner Boolean-Kernel nötig (§3.0). Das ist der
|
||||
kritische, roadmap-markierte 🔴-Teil (echte 3D-Öffnung statt nur Plan-Lücke) und kommt MIT
|
||||
Tür/Fenster, nicht danach.
|
||||
- **Massing-Befehle:** ExtrudeCrv (geschlossene Plan-Kurve → gecapptes Solid) → Box →
|
||||
Gumball-Face-Drag-PushPull.
|
||||
- **Allgemeine Booleans** (Union/Difference/Intersection) **erst bei Bedarf** (schräge/runde/
|
||||
verschnittene Fälle): **kein eigener Kernel — `rhino3dm` (WASM-openNURBS)** als `src/io/`-Schicht
|
||||
(Roadmap-Entscheid, HANDOVER). Bis dahin reicht die analytische Subtraktion.
|
||||
- **Weggelassen:** Loft/Sweep/Revolve/OffsetSrf (§3.0 — Sonderformen, kaum Wohnbau).
|
||||
|
||||
## 3.5 Was sauber 2D ist vs. was hart ist
|
||||
- **Sauber SVG/2D:** Line, Polyline, Rect, Circle, Arc, Move/Copy/Rotate/Scale/Mirror, Array, Group,
|
||||
Control-Point-Edit, Gumball(2D). Affine Transforms + Kurven-Schnitt.
|
||||
- **Echte Arbeit (2D-Kernel nötig):** **Offset, Trim, Fillet** brauchen kompetenten Kurven-Schnitt
|
||||
und Polylinien-Offset — dafür Zeit einplanen (`src/geometry/kernel2d.ts`).
|
||||
- **Braucht 3D/CSG:** Extrude, Box, Boolean*, Cap, OffsetSrf, Loft/Sweep/Revolve, Face-Drag. Booleans
|
||||
sind das Korrektheits-Zentrum → `rhino3dm`.
|
||||
|
||||
## 3.6 Gotchas (aus Rhino-Verhalten + dieser Codebase)
|
||||
- **Command-Line hört immer zu** — Tasten global routen, aber die `isTextEntry`-Disziplin
|
||||
(`main.tsx:24`) + die Native-App-Regeln (kein Ctrl+A/keine Textauswahl, CONVENTIONS.md) wahren.
|
||||
- **Zuletzt benutzte Optionswerte je Befehl persistieren** (Offset-Distanz, Array-Anzahl, Fillet-Radius).
|
||||
- **Enter = Rechtsklick = Wiederholen/Bestätigen/Mehrteiliges-Beenden** — alle drei auf EIN Signal.
|
||||
- **Distanz-Lock:** Live-Befehl muss EINEN primären Skalar exponieren, an den eine getippte Zahl bindet.
|
||||
- **Window vs. Crossing** über Drag-Richtung + durchgezogen/gestrichelt — nicht global ein Modus.
|
||||
- **Osnap liefert exakte Modellkoordinate** — nie Roh-Maus, wenn Snap aktiv (`ToolPointer.point`).
|
||||
- **Strict tsc** (`noUnusedLocals`) — ungenutzte Vars/Parameter brechen `npm run build`.
|
||||
- **i18n**: jeder sichtbare String über `t('key')`, Keys in `de.ts` UND `en.ts` (Parität erzwungen).
|
||||
- **Keine generische addWall/addDrawing2d-Action** — entweder via `setProject` committen (wie heute)
|
||||
oder beim Refactor saubere Actions im `projectSlice` ergänzen (besser für Undo/Redo).
|
||||
- **App.tsx ist bereits ~2200 Z.** (God-Component-Kritik in HANDOVER). Lege Command-Engine in
|
||||
`src/commands/`, halte App-Verdrahtung dünn (nur Tab-Handler + CommandLine-Mount + Dispatch-Brücke).
|
||||
|
||||
## 3.7 Verifikations-Drehbuch
|
||||
Pro Tier eine Probe (Vorlage: `scripts/probe-tools.mjs`/`probe-transform.mjs`): Befehl per Command-
|
||||
Line tippen → Punkte/Werte tippen → Screenshot → Geometrie visuell prüfen. Tier 0 zuerst headless
|
||||
treiben (Tab → „line" → „0,0" Enter → „r3,0" Enter → Linie im PNG sichtbar). `npx tsc -b` +
|
||||
`npm run build` grün halten. **Screenshot ansehen**, nicht nur Kompilat vertrauen (Memory `wire-dont-stub`).
|
||||
|
||||
---
|
||||
|
||||
## Anhang — Minimaler erster Meilenstein (konkret)
|
||||
1. `src/commands/types.ts` + `engine.ts` + `parseInput.ts` (Tier 0.1/0.2).
|
||||
2. `src/ui/CommandLine.tsx`, in `StatusBar` gemountet; Tab-Handler in App.
|
||||
3. `Line` als erster Command (portiert `lineTool`), inkl. getippter `0,0` / `r3,0` / `3<45`.
|
||||
4. Probe `scripts/probe-command-line.mjs`: Tab→line→zwei getippte Koordinaten→PNG prüfen.
|
||||
5. Dann Polyline/Rect/Circle, danach Move/Copy/Offset.
|
||||
|
||||
Damit steht der Rhino-Feel-Kern, und jeder weitere Befehl ist additiv (neues `Command`-Objekt in
|
||||
`registry.ts`, keine PlanView-/App-Änderung).
|
||||
@@ -0,0 +1,52 @@
|
||||
# Zustands-Architektur & Code-Aufteilung (App.tsx entschlacken)
|
||||
|
||||
> Ziel: `App.tsx` von „God-Component" zu dünnem Shell. Globaler Zustand in einen
|
||||
> Store, Features in eigene Module → **wartbar + parallel bearbeitbar**.
|
||||
|
||||
## Problem
|
||||
`App.tsx` hält aktuell: Projekt-State, Auswahl, View-State (viewType/detailLevel/
|
||||
renderMode/referenceLines/scale/activeLevel), Layout, ALLE Mutations-Handler
|
||||
(floors/layers/components/hatches/lineStyles/walls/doors), Kontextmenü-Builder,
|
||||
Inline-Editoren, Layout-Menü, View-Routing. → Risiko + Flaschenhals (jedes Feature
|
||||
fasst App.tsx an → kein paralleles Arbeiten).
|
||||
|
||||
## Zielstruktur
|
||||
```
|
||||
src/state/
|
||||
store.ts // Store (Zustand) — kombiniert die Slices, ein useStore-Hook
|
||||
projectSlice.ts // project + alle Mutationen (floors, layers, components,
|
||||
// hatches, lineStyles, walls, doors) inkl. recompute/refs-aware delete
|
||||
selectionSlice.ts // selectedWallIds (+ marquee-Ergebnis)
|
||||
viewSlice.ts // viewType, detailLevel, renderMode, referenceLines, activeLevelId, scale
|
||||
layoutSlice.ts // wraps src/panels/layout.ts (docks + floating)
|
||||
src/views/ // LevelPlanView, PerspectiveView, SectionStub, DrawingView (+ ViewRouter)
|
||||
src/editors/ // FloorSettingsEditor, LayerSettingsEditor, … (heute inline in App)
|
||||
src/menus/ // layerContextMenu(), levelContextMenu(), planContextMenu() — bauen ContextMenu-Items
|
||||
src/ui/ // TopBar, StatusBar, ResourceManager, ContextMenu (bestehen)
|
||||
src/panels/ // Docks/Panels (bestehen)
|
||||
App.tsx // DÜNN: Store-Provider · TopBar · (Docks + ViewRouter) · StatusBar
|
||||
// · Floating-Panels · Ressourcen-Overlay
|
||||
```
|
||||
|
||||
## Store-Wahl: Zustand (empfohlen)
|
||||
- Winzige Lib, kein Boilerplate, **Slices** gut teilbar, Selektoren verhindern
|
||||
Re-Render-Sturm, kein Prop-Drilling. Passt zu „verschiedene Features = verschiedene
|
||||
Slice-Dateien" → Parallelität.
|
||||
- Alternative ohne Dependency: Context + useReducer oder `useSyncExternalStore`
|
||||
(wie i18n). Mehr Boilerplate; bei der State-Menge ist Zustand ergonomischer.
|
||||
- Komponenten: `const walls = useStore(s => s.walls)` / `useStore(s => s.addFloor)`.
|
||||
PanelHostContext entfällt (Panels lesen direkt aus dem Store).
|
||||
|
||||
## Vorgehen (reiner Refactor — Verhalten MUSS identisch bleiben)
|
||||
1. Store + Slices anlegen, Projekt-State + Mutationen aus App.tsx hierher ziehen
|
||||
(1:1, gleiche Logik inkl. recomputeFloorElevations, refs-aware delete).
|
||||
2. View-/Selection-/Layout-State in ihre Slices.
|
||||
3. Inline-Editoren, Kontextmenü-Builder, View-Routing in `src/editors/`,`src/menus/`,`src/views/` extrahieren; sie lesen den Store.
|
||||
4. App.tsx auf den Shell reduzieren.
|
||||
5. Verifizieren: tsc + build + Screenshots — **pixel-/funktionsgleich** zu vorher
|
||||
(Auswahl, Massstab, Kontextmenü, Panels, 3D/Plan, i18n). Reiner Umbau, kein
|
||||
Feature-Wechsel.
|
||||
|
||||
## Auszahlung
|
||||
- Danach editiert ein Wand-Feature `projectSlice`/`views`, ein Panel-Feature `panels`,
|
||||
ein Editor `editors` — **disjunkte Dateien → mehrere Code-Workflows parallel** möglich.
|
||||
@@ -0,0 +1,43 @@
|
||||
# Top-Bar (Oberleiste) & Footer/Status-Leiste — Design
|
||||
|
||||
> Referenz: DOSSIER `rhino/toolbar.py` + `src/ToolbarApp.jsx`. Hier auf unseren
|
||||
> Standalone-Stack (React+TS, eigenes Modell) übersetzt. DOSSIER hat KEINEN Footer
|
||||
> (delegiert an Rhinos eigene Leiste) — den Footer ergänzen wir neu (Vectorworks-Stil).
|
||||
|
||||
## Top-Bar — Gruppen (links → rechts)
|
||||
|
||||
1. **Marke/Logo** + Settings-Icons (Projekt-Einstellungen, App-Einstellungen).
|
||||
2. **Ansicht** — Umschalter: Grundriss · Perspektive · Schnitt · Ansicht.
|
||||
Später: 3D-Views Top/Iso + Himmelsrichtungen N/O/S/W (mit Nordwinkel-Rotation).
|
||||
3. **Darstellung** — Render-/Anzeigemodus (Wireframe/Shaded/…) + **Detailgrad**
|
||||
(grob/mittel/fein, ≙ DOSSIER „Darstellung" Einfach/Standard/Detail).
|
||||
4. **Massstab & Zoom** — Live-Anzeige „1:N" + Dropdown (1:1,1:5,…,1:1000, frei) +
|
||||
**Plan-Ansicht-Toggle** (Linienstärken für Druck) + Zoom-Buttons: 100% · Einpassen ·
|
||||
Auswahl. Quelle: viewBox-Skala / `dpi = 96·devicePixelRatio` (siehe docs/design/plans-output.md).
|
||||
5. **Overrides** (regelbasiert, Toggle + Preset) · **Masse** (Bemaßungs-Preset) — später.
|
||||
6. **Anordnen (Z-Order)** — nach vorne/hinten (für 2D-Plangrafik) — später.
|
||||
7. **Snapping** — Master-Osnap + Modi (End/Mitte/Schnittpunkt/Lot/Zentrum/Nah) +
|
||||
**Raster** an/aus + **Referenzlinien** (Wandachsen) an/aus — wenn Zeichenwerkzeuge da sind.
|
||||
8. **Text** — Stil/Font/Größe + B/I/U + Ausrichtung + „+" — mit den 2D-Werkzeugen.
|
||||
|
||||
### MVP jetzt (zu vorhandenem Modell)
|
||||
- Ansichts-Umschalter (haben wir, ausbauen) · Detailgrad-Dropdown · **Massstab 1:N +
|
||||
Zoom: Einpassen/Auswahl/100%** · Render-Modus · Referenzlinien-Toggle · Ressourcen.
|
||||
|
||||
## Footer / Status-Leiste (neu, unten, ~22 px)
|
||||
|
||||
`[Werkzeug-Hinweis] … [Cursor X/Y/Z] · [Einheit] · [Massstab 1:N] · [Zoom %] · [Geschoss] · [Ebene] · [Snap] … [Auswahl: n]`
|
||||
|
||||
- **Cursor X/Y/Z** — live aus der Plan-/3D-Position (Plan: aus viewBox-Inverse der Maus).
|
||||
- **Einheit** — m (aus Projekt). **Massstab** 1:N + **Zoom %** — aus der View-Transform.
|
||||
- **Aktives Geschoss** + **aktive Ebene** — aus Selection/State.
|
||||
- **Snap-Status** — aktive Fänge (später). **Auswahl: n** — Anzahl selektierter Objekte.
|
||||
- **Werkzeug-Hinweis** links — kontextueller Text des aktiven Werkzeugs.
|
||||
|
||||
### MVP jetzt
|
||||
- Cursor X/Y (im Grundriss), Einheit, Massstab 1:N, Zoom %, aktives Geschoss + Ebene.
|
||||
Snap/Werkzeug/Auswahl kommen mit den Zeichenwerkzeugen.
|
||||
|
||||
## Anbindung
|
||||
Beide Leisten docken an das Panel-/Dock-Layout an (Top über den Docks, Footer darunter),
|
||||
Inhalte rein aus dem Modell + View-State abgeleitet (keine Sonderzustände).
|
||||
@@ -0,0 +1,636 @@
|
||||
# Design — Prioritätsbasierte mehrschichtige Wand-Verschneidung (T/X)
|
||||
|
||||
> Teil der Standalone-Architektur — siehe [../../ARCHITECTURE.md](../../ARCHITECTURE.md).
|
||||
> Aufbauend auf der bestehenden **L-Ecken-Gehrung** in `src/model/joins.ts`
|
||||
> (`computeJoins`, `miterLine`) und `src/model/geometry.ts` (`clippedBand`,
|
||||
> `lineIntersect`). Plan-Verbraucher: `src/plan/generatePlan.ts` (`addWallPoche`).
|
||||
> Bezeichner **englisch**, Prosa deutsch, Einheiten **Meter**.
|
||||
|
||||
> **Hinweis Referenz:** Die im Auftrag genannte DOSSIER-Datei
|
||||
> `rhino/wand_grips.py` ist in dieser Umgebung **nicht vorhanden** (das einzige
|
||||
> auffindbare `dossier` ist ein Typst-Portfolio, kein Rhino-Plugin). Das Design
|
||||
> stützt sich daher auf (a) den bestehenden Code, (b) die in CONVENTIONS.md/elements.md
|
||||
> festgehaltenen Geometrie-Konventionen und (c) die etablierte Bau-Semantik der
|
||||
> prioritätsbasierten Schichtverschneidung (Vectorworks „Komponenten-Verbindung",
|
||||
> Revit „Layer Priority", ArchiCAD „Composite Priority"). Sobald `wand_grips.py`
|
||||
> verfügbar ist, sollte Abschnitt 7 (Priorität/Backbone) gegen DOSSIERs konkrete
|
||||
> Rangregel abgeglichen werden.
|
||||
|
||||
---
|
||||
|
||||
## 0. Problem & Leitbild
|
||||
|
||||
Heute (`computeJoins`) wird **nur die L-Ecke** behandelt: genau zwei Wandenden
|
||||
treffen sich in einem Knoten, eine gemeinsame **Gehrungslinie** (`miterLine`)
|
||||
schneidet beide Wände sauber. T-/X-Stöße (≥ 3 Enden) bleiben rechtwinklig
|
||||
gekappt (`if (ends.length !== 2) continue;`) — die durchgehende Wand wird von der
|
||||
ankommenden Wand nicht durchdrungen, und die Schichten überlappen sich oder
|
||||
klaffen.
|
||||
|
||||
**Ziel:** An jedem Knoten — L (2 Enden), T (3), X/Kreuz (4+) — soll **jede
|
||||
Schicht jeder Wand** genau bis zu der Fläche reichen, die ihre Verschneidungs-
|
||||
Semantik vorgibt:
|
||||
|
||||
- Die **gemeinsame, höchstpriorisierte Schicht** (Backbone, z. B. Stahlbeton)
|
||||
läuft **durch** den Stoß.
|
||||
- **Niederpriorisierte Schichten** (z. B. Putz, Dämmung) **stoßen** an die nächst-
|
||||
höhere Schicht des Nachbarn und **enden** dort.
|
||||
- Putz **läuft auf jeder Seite** bis zur Betonfläche und endet dort; Putz
|
||||
**überquert nie** den Beton (kanonisches Beispiel, siehe §7.1).
|
||||
|
||||
**Architektur-Prinzip (CONVENTIONS.md):** Das semantische Modell ist die einzige
|
||||
Wahrheit. Die Verschneidung ist eine **reine Ableitung** (`Project + Wall[]` →
|
||||
Trimm-Linien je Schicht-Band), nichts wird in die Geometrie eingebacken. Sie wird
|
||||
beim Generieren des Plans angewandt und ist **deterministisch** und **idempotent**.
|
||||
|
||||
---
|
||||
|
||||
## 1. Geometrie-Konventionen (Wiederholung, verbindlich)
|
||||
|
||||
Aus CONVENTIONS.md und `geometry.ts`:
|
||||
|
||||
- Achsrichtung `u = normalize(end - start)`.
|
||||
- Wand-Normale `n = leftNormal(u) = (-u.y, u.x)`.
|
||||
- Schichten werden **außen → innen** gestapelt: Offset entlang `n` läuft von
|
||||
`-T/2` (linke/„außen"-Kante) nach `+T/2` (rechte/„innen"-Kante). Eine Schicht `k`
|
||||
belegt das Intervall `[off_k, off_k + thickness_k]` mit `off_0 = -T/2`.
|
||||
- Eine **unendliche Gerade** ist `Line { point, dir }`; Schnittpunkt zweier
|
||||
Geraden via `lineIntersect(a, da, b, db)` (null bei parallel).
|
||||
- Ein Schicht-**Band** zwischen Offsets `offA, offB` wird über `clippedBand(start,
|
||||
end, offA, offB, startCut, endCut)` gebildet; jede Bandlängskante wird mit einer
|
||||
optionalen Schnittlinie verschnitten statt rechtwinklig gekappt.
|
||||
|
||||
---
|
||||
|
||||
## 2. Datenmodell — was schon da ist, was neu kommt
|
||||
|
||||
### 2.1 Vorhanden (`types.ts`)
|
||||
|
||||
```ts
|
||||
interface Component { …; joinPriority: number; } // höher = läuft am Stoß durch
|
||||
interface Layer { componentId: string; thickness: number; }
|
||||
interface WallType { id; name; layers: Layer[]; } // layers: außen → innen
|
||||
interface Wall { start: Vec2; end: Vec2; wallTypeId; height; … }
|
||||
```
|
||||
|
||||
`joinPriority` ist bereits **pro Bauteil (Component)** definiert — genau richtig:
|
||||
Priorität ist eine **Material-Eigenschaft**, nicht eine Schicht-Eigenschaft. Damit
|
||||
verschneidet sich Beton mit Beton unabhängig vom Wandtyp.
|
||||
|
||||
### 2.2 Neue, abgeleitete Strukturen (keine neuen persistenten Felder)
|
||||
|
||||
Die heutige `WallCuts`-Struktur (eine Schnittlinie je **Wandende**) reicht für L
|
||||
(Gehrung) — aber **nicht** für T/X, weil dort verschiedene Schichten **verschiedene**
|
||||
Trimm-Linien brauchen (Beton läuft durch, Putz stoppt früher). Wir erweitern auf
|
||||
**pro Schicht, pro Ende** eine eigene Trimm-Linie:
|
||||
|
||||
```ts
|
||||
// src/model/joins.ts (erweitert)
|
||||
|
||||
/** Eine gerichtete Halbkante eines Wandendes an einem Knoten. */
|
||||
interface WallEnd {
|
||||
wallId: string;
|
||||
end: "start" | "end";
|
||||
}
|
||||
|
||||
/** Trimm-Linie + Klassifikation für GENAU EIN Schicht-Band an EINEM Ende. */
|
||||
interface LayerCut {
|
||||
/** Schnittgerade in Weltkoordinaten; null = rechtwinklig kappen (Default). */
|
||||
line: Line | null;
|
||||
/**
|
||||
* "miter" – Gehrung (L): geteilte Diagonale mit dem Nachbarn.
|
||||
* "butt" – Band stößt stumpf an eine Nachbarfläche (niedrigere Priorität).
|
||||
* "through" – Band läuft durch den Knoten (höchste Priorität / Backbone).
|
||||
* "square" – freies Ende, rechtwinklig (line === null).
|
||||
*/
|
||||
kind: "miter" | "butt" | "through" | "square";
|
||||
}
|
||||
|
||||
/** Pro Wandende: eine Trimm-Linie je Schicht-Index (parallel zu WallType.layers). */
|
||||
interface EndCuts {
|
||||
/** layerCuts[k] gilt für layers[k]; Länge === wt.layers.length. */
|
||||
layerCuts: LayerCut[];
|
||||
}
|
||||
|
||||
/** Ersetzt die alte WallCuts: jetzt schichtweise an beiden Enden. */
|
||||
interface WallJoin {
|
||||
start: EndCuts;
|
||||
end: EndCuts;
|
||||
}
|
||||
|
||||
export type JoinMap = Map<string /*wallId*/, WallJoin>;
|
||||
```
|
||||
|
||||
**Abwärtskompatibilität:** Die alte L-Gehrung ist der Spezialfall „alle
|
||||
`layerCuts[k].line` an einem Ende sind dieselbe `miter`-Linie". `clippedBand`
|
||||
bleibt unverändert; der Plan-Generator ruft es jetzt **je Schicht mit der
|
||||
schichtspezifischen Linie** auf (siehe §8).
|
||||
|
||||
### 2.3 Knoten-Repräsentation
|
||||
|
||||
```ts
|
||||
/** Ein Verschneidungsknoten: alle Wandenden, die sich (gerundet) berühren. */
|
||||
interface Junction {
|
||||
key: string; // roundKey(p)
|
||||
p: Vec2; // Knotenposition (Mittel der Enden)
|
||||
arms: Arm[]; // sortiert nach Außenwinkel (CCW)
|
||||
}
|
||||
|
||||
/** Ein „Arm" = ein Wandende, gesehen als Strahl, der vom Knoten WEGzeigt. */
|
||||
interface Arm {
|
||||
we: WallEnd;
|
||||
wall: Wall;
|
||||
/** Richtung VOM Knoten weg in die Wand hinein (immer normiert). */
|
||||
dirOut: Vec2; // = end==="start" ? +u : -u
|
||||
/** Außenwinkel atan2(dirOut.y, dirOut.x) für Sortierung. */
|
||||
angle: number;
|
||||
total: number; // Gesamtdicke der Wand
|
||||
/** Schicht-Profil, vom Knoten aus gesehen (siehe §3.2). */
|
||||
layers: ArmLayer[];
|
||||
}
|
||||
|
||||
/** Eine Schicht eines Arms, mit ihren beiden Längs-Flächengeraden am Knoten. */
|
||||
interface ArmLayer {
|
||||
index: number; // Index in wt.layers
|
||||
componentId: string;
|
||||
priority: number; // Component.joinPriority
|
||||
/** Offsets entlang n der Wand: [innerEdge..outerEdge] des Bandes. */
|
||||
off0: number; off1: number;
|
||||
/** Die zwei Längsflächen als Geraden (point am Knoten, dir = u der Wand). */
|
||||
faceA: Line; faceB: Line;
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 3. Knotenerkennung (Junction Detection)
|
||||
|
||||
### 3.1 Knoten clustern
|
||||
|
||||
Identisch zur heutigen Logik, nur ohne die `length !== 2`-Abbruchbedingung:
|
||||
|
||||
```
|
||||
function buildJunctions(walls): Junction[]
|
||||
map = Map<key, WallEnd[]>
|
||||
for w in walls:
|
||||
map.push(roundKey(w.start), {wallId:w.id, end:"start"})
|
||||
map.push(roundKey(w.end), {wallId:w.id, end:"end"})
|
||||
out = []
|
||||
for (key, ends) in map:
|
||||
if ends.length < 2: continue // freies Ende → alle Schichten "square"
|
||||
arms = ends.map(buildArm)
|
||||
arms.sort(by angle) // CCW um den Knoten
|
||||
out.push({ key, p: avgEndPoint(ends), arms })
|
||||
return out
|
||||
```
|
||||
|
||||
`roundKey` (vorhanden) gruppiert Endpunkte auf ein 0.1-mm-Gitter. **Wichtig für
|
||||
T-Stöße:** Bei einem echten T endet die ankommende Wand **auf der Achse** der
|
||||
durchgehenden Wand, nicht an deren Endpunkt. Solche Knoten werden über die
|
||||
Endpunkt-Gruppierung **nicht** gefunden, wenn die durchgehende Wand dort kein Ende
|
||||
hat. Daher zusätzlich (siehe §3.3) eine **Achs-Auf-Achs-Inzidenz**.
|
||||
|
||||
### 3.2 Arm-Schichtprofil (kanonische Orientierung)
|
||||
|
||||
Damit Schichten zweier Arme vergleichbar sind, muss jeder Arm seine Schichten in
|
||||
**konsistenter Welt-Orientierung** kennen. Wir speichern je Schicht ihre beiden
|
||||
**Längsflächen** als Geraden mit Stützpunkt am Knoten und Richtung `u`:
|
||||
|
||||
```
|
||||
function buildArm(we): Arm
|
||||
wall = byId(we.wallId); u = dirOf(wall); n = leftNormal(u)
|
||||
dirOut = we.end==="start" ? u : negate(u) // vom Knoten in die Wand
|
||||
j = we.end==="start" ? wall.start : wall.end
|
||||
total = wallTypeThickness(wt)
|
||||
off = -total/2
|
||||
layers = []
|
||||
for (k, layer) in wt.layers:
|
||||
off0 = off; off1 = off + layer.thickness
|
||||
faceA = { point: j + n*off0, dir: u }
|
||||
faceB = { point: j + n*off1, dir: u }
|
||||
layers.push({ index:k, componentId, priority, off0, off1, faceA, faceB })
|
||||
off = off1
|
||||
return { we, wall, dirOut, angle: atan2(dirOut), total, layers }
|
||||
```
|
||||
|
||||
### 3.3 T-Stoß-Erkennung (Achs-auf-Achs)
|
||||
|
||||
Zusätzlich zu Endpunkt-Clustern: ein Wandende `e` (Punkt `P`) bildet einen
|
||||
**T-Stoß** mit Wand `B`, wenn `P` (innerhalb Toleranz) auf der **Strecke** `B.start
|
||||
→ B.end` liegt, aber **nicht** auf deren Endpunkten:
|
||||
|
||||
```
|
||||
function findTeeIncidences(walls):
|
||||
for endpoint P of each wall A (as WallEnd e):
|
||||
for each wall B != A:
|
||||
if pointOnSegment(P, B.start, B.end, tol) and not nearEndpoint(P, B):
|
||||
// virtueller Knoten: A endet, B läuft durch.
|
||||
registerTee(P, armOf(e), passThroughWall=B)
|
||||
```
|
||||
|
||||
`B` wird hier als **durchgehender Strang** behandelt (kein Ende am Knoten); im
|
||||
Junction-Modell taucht `B` als zwei kollineare „Arme" auf (Richtung `+u` und
|
||||
`−u`), die der Prioritätsalgorithmus (§5) automatisch als „durchlaufend" erkennt
|
||||
(zwei kollineare Arme gleicher Wand → ihre Schichten enden nie gegeneinander).
|
||||
|
||||
**MVP-Vereinfachung (Phase 1, §10):** T-Stöße zunächst NUR über koinzidente
|
||||
Endpunkte (B hat dort tatsächlich einen Eckpunkt, z. B. weil die Wand dort geteilt
|
||||
wurde). Echte Achs-auf-Achs-T-Stöße (B durchgehend) folgen in Phase 3.
|
||||
|
||||
---
|
||||
|
||||
## 4. Winkel-Sektoren & Nachbar-Flächen
|
||||
|
||||
Für die Prioritätsauflösung muss man wissen, **welche Fläche eines Arms welcher
|
||||
Fläche des Nachbarn gegenübersteht**. Die Arme sind CCW nach `angle` sortiert.
|
||||
Zwischen zwei aufeinanderfolgenden Armen `arms[i]` und `arms[i+1]` (zyklisch) liegt
|
||||
ein **Sektor** (Keil). Jeder Sektor wird von **einer Längsfläche jedes der beiden
|
||||
Arme** begrenzt:
|
||||
|
||||
```
|
||||
arm[i+1]
|
||||
\ Sektor S_i
|
||||
\ /
|
||||
faceR(i+1)\ ___ faceL(i)
|
||||
X (Knoten)
|
||||
/
|
||||
/
|
||||
arm[i]
|
||||
```
|
||||
|
||||
Konvention: pro Arm hat die **äußere** Schicht (Index 0, Offset `-T/2`) die Fläche,
|
||||
die in den **CCW-vorausgehenden** Sektor zeigt; die **innere** Schicht den
|
||||
**nachfolgenden**. Konkret bestimmen wir die „dem Sektor zugewandte" Fläche jeder
|
||||
Schicht über das Vorzeichen von `cross(dirOut, sektorrichtung)` — analog zur
|
||||
`lbCloser`-Heuristik in `miterLine`, aber pro Sektor statt global.
|
||||
|
||||
```
|
||||
function sectorFaces(armLeft, armRight):
|
||||
// armRight ist CCW vor armLeft (Sektor liegt zwischen ihnen).
|
||||
// Wähle für jeden Arm die Schicht-Flächen, die in den Sektor zeigen.
|
||||
faceOf(arm, towards): pick faceA or faceB of each layer by sign of
|
||||
cross(arm.dirOut, towards - knoten)
|
||||
```
|
||||
|
||||
Diese Sektor-Sicht verallgemeinert die bestehende `miterLine`: bei genau zwei
|
||||
Armen (L) gibt es zwei Sektoren (innen/außen), und die Mittel-Gehrungslinie ergibt
|
||||
sich wie bisher aus dem Schnitt der gegenüberliegenden Außen- bzw. Innenflächen.
|
||||
|
||||
---
|
||||
|
||||
## 5. Prioritätsauflösung — das Kernstück
|
||||
|
||||
### 5.1 Idee
|
||||
|
||||
An einem Knoten konkurrieren Schichten verschiedener Arme um denselben Raum. Regel:
|
||||
|
||||
> Eine Schicht **läuft durch** (`through`), wenn sie zur **höchsten am Knoten
|
||||
> präsenten Priorität** gehört **und** auf der „gegenüberliegenden" Seite eine
|
||||
> Schicht **gleichen Materials** (oder ≥ gleicher Priorität) existiert, an die sie
|
||||
> nahtlos anschließt. Andernfalls **stößt** sie (`butt`) an die nächsthöher-
|
||||
> priorisierte Nachbarfläche und endet dort.
|
||||
|
||||
Praktisch lösen wir das **fläche-gegen-fläche** je Schicht: Für jede Schicht `L`
|
||||
eines Arms suchen wir die **Trimm-Fläche**, die ihr Band beendet. Das ist die
|
||||
**erste** (vom Knoten aus, entlang `dirOut`) der gegenüberliegenden Flächen mit
|
||||
**echt höherer Priorität**; existiert keine, läuft die Schicht bis zur
|
||||
Knoten-Mittelachse durch.
|
||||
|
||||
### 5.2 Pro Schicht: Trimm-Fläche finden
|
||||
|
||||
```
|
||||
function resolveLayerCut(arm, layer, junction): LayerCut
|
||||
// Kandidaten: alle Schichten ALLER ANDEREN Arme, deren Band den
|
||||
// Halbraum dieses Layers überlappt (Offset-Überlapp im gemeinsamen
|
||||
// Sektor) UND deren Priorität die Trimm-Entscheidung bestimmt.
|
||||
candidates = []
|
||||
for other in junction.arms where other.wall.id-end != arm.id-end:
|
||||
for ol in other.layers:
|
||||
if overlapsInSector(layer, ol, arm, other):
|
||||
candidates.push({ other, ol, face: facingFace(ol, towards arm) })
|
||||
|
||||
// Höchste am Knoten präsente Priorität (global, für "through").
|
||||
maxPrio = max over all candidate.ol.priority and layer.priority
|
||||
|
||||
if layer.priority == maxPrio and hasCollinearSamePrio(arm, layer, junction):
|
||||
// Backbone: läuft durch bis zur Mittel-/Gehrungslinie.
|
||||
return { line: miterMidline(arm, layer, junction), kind: "through" }
|
||||
|
||||
// Sonst: stoße an die NÄCHSTE Fläche höherer Priorität entlang dirOut.
|
||||
blockers = candidates.filter(c => c.ol.priority > layer.priority)
|
||||
if blockers.empty:
|
||||
// niemand höher → Gehrung mit dem Nachbarn gleicher Stufe (L-Fall)
|
||||
return { line: miterMidline(arm, layer, junction), kind: "miter" }
|
||||
|
||||
nearest = argmin over blockers of distanceAlong(dirOut, face)
|
||||
return { line: nearest.face, kind: "butt" }
|
||||
```
|
||||
|
||||
Hilfsbegriffe:
|
||||
|
||||
- `overlapsInSector(layer, ol, …)` — projiziert beide Bänder auf die **Normale des
|
||||
Sektors** und prüft Intervall-Überlapp `[off0,off1] ∩ [off0',off1'] ≠ ∅`. Nur
|
||||
überlappende Bänder können sich gegenseitig trimmen.
|
||||
- `facingFace(ol, towards arm)` — die der `arm`-Seite zugewandte Längsfläche von
|
||||
`ol` (die `faceA`/`faceB` von §3.2), als `Line`.
|
||||
- `distanceAlong(dirOut, face)` — Abstand des Schnittpunkts `faceLine ∩ layerAxis`
|
||||
vom Knoten, gemessen entlang `dirOut`. Negative bzw. hinter dem Knoten liegende
|
||||
Treffer werden verworfen (eine Trimm-Fläche muss **vor** dem Band liegen).
|
||||
- `miterMidline(...)` — die gemeinsame Diagonale für gleichrangige Begegnung; für
|
||||
zwei Arme exakt die heutige `miterLine`.
|
||||
- `hasCollinearSamePrio(...)` — true, wenn auf der „anderen Seite" des Knotens eine
|
||||
Schicht **gleichen Materials/Priorität** existiert, in die das Band nahtlos
|
||||
übergeht (Backbone-Kontinuität, §7).
|
||||
|
||||
### 5.3 Resultat in `LayerCut.line` schreiben
|
||||
|
||||
`resolveLayerCut` liefert für `layers[k]` eine `Line | null`. Diese wird in
|
||||
`WallJoin[end].layerCuts[k]` abgelegt. `clippedBand` kappt damit **dieses eine
|
||||
Band** an genau dieser Linie — alle anderen Schichten derselben Wand können andere
|
||||
Linien (oder `null`) haben. Das ist die ganze Verkabelung zum Renderer.
|
||||
|
||||
---
|
||||
|
||||
## 6. Master-Pseudocode `computeJoins` (neu)
|
||||
|
||||
```
|
||||
function computeJoins(project, walls): JoinMap
|
||||
result = init each wall → { start:{layerCuts:[square…]}, end:{layerCuts:[square…]} }
|
||||
junctions = buildJunctions(walls) // §3.1
|
||||
// (Phase 3: junctions += findTeeIncidences(walls)) // §3.3
|
||||
|
||||
for J in junctions:
|
||||
if J.arms.length == 1: continue // freies Ende: alles "square"
|
||||
if J.arms.length == 2:
|
||||
resolveL(J, project, result) // bestehende Gehrung, schichtweise
|
||||
else:
|
||||
resolveTorX(J, project, result) // §5, pro Arm pro Schicht
|
||||
return result
|
||||
|
||||
function resolveTorX(J, project, result):
|
||||
for arm in J.arms:
|
||||
cuts = []
|
||||
for layer in arm.layers:
|
||||
cuts[layer.index] = resolveLayerCut(arm, layer, J) // §5.2
|
||||
writeEnd(result, arm.we, cuts) // start oder end
|
||||
|
||||
function resolveL(J, project, result):
|
||||
[a, b] = J.arms
|
||||
// Wie heute: eine gemeinsame Gehrungslinie pro Sektor; aber wenn die
|
||||
// Dicken/Schichten ungleich sind, kann pro Schicht über §5.2 verfeinert werden.
|
||||
// MVP: eine miterLine für alle Schichten beider Arme (= heutiges Verhalten,
|
||||
// schichtweise dupliziert).
|
||||
line = miterLine(project, a.wall, a.we.end, b.wall)
|
||||
for arm in [a,b]:
|
||||
cuts = arm.layers.map(_ => ({ line, kind:"miter" }))
|
||||
writeEnd(result, arm.we, cuts)
|
||||
```
|
||||
|
||||
So bleibt die **L-Ecke bit-genau wie heute** (Regressionssicherheit), und die
|
||||
neue Logik greift nur bei ≥ 3 Armen.
|
||||
|
||||
---
|
||||
|
||||
## 7. Prioritäts-Semantik im Detail (das Putz/Beton-Beispiel)
|
||||
|
||||
### 7.1 Kanonisches Beispiel
|
||||
|
||||
Wandtyp „Aussenwand" (außen → innen):
|
||||
|
||||
| k | Component | thickness | joinPriority |
|
||||
|---|------------|-----------|--------------|
|
||||
| 0 | Putz aussen| 0.02 | 1 |
|
||||
| 1 | Stahlbeton | 0.18 | 9 |
|
||||
| 2 | Putz innen | 0.015 | 1 |
|
||||
|
||||
Drei solche Wände treffen in einem T-Knoten (zwei kollinear durchgehend „BB",
|
||||
eine ankommend „A"):
|
||||
|
||||
1. **Beton (prio 9)** der durchgehenden Wände `BB` läuft durch — beide
|
||||
Beton-Bänder sind kollinear gleicher Priorität → `hasCollinearSamePrio` =
|
||||
true → `through`. Der Beton von `A` (prio 9) **stößt** an die **Betonfläche**
|
||||
von `BB` (gegenüberliegende Fläche, gleiche höchste Priorität, aber kein
|
||||
kollinearer Partner für `A`) → `butt` an Betonaußenfläche von `BB`.
|
||||
2. **Putz (prio 1)** jeder Wand stößt an die **erste höherpriorisierte Fläche**
|
||||
entlang `dirOut`. Für die Putzschichten von `A` ist das die **Betonfläche von
|
||||
`BB`**: Putz **läuft auf jeder Seite bis zum Beton** und endet dort (`butt`).
|
||||
3. Putz **überquert nie** den Beton, weil eine `butt`-Trimm-Linie immer die
|
||||
**nächste** höhere Fläche ist — sie liegt vor dem Beton-Durchlauf.
|
||||
|
||||
Ergebnis exakt wie gefordert: *Beton durch, Putz schließt beidseitig an, Putz
|
||||
kreuzt Beton nicht.*
|
||||
|
||||
### 7.2 Warum Priorität pro Component (nicht pro Layer)
|
||||
|
||||
Beton trifft Beton → gleiche Priorität → nahtlos. Würde Priorität pro Schicht
|
||||
vergeben, müsste man sie pro Wandtyp neu pflegen. `joinPriority` am Component löst
|
||||
das materialweise — Stahlbeton hat **immer** 9, egal in welchem Wandtyp.
|
||||
|
||||
### 7.3 Backbone-Erkennung für „through"
|
||||
|
||||
`hasCollinearSamePrio(arm, layer, junction)`:
|
||||
|
||||
```
|
||||
for other in junction.arms where other != arm:
|
||||
if collinear(arm.dirOut, other.dirOut) (antiparallel, gleiche Achse) and
|
||||
other has a layer ol with ol.priority == layer.priority and
|
||||
bandsAlign(layer, ol): // gleiche Offsets relativ zur gemeinsamen Achse
|
||||
return true
|
||||
return false
|
||||
```
|
||||
|
||||
Nur wenn das Band auf der **gegenüberliegenden** Achse einen passenden Partner
|
||||
gleicher Priorität und Lage hat, läuft es wirklich **durch**. Sonst (z. B. der
|
||||
ankommende Beton von `A`) **stößt** es an — exakt das gewünschte Verhalten.
|
||||
|
||||
---
|
||||
|
||||
## 8. Layer-Wrapping (Umschlagen niederpriorisierter Schichten)
|
||||
|
||||
Ein subtiler, aber wichtiger Fall: An einem T-Stoß endet die **innere** Putzschicht
|
||||
der ankommenden Wand `A` an der Betonfläche von `BB`. Damit der Putz **um die Ecke
|
||||
herum sichtbar bleibt** (auf der Innenseite der durchgehenden Wand zieht der innere
|
||||
Putz von `BB` durch), ist nichts Zusätzliches nötig — `BB`s innerer Putz läuft als
|
||||
eigenes durchgehendes Band weiter.
|
||||
|
||||
Wo Wrapping aktiv nötig ist: wenn eine **niederpriorisierte Außenschicht** an einer
|
||||
Ecke **um eine höhere Schicht herumgeführt** werden soll (z. B. Dämmung, die außen
|
||||
um die Stütze läuft). Modellierung:
|
||||
|
||||
- Standard (MVP): kein Wrapping — jede Schicht endet an ihrer Trimm-Fläche
|
||||
(`butt`). Das deckt T/X korrekt ab.
|
||||
- Optional (Phase 4): Ein `wrap`-Flag pro Component (`Component.wrapAtEnds?:
|
||||
boolean`). Ist es gesetzt, erzeugt der Generator an der Trimm-Fläche ein
|
||||
**zusätzliches kurzes Stirnband** quer (Offset-Intervall der Schicht, Länge =
|
||||
Tiefe bis zur nächsten Fläche), sodass die Schicht ihre eigene Stirnseite
|
||||
„umschließt". Geometrisch ein weiteres `clippedBand` mit getauschten Achsen.
|
||||
|
||||
Wrapping ist bewusst **nachgelagert**; es ändert die Trimm-Logik (§5) nicht,
|
||||
sondern fügt nur Zusatzpolygone hinzu.
|
||||
|
||||
---
|
||||
|
||||
## 9. Anbindung an den Plan-Generator (`generatePlan.addWallPoche`)
|
||||
|
||||
Heute ruft `addWallPoche` `clippedBand(p1, p2, off, off+thickness, startCut,
|
||||
endCut)` mit **einer** `WallCuts` je Ende. Neu:
|
||||
|
||||
```ts
|
||||
// joins: JoinMap (neu)
|
||||
const join = joins.get(wall.id) ?? emptyJoin(wt.layers.length);
|
||||
…
|
||||
let off = -total / 2;
|
||||
wt.layers.forEach((layer, k) => {
|
||||
const startCut = (s <= 1e-6) ? join.start.layerCuts[k].line : null;
|
||||
const endCut = (e >= axisLen - 1e-6) ? join.end.layerCuts[k].line : null;
|
||||
out.push({ kind:"polygon",
|
||||
pts: clippedBand(p1, p2, off, off + layer.thickness, startCut, endCut),
|
||||
fill: comp.color, hatch: resolveHatch(...), … });
|
||||
off += layer.thickness;
|
||||
});
|
||||
```
|
||||
|
||||
- Die **Umrisslinie** über die volle Dicke (`-T/2..+T/2`) nutzt für ihre beiden
|
||||
Kanten die Cuts der **äußersten** bzw. **innersten** Schicht — oder wird, falls
|
||||
Schichten unterschiedlich getrimmt sind, durch eine **abgeleitete Outline**
|
||||
(Vereinigung der Schicht-Polygone, §11) ersetzt. MVP: weiterhin volle-Dicke-Band
|
||||
mit den Cuts von Schicht 0 / letzter Schicht.
|
||||
- `grob`-Detailgrad nutzt nur die **Backbone-Schicht** → ihr `through`/`miter`-Cut
|
||||
für die ganze Sammelfläche (entspricht der bestehenden `backboneColor`-Logik).
|
||||
|
||||
**Keine Signaturänderung an `clippedBand`** — es bleibt der zentrale Trimmer; wir
|
||||
füttern es nur schichtweise mit verschiedenen Linien.
|
||||
|
||||
---
|
||||
|
||||
## 10. 2D-analytisch jetzt vs. exakte 3D-Booleans später (OCCT)
|
||||
|
||||
### 10.1 Jetzt — 2D-analytisch (dieses Design)
|
||||
|
||||
- **Plan/Grundriss** ist eine reine 2D-Ableitung (vgl. `generatePlan.ts`-Kopf:
|
||||
„nicht durch Zerschneiden eines 3D-Meshes, sondern direkt aus den Parametern").
|
||||
- Trimmen = **Geraden-Schnitt** (`lineIntersect`) + Polygon-Kappen (`clippedBand`).
|
||||
Kein Polygon-Boolean nötig, solange Schichten als **konvexe Bänder** mit
|
||||
schrägen Stirnflächen modelliert werden. Das ist exakt, schnell (O(Arme² ·
|
||||
Schichten) je Knoten), und deterministisch.
|
||||
- **3D-Wand** im Viewport: Extrusion der getrimmten 2D-Schichtpolygone in `z`
|
||||
(Höhe). Damit stimmen Plan und 3D ohne separaten Kernel überein.
|
||||
|
||||
Grenzen der 2D-Analytik: nicht-konvexe Stirnprofile, echte Materialdurchdringung in
|
||||
`z` (z. B. wenn Wände unterschiedlicher Höhe / Sturz / Brüstung interagieren),
|
||||
Verschneidung Wand × Decke × Stütze. Das braucht echte Volumen-Booleans.
|
||||
|
||||
### 10.2 Später — exakte 3D-Booleans (OCCT / opencascade.js)
|
||||
|
||||
- **Bibliothek:** `opencascade.js` (WASM-Port von OCCT) — `BRepAlgoAPI_Cut/Common`,
|
||||
`BRepPrimAPI_MakePrism` für Extrusionen. Alternativ `manifold-3d` (schneller,
|
||||
robuster für reine Mesh-Booleans, aber ohne B-Rep/Fillets).
|
||||
- **Modell bleibt gleich:** Priorität (`joinPriority`) bestimmt die **Cut-
|
||||
Reihenfolge**. Algorithmus: baue je Schicht einen über-langen Solid (Band ×
|
||||
Höhe, über den Knoten hinaus verlängert); subtrahiere von jeder niederpriori-
|
||||
sierten Schicht die Solids **aller höherpriorisierten** Schichten am Knoten
|
||||
(`result = layerSolid − ⋃ higherPrioritySolids`). Gleiche Priorität: kein Cut
|
||||
(Beton bleibt an Beton). Das ist die **3D-Verallgemeinerung exakt derselben
|
||||
Prioritätsregel** — die 2D-`butt`/`through`-Klassifikation aus §5 ist die
|
||||
2D-Projektion dieser Boolean-Reihenfolge.
|
||||
- Die Datenstrukturen (§2) bleiben unverändert; nur der **Trimmer** wird
|
||||
ausgetauscht (`clippedBand` → OCCT-Cut). Deshalb ist das 2D-Design bereits
|
||||
„OCCT-ready".
|
||||
|
||||
---
|
||||
|
||||
## 11. Robuste Outline (optional, Phase 4)
|
||||
|
||||
Wenn Schichten an einem Knoten unterschiedlich getrimmt sind, ist die „volle
|
||||
Dicke"-Umrisslinie nicht mehr ein einfaches Band. Saubere Lösung: die
|
||||
**Wand-Outline** als **Vereinigung aller Schicht-Polygone** berechnen
|
||||
(Polygon-Boolean in 2D). Empfohlene Library: **`polygon-clipping`** (Martinez-
|
||||
Rueda, robust, klein) oder **`@flatten-js/boolean-op`**. Damit wird der Umriss
|
||||
exakt die Außenkontur der getrimmten Bänder — auch bei X-Knoten. MVP verzichtet
|
||||
darauf und nutzt die Schicht-0/N-Cuts (visuell für die meisten Fälle ausreichend).
|
||||
|
||||
---
|
||||
|
||||
## 12. Edge Cases
|
||||
|
||||
1. **Gleiche Priorität, nicht kollinear** (z. B. zwei Betonwände treffen im rechten
|
||||
Winkel im T): kein „through" (kein kollinearer Partner), aber auch kein
|
||||
`butt`-Blocker höherer Priorität → Fallback **`miter`** (gemeinsame Gehrung wie
|
||||
im L-Fall). Bei drei gleichrangigen Armen: paarweise Gehrung pro Sektor; die
|
||||
resultierenden Stirnflächen sind die Sektor-Halbierenden.
|
||||
2. **Kollinear (180°)** — zwei Wände in einer Linie: `lineIntersect` liefert null
|
||||
(parallel). Behandlung wie heute: **kein Schnitt**, Bänder laufen gerade durch
|
||||
(bei gleichem Typ nahtlos). Bei ungleichem Typ: die schmalere Wand stößt an die
|
||||
breitere; pro Schicht über §5 auflösbar.
|
||||
3. **> 2 Schichten / asymmetrische Wandtypen**: Der Algorithmus ist in der Schicht-
|
||||
anzahl generisch (`resolveLayerCut` läuft je Schicht-Index). Treffen Wände
|
||||
verschiedener Typen (verschiedene Schichtzahl/-dicke), entscheidet **nur die
|
||||
Priorität pro Fläche**, nicht der Index — deshalb arbeiten wir mit
|
||||
`ArmLayer.faceA/faceB` (Welt-Flächen), nicht mit Schicht-Indizes über Wände
|
||||
hinweg.
|
||||
4. **Backbone fehlt** (alle Prioritäten gleich): degeneriert sauber zu reinen
|
||||
Gehrungen (Fall 1).
|
||||
5. **Sehr spitze Winkel**: Trimm-Schnittpunkte können weit vom Knoten wegwandern.
|
||||
Begrenzung: `distanceAlong` auf `≤ maxReach` (z. B. `3 · total`) clampen; sonst
|
||||
rechtwinklig kappen (`square`), um Artefakte zu vermeiden.
|
||||
6. **Öffnungen am Wandende** (`addWallPoche`-Segmentierung): Cuts gelten nur für das
|
||||
echte Wandende (`s≤ε` / `e≥len−ε`), wie heute. Türnahe Segmentenden bleiben
|
||||
`square`.
|
||||
7. **Numerische Knoten-Toleranz**: `roundKey`-Gitter (0.1 mm) und ε in
|
||||
`pointOnSegment` müssen konsistent sein, sonst „flackernde" Knoten. Toleranz
|
||||
zentral als Konstante (`JOIN_EPS = 1e-4` m).
|
||||
8. **Mehr als 2 Wände gleicher Achse** (degenerierter X, alle kollinear): als ein
|
||||
durchgehender Strang behandeln; Prioritätsregel pro Schicht greift normal.
|
||||
|
||||
---
|
||||
|
||||
## 13. Staged Build-Plan
|
||||
|
||||
**Phase 1 — Single-Layer T (Fundament).**
|
||||
- `JoinMap`/`WallJoin`/`EndCuts`/`LayerCut` einführen; `WallCuts` darin als
|
||||
Spezialfall abbilden. `clippedBand` unverändert.
|
||||
- `buildJunctions` ohne `length!==2`-Abbruch; L-Fall ruft bestehende `miterLine`
|
||||
(schichtweise dupliziert) → **Regressionsgleichheit** zu heute.
|
||||
- T-Knoten **nur über koinzidente Endpunkte** (§3.3 MVP). Für **einschichtige**
|
||||
Wände: die durchgehende Wand läuft durch, die ankommende stößt rechtwinklig an
|
||||
deren nächste Fläche. Verifizieren: `npx tsc -b`, `npm run build`,
|
||||
`node scripts/probe.mjs`, Screenshot prüfen.
|
||||
|
||||
**Phase 2 — Prioritäts-Auflösung mehrschichtig (T).**
|
||||
- `ArmLayer`-Profil (§3.2), Sektor-Flächen (§4), `resolveLayerCut` (§5) inkl.
|
||||
`through`/`butt`/`miter`-Klassifikation und `hasCollinearSamePrio`.
|
||||
- `addWallPoche` schichtweise verkabeln (§9). Putz/Beton-Testszene (§7.1) anlegen
|
||||
und visuell prüfen.
|
||||
|
||||
**Phase 3 — X-Knoten & echte Achs-T-Stöße.**
|
||||
- `findTeeIncidences` (Achs-auf-Achs, §3.3): durchgehende Wand wird nicht geteilt.
|
||||
- 4+-Arm-Sektorlogik vollständig; Edge Cases 1/5/8 absichern.
|
||||
|
||||
**Phase 4 — Politur.**
|
||||
- Robuste Outline via Polygon-Boolean (§11); optionales Layer-Wrapping (§8,
|
||||
`Component.wrapAtEnds`).
|
||||
|
||||
**Phase 5 — Exakte 3D-Booleans (OCCT).**
|
||||
- `opencascade.js` integrieren; Trimmer-Interface so abstrahieren, dass 2D
|
||||
(`clippedBand`) und 3D (OCCT-Cut) dieselbe Prioritäts-Reihenfolge nutzen (§10.2).
|
||||
Plan bleibt 2D-analytisch; nur das 3D-Volumen nutzt Booleans.
|
||||
|
||||
---
|
||||
|
||||
## 14. Trimmer-Abstraktion (für §10.2-Migration)
|
||||
|
||||
Damit Phase 5 nicht den Aufrufer ändert, kapseln wir das Trimmen hinter einer
|
||||
Schnittstelle. 2D nutzt `clippedBand`; 3D nutzt OCCT — beide konsumieren dieselbe
|
||||
`JoinMap`.
|
||||
|
||||
```ts
|
||||
interface LayerTrimmer {
|
||||
/** 2D: getrimmtes Bandpolygon. 3D-Variante liefert stattdessen einen Solid. */
|
||||
trimBand(p1: Vec2, p2: Vec2, offA: number, offB: number,
|
||||
startCut: Line | null, endCut: Line | null): Vec2[];
|
||||
}
|
||||
```
|
||||
|
||||
Die Prioritätslogik (`computeJoins`) bleibt der **gemeinsame, kernel-unabhängige**
|
||||
Kopf; nur der `LayerTrimmer` wird ausgetauscht. Das hält das Design dem
|
||||
Architektur-Prinzip treu: ein semantisches Modell, viele abgeleitete Ansichten.
|
||||
Reference in New Issue
Block a user