karim/DOSSIER-WEBSITE
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Initial commit: DOSSIER Hugo website

Browse Source
This commit is contained in:
karim
2026-05-26 11:23:18 +02:00
commit 53c0532f60
417 changed files with 32891 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/features/_index.md
+27
View File
@@ -0,0 +1,27 @@
---
title: Features
linkTitle: Features
weight: 2
sidebar:
open: true
---
Alle DOSSIER-Panels im Überblick. Jedes Feature ist ein eigenes Modul mit React-UI und Python-Backend.
{{< cards >}}
{{< card link="geschosse" title="Geschosse & Ebenen" icon="template" subtitle="Layer-Hierarchie, Multi-Geschoss-Clipping, Snap-Bar, Top-View Z-Guard." >}}
{{< card link="smart-elemente" title="Smart-Elemente" icon="cube" subtitle="Wände v1 (Polyline + Chain-Anchor + Grips) · Decken · Dächer · Öffnungen · Treppen · Tragwerk." >}}
{{< card link="schnitte-ansichten" title="Schnitte & Ansichten" icon="scissors" subtitle="Schnitt-Perspektive, Section-Style-API, Hidden-Line, Hatch-Pattern." >}}
{{< card link="project-settings" title="Project-Settings" icon="cog" subtitle="5 Tabs — Voreinstellungen, Materialien, Linientypen, Hatches, Symbole." >}}
{{< card link="materialien" title="Material-Library" icon="color-swatch" subtitle="PBR + Texturen, .lin/.pat-Import, Material/Ebene-Separation, Auto-Regen." >}}
{{< card link="symbol-library" title="Symbol-Library" icon="collection" subtitle="2D+3D Pair-Files, Satellite-Picker, Multi-Format-Import, Auto-Thumbnails." >}}
{{< card link="raeume-sia416" title="Räume (SIA 416)" icon="view-grid" subtitle="HNF / NNF / FF / VF, Flächentabellen, CSV-Export." >}}
{{< card link="layouts" title="Layouts & PDF-Export" icon="document-duplicate" subtitle="Plan-Sets, Titelblock-Vorlagen, Stapelexport." >}}
{{< card link="massstab" title="Massstab & Display" icon="search" subtitle="Viewport 1:N, Auto-DPI, Display-Modes (Dossier-Plan in Entwicklung)." >}}
{{< card link="gestaltung" title="Gestaltung & Overrides" icon="adjustments" subtitle="Farbe · Lineweight · Linetype · Hatch · Regeln." >}}
{{< card link="ausschnitte" title="Ausschnitte & Kamera" icon="camera" subtitle="Viewport-Snapshots, Detail-Views, Kamera-Sets." >}}
{{< card link="dimensionen" title="Dimensionen" icon="lightning-bolt" subtitle="Bemassungs-Panel, Wand-Dicken, Geschoss-Höhen." >}}
{{< card link="swisstopo-osm" title="Swisstopo & OSM" icon="map" subtitle="Landeskarten-Tiles, OSM, Adress-Prefill, Terrain, m.ü.M." >}}
{{< card link="text-editor" title="DOSSIER-Text Editor" icon="pencil" subtitle="WYSIWYG Rich-Text für TextEntities mit RTF-Export." >}}
{{< card link="werkzeuge" title="Werkzeuge" icon="cog" subtitle="Batch-Tools — Cache-Clear, Section-Reset, Layer-Bereinigung." >}}
{{< /cards >}}
content/features/ausschnitte.md
+69
View File
@@ -0,0 +1,69 @@
---
title: Ausschnitte & Kamera
linkTitle: Ausschnitte
weight: 11
---
Das **AUSSCHNITTE**-Panel speichert Viewport-Snapshots — Kamera-Position + Display-Mode + Layer-Sichtbarkeit als wiederherstellbare States.
## Was wird gespeichert?
Pro Ausschnitt:
- **Kamera** — Position, Target, Up-Vector, FOV oder Parallel-Projection
- **Display-Mode** — Wireframe, Shaded, Dossier-Plan, …
- **Layer-Sichtbarkeit** — pro Layer on/off, Sublayer-Override
- **Massstab** — gespeichert mit dem Snapshot (über `massstab.py`)
- **Clipping-Plane** — optional, mit Position und Normal
- **Section-Style** — falls aktiv
## KAMERA-Panel
Eigenes Sub-Panel für reine Kamera-Verwaltung — ohne Layer und Display:
- Standard-Ansichten (Grundriss, Schnitt, Axo, ISO)
- Eigene Kamera-Sets pro Geschoss
- Multi-Cam-Toolbar für schnellen Wechsel
## Detail-Views
Ausschnitte sind die Grundlage für **Detail-Views** im Layout. Workflow:
{{% steps %}}
### Ausschnitt im Modell anlegen
In Rhino auf die gewünschte Stelle zoomen, Layer und Display einstellen, im AUSSCHNITTE-Panel auf **Speichern**.
### Benennen und kategorisieren
Bezeichnung (`Anschluss Wand-Decke`), Massstab (1:20), Geschoss-Zuordnung.
### Auf Layout ziehen
Im LAYOUTS-Panel den Ausschnitt auswählen, auf Layout-Blatt platzieren. Massstab wird übernommen, Titelblock-Feld automatisch ausgefüllt.
### Beschriftung
Bemassungen direkt im Modellraum — durch die View-Verknüpfung erscheinen sie nur in diesem Ausschnitt im Layout.
{{% /steps %}}
## AUSSCHNITT-SETTINGS
Pro Ausschnitt einstellbar:
- **Linienstärken-Override** — z.B. Detail mit dickeren Linien
- **Hatch-Sichtbarkeit** — pro Ausschnitt ein/aus
- **Annotation-Layer** — separater Layer für Detail-Bemassung
- **Auto-Refresh** — bei Modell-Änderung Snapshot neu rendern
## Bi-direktional mit MASSSTAB
```text
AUSSCHNITTE ──save with scale──▶ MASSSTAB
▲ │
└────read scale on restore─────┘
```
Beim Wechsel eines Ausschnitts wird die gespeicherte Skala über das MASSSTAB-Panel angewendet — inkl. PlotWeight-Synchronisation.
content/features/dimensionen.md
+62
View File
@@ -0,0 +1,62 @@
---
title: Dimensionen
linkTitle: Dimensionen
weight: 12
---
Das **DIMENSIONEN**-Panel zeigt und editiert Bemassungs-Stile und Objekt-Informationen für die aktuelle Selektion.
## Objekt-Info
Für die Selektion werden angezeigt:
| Eigenschaft | Beschreibung |
|-------------------|------------------------------------------------|
| Position | X / Y / Z im Welt-Koordinatensystem |
| Abmessungen | Bounding-Box-Dimensionen |
| Element-Typ | Wand, Decke, Öffnung, Raum, … (falls Smart) |
| Geschoss | Aus `dossier_geschoss_id` UserString |
| Material | Index + Hex-Farbe |
| Layer | Vollständiger Pfad |
| User-Strings | Alle `dossier_*` Keys + Werte |
Bei Multi-Selektion werden Summen / Mittelwerte angezeigt.
## Bemassungs-Stile
DOSSIER liefert konsistente Bemassungsstile:
- **Architektur 1:100** — kleine Pfeile, Lineweight 0.18 mm
- **Architektur 1:50** — Standard für Konstruktionspläne
- **Detail 1:20** — grössere Schrift, mehr Hierarchie
- **Statik** — andere Schrift, technische Beschriftung
Stile sind im Dokument gespeichert und können als Vorlage in andere Projekte übertragen werden.
## Wand-Dicken-Bemassung
Spezial-Funktion: über alle Wände eines Geschosses automatisch Dicken-Bemassung erzeugen — mit konfigurierbarer Versatzdistanz und Ausrichtung.
## Geschoss-Höhen
Vertikale Bemassung zwischen OKFF-Linien — entweder als manuelle Bemassung in einem Schnitt oder automatisch aus den Geschoss-Daten generiert.
## Öffnungs-Masse
Für selektierte Öffnungen:
- Brüstungshöhe (UK)
- Sturzhöhe (OK)
- Breite × Höhe (Lichtmass)
- Position in der Wand (Abstand vom nächsten Eck)
Werden bei Modell-Änderungen aktualisiert.
## MASSE-SETTINGS
Eigenes Sub-Panel für globale Bemassungs-Einstellungen:
- Linien-Farbe und -Stärke
- Pfeil-Typ (Tick, Arrow, Dot)
- Schrift-Höhe in mm
- Massstabs-Faktor (Display vs. Plot)
content/features/geschosse.md
+96
View File
@@ -0,0 +1,96 @@
---
title: Geschosse & Ebenen
linkTitle: Geschosse
weight: 1
---
Das **EBENEN**-Panel ist die zentrale Projekt-Struktur. Geschosse mit Name, Höhe und OKFF definieren — Dossier baut die komplette Layer-Hierarchie automatisch auf.
## Geschoss-Definition
Jedes Geschoss trägt:
| Feld | Beschreibung |
|--------|-------------------------------------------------------|
| Name | `UG`, `EG`, `1OG`, `2OG`, `DG`, … (frei wählbar) |
| Höhe | Lichte Höhe in mm |
| OKFF | Oberkante Fertigfussboden, absolut in mm |
| Typ | Vollgeschoss · Untergeschoss · Dachgeschoss · Attika |
Gespeichert als JSON in `doc.Strings["dossier_ebenen"]` — bleibt in der `.3dm` erhalten.
## Layer-Hierarchie
Aus den Geschossen baut Dossier diese Struktur:
```text
10_GRUNDRISSE
├── EG
│ ├── 20_WAENDE
│ ├── 30_DECKEN
│ ├── 31_DAECHER
│ └── 40_TREPPEN
├── 1OG (gleiche Sublayer)
└── 2OG
20_SCHNITTE
30_ANSICHTEN
00_RASTER
01_VERMESSUNG
40_SITUATION
90_REFERENZEN
99_KONSTRUKTION
```
Wird ein neues Geschoss angelegt, werden die Sublayer automatisch nachgezogen (`layer_builder.py`).
## Presets
Häufige Konstellationen sind als Presets verfügbar:
- **Einfamilienhaus** — UG / EG / OG / DG
- **Mehrfamilienhaus** — UG / EG / 1OG / 2OG / 3OG / DG
- **Gewerbe** — TG / EG / 1OG / 2OG
Eigene Presets können gespeichert und projektübergreifend wiederverwendet werden.
## Aktives Geschoss
Das aktive Geschoss bestimmt, auf welchem Layer neue Smart-Elemente landen. Wechsel über das Drop-Down im EBENEN-Panel oder über die OBERLEISTE.
## Multi-Geschoss-Clipping
Beim Editieren eines Geschosses werden alle darüberliegenden Geschosse automatisch geclippt — sichtbar ist nur das aktive plus optional die unmittelbar darunterliegenden Etagen als Referenz. Die Clipping-Planes sitzen exakt auf OKFF + Geschoss-Höhe und folgen jeder Höhen-Änderung sofort.
Modi:
- **Aktiv only** — nur das gewählte Geschoss
- **Aktiv + Darunter** — mit der nächst tieferen Etage als Kontext (Standard)
- **Alle** — Multi-Geschoss-Stack ohne Clipping
Toggle über die OBERLEISTE oder per Shortcut. Clipping ist viewport-spezifisch — Schnittansichten bleiben unberührt.
## Top-View Z-Guard
In der Top-View werden Smart-Elemente versehentlich gerne mit Z-Offset verschoben. Der **Z-Guard** fängt das ab: bei Move/Drag-Operationen aus der Top-View wird die Z-Komponente auf 0 (relativ zum aktiven Geschoss-OKFF) gezwungen, ausser der User hält explizit eine Modifier-Taste. Das verhindert die typischen "warum schwebt jetzt meine Wand"-Fehler.
## Snap-Bar pro Geschoss
Eigene Snap-Targets pro Geschoss werden im EBENEN-Panel über die **Snap-Bar** verwaltet:
- **OKFF-Linien** — pro Geschoss als horizontale Endlos-Snaps
- **Achs-Lines** — Tragwerk-Achsen als geteilte Referenz
- **Polyline-Knoten** — automatisch aus den Wand-Polylines abgeleitet
Snaps werden viewport-bezogen registriert und beim Geschoss-Wechsel automatisch ein-/ausgeblendet. Spart Rhinos OSnap-Slot für andere Workflows.
{{< callout type="info" >}}
Code-Identifier verwenden **ASCII-Schreibweise** (`UG`, `OG`, `DG`) — UI darf Umlaute, Layer-Codes nicht. Das ist eine bewusste Konvention seit der CPython-3-Migration.
{{< /callout >}}
## Cross-Module-Verhalten
Wenn Geschoss-Höhen oder OKFF im EBENEN-Panel geändert werden:
1. `rhinopanel.py` schreibt die neuen Werte in `doc.Strings`
2. `elemente_bridge._regenerate_all()` wird über Sticky-Reference getriggert
3. Alle Wand- und Decken-Volumen regenerieren automatisch
content/features/gestaltung.md
+78
View File
@@ -0,0 +1,78 @@
---
title: Gestaltung & Overrides
linkTitle: Gestaltung
weight: 10
---
Das **GESTALTUNG**-Panel verwaltet Selektions-Attribute (Farbe, Lineweight, Linetype, Hatch) und integriert sich mit der **Overrides-Engine** für regelbasierte Wiederverwendung.
## GESTALTUNG-Panel
Direkte Editierung der Selektions-Eigenschaften:
- **Farbe** — Hex-Picker, Layer-Default oder Override
- **Lineweight** — in mm oder PlotWeight-Stufe
- **Linetype** — Continuous, Dashed, Dotted, Custom-Pattern
- **Hatch** — Pattern, Scale, Rotation, Color
- **Plot-Sync** — Display-Farbe und Plot-Farbe identisch oder unabhängig
### Hatch-Curve-Link
Hatches werden über eine **UUID** an die Boundary-Curve gebunden (in `sc.sticky` gespeichert). Grund: Rhinos UserStrings werden bei Move oder Replace teilweise weggewischt — die Sticky-Bindung ist robuster.
**Pending-Hatch TTL** — 3-Sekunden-Fenster nach Drag/Move, in dem Hatch-Metadaten wiederherstellbar sind. Verhindert verlorene Hatches bei schnellen Edit-Operationen.
## Overrides-Engine
Regelbasierte Overrides folgen dem Schema **Bedingung → Aktion**:
### Beispiel: Tragwände hervorheben
```yaml
- name: Tragwände rot
condition:
element_type: wand
variant: tragwand
action:
color: "#c44b4b"
lineweight: 0.50
hatch:
pattern: Solid
color: "#c44b4b40"
```
### Beispiel: Geschoss 1OG ausblenden
```yaml
- name: 1OG-Fade
condition:
layer: "10_GRUNDRISSE::1OG::*"
action:
color: "#88888840"
print: false
```
## Presets
Presets sind **cross-doc** — einmal definiert, in jedem Projekt verfügbar:
- **Wettbewerb** — Reduktion auf Linie, kein Hatch
- **Ausführungsplan** — Volle Hatching, Section-Styles aktiv
- **Detail 1:20** — Hohe Strichstärken, Materialhinweise
- **Präsentation** — Farben + Schatten, kein Bemassungs-Layer
Preset-Auswahl in der OBERLEISTE triggert `overrides_bridge._send_state()` — Panel-Sync ohne Reload.
## Plot-Sync
Drei Modi für Display vs. Plot:
| Modus | Beschreibung |
|-----------------|---------------------------------------------------------|
| **Sync** | Display-Farbe = Plot-Farbe (Standard) |
| **Print-only** | Display bunt zum Editieren, Plot in Schwarz/Weiss |
| **Display-only**| Plot folgt Layer-Default, Display ist Override |
## Hatch-Pattern Matching
`gestaltung.py` und `rhinopanel.py` koppeln über die **Pattern + Scale + Rotation-Signature**. Wenn ein Hatch in der Selektion einer bekannten Layer-Konvention entspricht, wird automatisch der passende Layer vorgeschlagen.
content/features/layouts.md
+77
View File
@@ -0,0 +1,77 @@
---
title: Layouts & PDF-Export
linkTitle: Layouts
weight: 8
---
Das **LAYOUTS**-Panel baut auf Rhinos Layout-System auf und ergänzt die projektbezogene Verwaltung: Plan-Sets, zentrale Titelblock-Vorlagen und Stapelexport.
## Plan-Set Workflow
{{% steps %}}
### Vorlage wählen
Titelblock-Vorlagen liegen als zentrale Master pro Büro / Projekt. Bürologo, Phasenbezeichnung, Plannummer und Adresse werden aus den Projektdaten (`dossier.project.json`) gespeist und bleiben über alle Blätter konsistent.
### Views auf das Blatt ziehen
Named Views aus dem Modell (`Grundriss EG`, `Schnitt A-A`, `Axonometrie`, …) werden auf das Layout-Blatt gezogen. Der **Massstab** wird mit der View übernommen und automatisch im Titelblock eingetragen.
### Plannummer vergeben
Plannummern nach Konvention `A.01`, `A.02`, `D.01`, … Reihenfolge bestimmt das spätere Planverzeichnis.
### Beschriftung
Bemassungen, Höhenkoten und Detailverweise direkt im Modellraum platzieren — durch die View-Verknüpfung erscheinen sie korrekt im Layout.
{{% /steps %}}
## Titelblock
Felder werden aus Projekt-Daten gespeist:
| Feld | Quelle |
|----------------|------------------------------------------------|
| Bürologo | `dossier.project.json` → `buero.logo` |
| Bauherr | `dossier.project.json` → `bauherr` |
| Projektnummer | `dossier.project.json` → `projektnummer` |
| Phase | `dossier.project.json` → `phase` |
| Plannummer | Pro Layout-Blatt |
| Plantitel | Pro Layout-Blatt |
| Massstab | Aus Named View übernommen |
| Datum | Automatisch (oder manuell überschrieben) |
## Stapelexport
Alle Pläne in einem Durchgang:
- **Vektor-PDF** — eingebettete Schichten (Layer), text-suchbar
- **PNG** — hochauflösend für Präsentationen und Wettbewerbe
- **JPG** — kompakter, mit Qualitätsstufe einstellbar
Dateinamen folgen dem Schema `{Projektnummer}_{Plannummer}_{Titel}.pdf` — konfigurierbar.
## Planverzeichnis
Automatisches Inhaltsverzeichnis aller Pläne mit:
- Nummer
- Titel
- Massstab
- Datum
- Phase
Exportierbar als eigenes Übersichts-Blatt im Plan-Set oder als CSV.
## LAYOUT-Dialog
Das **LAYOUT-DIALOG**-Panel zeigt für jedes Layout-Blatt:
- Verwendete Views
- Massstab-Verifikation (Soll vs. Ist)
- Fehlende Beschriftungen
- Status (Entwurf / Eingabe / Ausführung)
Ein Plan-Audit vor dem Export verhindert, dass Skalen-Fehler in die Ausgabe wandern.
content/features/massstab.md
+92
View File
@@ -0,0 +1,92 @@
---
title: Massstab & Display-Modes
linkTitle: Massstab
weight: 9
---
Das **MASSSTAB**-Panel verwaltet den Viewport-Massstab und die Display-Modes. Es kommuniziert bi-direktional mit AUSSCHNITTE — Skala lesen und setzen.
## Massstab 1:N
Standard-Massstäbe für architektonische Pläne:
| Code | Verwendung |
|--------|------------------------------------------|
| 1:1 | Detail |
| 1:5 | Detail |
| 1:10 | Detail |
| 1:20 | Detail / Konstruktion |
| 1:50 | Grundriss Detail / Konstruktion |
| 1:100 | Grundriss / Schnitt / Ansicht (Standard) |
| 1:200 | Grundriss (gross) |
| 1:500 | Situation |
| 1:1000 | Situation / Übersicht |
Eigene Skalen können hinzugefügt werden.
## Auto-DPI
Auf Mac wird die DPI über **CoreGraphics** automatisch ermittelt — Retina-Display vs. externer Monitor wird korrekt erkannt. Robuster als die meisten alternativen Ansätze (z.B. NSScreen-Polling) und ohne Display-Profile-Hacks.
Auf Windows wird `GetDeviceCaps(LOGPIXELSX)` verwendet.
## PlotWeight-Synchronisation
Plot-Strichstärken sind massstabsabhängig:
```text
1:100 → 0.18 mm = 0.5 PlotWeight
1:50 → 0.18 mm = 1.0 PlotWeight (skalierungsbedingt)
1:20 → 0.18 mm = 2.5 PlotWeight
```
Das MASSSTAB-Panel rechnet die effektive PlotWeight für die aktuelle Skala automatisch und schreibt sie in die Layer-Eigenschaften.
## Display-Modes
Eingebaute Display-Modes plus DOSSIER-spezifische:
| Mode | Verwendung |
|----------------------|--------------------------------------------------|
| Wireframe | Editieren, Geometrie-Check |
| Shaded | Modellansicht |
| Rendered | Präsentation |
| **Dossier-Plan** | Plot-optimiert (in aktiver Entwicklung) |
| **Dossier-Flaechen** | SIA-416 farbliche Überlagerung |
| **Dossier-Detail** | Hatching aktiv, hohe Strichstärken |
Display-Modes werden einmal gelesen und im Sticky gecacht (`oberleiste.py`).
### Dossier-Plan — Plan-Qualität direkt aus 3D
{{< callout type="warning" >}}
**In Arbeit.** Der Dossier-Plan-Mode ist der nächste grosse Schritt für Plan-Qualität direkt aus dem 3D-Modell — ohne Umweg über 2D-Plandateien.
{{< /callout >}}
Drei kombinierte Effekte machen den Mode aus:
- **Hidden-Line-Removal** — verdeckte Kanten werden ausgeblendet, Sichtkanten als saubere Strichgrafik gerendert. Funktioniert in Top-View und in der Schnitt-Perspektive.
- **Weisser Hintergrund** — Modell-Background auf reinweiss gezwungen, Layer-Display-Farben werden zu pure Schwarz remappt. Sieht direkt aus wie ein gedruckter Plan, nicht wie ein 3D-Viewport.
- **Section-Hatch** — Schnittflächen, die über die [Schnitte & Ansichten](../schnitte-ansichten)-Section-Style-API erzeugt wurden, werden mit Pattern und Lineweight aus dem Layer-Style gehatched.
Das Ziel: Wettbewerbs- und Konkurrenz-Pläne direkt aus dem Modell exportieren, ohne Plot-Konvertierung über 2D-CAD.
## Section-Styles
Mit der CPython-3-Migration ist `Rhino.DocObjects.SectionStyle()` direkt instanziierbar — `layer.SetCustomSectionStyle()` verfügbar. Die volle Section-Style-API steht zur Verfügung:
- Schnittlinien-Stil pro Layer
- Hatch-Pattern für Schnittflächen
- Hidden-Line-Removal für Ansichten
War der **Anlass** für die Migration von IronPython 2.7 zu CPython 3.
## Bi-direktional mit AUSSCHNITTE
```text
MASSSTAB ──set scale──▶ AUSSCHNITTE
▲ │
└──read scale on load───┘
```
Beim Wechsel eines Ausschnitts (Named View) wird die gespeicherte Skala übernommen. Manuelle Massstabs-Änderung wird beim nächsten Save in den Ausschnitt zurückgeschrieben.
content/features/materialien.md
+101
View File
@@ -0,0 +1,101 @@
---
title: Material-Library
linkTitle: Materialien
weight: 5
---
Die Material-Library lebt im **PROJECT-SETTINGS**-Tab "Materialien" und folgt einem **ArchiCAD-style List/Detail-Layout**: links die Material-Liste, rechts der Detail-Editor für die aktive Auswahl.
## List/Detail-Workflow
{{% steps %}}
### Material in der Liste anlegen
Plus-Button → neues Material mit Default-Werten. Liste wird sofort aktualisiert, Thumbnail erscheint.
### Detail editieren
Rechts werden alle Eigenschaften der aktiven Auswahl gezeigt: Name, Farbe, Rauheit, Metallic, Texturen, Linetype-Binding. Änderungen werden live geschrieben — kein Apply-Button.
### Verwendung im Modell
Material wird im ELEMENTE-Panel pro Smart-Element ausgewählt. Auto-Regen aktualisiert die Rhino-Rendermaterials und triggert eine View-Aktualisierung.
{{% /steps %}}
## PBR-Materialien
Jedes Material trägt:
| Eigenschaft | Beschreibung |
|---------------|-------------------------------------------------------|
| Name | Frei vergeben — `Sichtbeton fein`, `Eiche geölt` |
| Albedo | Basis-Farbe (Hex) oder Albedo-Textur (PNG/JPG) |
| Roughness | Glanz-Schärfe, 0 (Spiegel) → 1 (matt) |
| Metallic | Dielektrikum vs. Metall, 0 → 1 |
| Normal-Map | Optional — PNG für Surface-Detail |
| Linetype | Gebundener Linetype für Schnittlinien (Bezug zu .lin) |
Rhino-Renderer (Cycles) liest die PBR-Daten direkt — kein separater Material-Editor nötig.
## Material/Ebene-Separation
Eine bewusste DOSSIER-Konvention:
```text
Material ──────▶ Wie sieht's aus? (Albedo, Roughness, …)
Layer ──────▶ Wozu gehört's? (10_GRUNDRISSE::EG::20_WAENDE)
```
Die beiden bleiben **getrennt** — ein Material kann auf vielen Layern verwendet werden, ein Layer kann viele Materialien tragen. Das vermeidet die typische Rhino-Falle, in der Layer-Farbe und Material-Farbe konkurrieren.
## Auto-Regen
Wird ein Material editiert (Farbe geändert, Textur ersetzt), regenerieren sich alle Smart-Elemente, die es verwenden, automatisch:
1. `materialien_bridge` schreibt das neue PBR-Set in Rhinos `RenderMaterial`-Tabelle
2. `elemente_bridge._regenerate_all_with_material(material_id)` läuft über alle Wände, Decken, … mit diesem Material
3. Joint-Cache wird invalidiert (Material kann die Lineweight bei Anschnitten beeinflussen)
Spürbare Latenz < 200 ms für Projekte unter 500 Smart-Elementen.
## Linetypes (.lin-Import)
Der **Linientypen**-Tab in PROJECT-SETTINGS importiert AutoCAD-kompatible `.lin`-Files:
```text
*BORDER,Border __ __ . __ __ . __ __ . __ __ . __ __ .
A,.5,-.25,.5,-.25,0,-.25
```
Der Parser zerlegt die Sequenz und schreibt eine native `Rhino.DocObjects.Linetype` ins Dokument. Skalierung wird projektweit gesetzt und folgt dem aktiven Massstab (siehe [Massstab](../massstab)).
Pattern-Editor visualisiert die Sequenz mit Drag-Handles für Strich/Lücke-Längen — `.lin`-Import und Editor schreiben in denselben Datentyp, sind also austauschbar.
## Hatches (.pat-Import)
Der **Schraffuren**-Tab importiert AutoCAD-Hatches:
```text
*ANSI31,ANSI Iron, Brick, Stone masonry
45,0,0,0,.125
```
Pattern werden als `Rhino.DocObjects.HatchPattern` registriert und stehen Section-Styles, Layer-Properties und Gestaltung-Panel direkt zur Verfügung.
**Pattern + Scale + Rotation-Signatur** wird im GESTALTUNG-Panel zur automatischen Layer-Erkennung verwendet (siehe [Gestaltung](../gestaltung)).
## Material-Cache
Beim Lesen wird über eine **Hex → MaterialIndex-Map** gecacht. Stale-Check bei jedem Read:
- Existiert der Material-Index noch im Rhino-Doc?
- Hat sich der Hex-Wert verändert?
- Wurde das Material extern via Rhinos Material-Editor gelöscht?
Bei Stale wird die Map neu aufgebaut. Manuell triggerbar via [Werkzeuge → Material-Cache leeren](../werkzeuge).
{{< callout type="info" >}}
Texturen werden **relativ zur `.3dm`** referenziert. Wenn das Projekt verschoben wird, müssen Texturen mitwandern — Dossier zeigt fehlende Texturen mit einem warnenden Placeholder-Thumbnail in der Library-Liste an.
{{< /callout >}}
content/features/project-settings.md
+95
View File
@@ -0,0 +1,95 @@
---
title: Project-Settings
linkTitle: Project-Settings
weight: 4
---
Das **PROJECT-SETTINGS**-Panel ist der zentrale Dialog für alles, was projektweit konsistent sein muss. Fünf Tabs, alle Daten im `.3dm` — keine externen Config-Files.
## Übersicht
| Tab | Inhalt |
|-------------------|-----------------------------------------------------------------------|
| Voreinstellungen | Bürodaten, Projektdaten, Phase, Plankopf-Defaults |
| Materialien | PBR-Materialien mit Texturen, Farbe, Roughness, Metallic |
| Linientypen | Custom-Linetypes per Skalierung und Pattern-Editor (.lin-Import) |
| Schraffuren | Hatch-Pattern-Library mit Scale, Rotation und .pat-Import |
| Symbole | Symbol-Library mit 2D+3D Pair-Files (siehe [Symbol-Library](../symbol-library)) |
Alle Tabs schreiben direkt in das `.3dm` (User-Strings am Document-Level) und in eine begleitende `dossier.project.json` neben der Datei.
## Tab 1 — Voreinstellungen + Projektdaten
Bürodaten und Projektdaten gehören zusammen ins Plankopf-System. Felder:
### Bürodaten
| Feld | Beschreibung |
|----------------|---------------------------------------------|
| Bürologo | PNG/SVG-Pfad, wird im Titelblock eingesetzt |
| Büroname | Volle Firmenbezeichnung |
| Adresse | Strasse, PLZ, Ort |
| Kontakt | Telefon, Email, Website |
### Projektdaten
| Feld | Beschreibung |
|-------------------|-----------------------------------------------------------|
| Projektnummer | Frei vergeben — `2026-001`, `WBB-123` |
| Projektname | Kurz-Titel |
| Bauadresse | Strasse, PLZ, Ort der Baustelle |
| Bauherr | Name + Adresse |
| Phase | Vorprojekt · Bauprojekt · Ausführung · Wettbewerb |
| Höhe ü. Meer | Auto-Prefill aus [Swisstopo](../swisstopo-osm) AlMo-DOM |
Diese Werte stehen allen Layout-Blättern als Titelblock-Variablen zur Verfügung — pro Plan ändert sich nur die Plannummer, der Rest ist projektweit konsistent.
## Tab 2 — Materialien
Siehe [Material-Library](../materialien) für die volle Doku.
Kurz: PBR-Materialien mit Albedo-Textur, Roughness, Metallic, Normal-Map und Linetype-Bindung. Auto-Regen bei Material-Change in der ganzen Geschoss-Hierarchie.
## Tab 3 — Linientypen
Custom-Linetypes pro Projekt:
- **Pattern-Editor** — Strich/Lücke-Sequenz visuell editieren
- **Skalierung** — pro Linetype und global (mit Massstab-Bezug)
- **.lin-Import** — AutoCAD-kompatible Linetype-Files direkt einlesen
Linetypes werden in das `.3dm` geschrieben (Rhino-native `Linetype`-Tabelle) und stehen sofort allen Layer-Eigenschaften zur Verfügung.
## Tab 4 — Schraffuren
Hatch-Pattern-Verwaltung:
- **Pattern-Library** mit Standardbestand (Mauerwerk, Stahlbeton, Holz, Dämmung, …)
- **.pat-Import** — AutoCAD-Hatches einlesen
- **Scale + Rotation** pro Pattern projektweit setzen, lokal überschreibbar
Hatches werden mit Section-Styles verknüpft (siehe [Schnitte & Ansichten](../schnitte-ansichten)) — Anschnitte beziehen das Pattern automatisch aus den Layer-Properties.
## Tab 5 — Symbole
Siehe [Symbol-Library](../symbol-library) für die volle Doku.
Kurz: 2D+3D Pair-Files mit Satellite-Picker, Multi-Format-Import, Auto-Thumbnails als Base64-PNG.
## Datenhaltung
```text
dossier.project.json (neben der .3dm)
├── buero — Logo, Name, Adresse
├── projekt — Nummer, Name, Phase, Bauadresse, Höhe ü. M
├── bauherr — Name, Adresse
└── settings — Plankopf-Defaults, Massstab, …
.3dm (Document-UserStrings + Rhino-native Tabellen)
├── dossier_materialien — JSON-Liste der Material-IDs + PBR-Daten
├── dossier_linetypes — Linetype-Tabelle (Rhino-native)
├── dossier_hatches — Hatch-Pattern-Tabelle (Rhino-native)
└── dossier_symbols — JSON-Liste der Symbol-IDs + Thumbnail-Cache
```
Eine `.3dm` bleibt eine Datei — Backup heisst `.3dm` + `dossier.project.json` kopieren.
content/features/raeume-sia416.md
+74
View File
@@ -0,0 +1,74 @@
---
title: Räume nach SIA 416
linkTitle: Räume (SIA 416)
weight: 7
---
Räume sind ein eigener Smart-Element-Typ mit **SIA-416-Kategorisierung**. Die Klassifikation lebt als Metadatum am Raum, nicht als sichtbare Farbe — die Plandarstellung bleibt sauber.
## Kategorien
| Code | Kategorie | Beispiele |
|------|----------------------------|------------------------------------------|
| HNF | Hauptnutzfläche | Wohnen, Schlafen, Büro, Verkauf, … |
| NNF | Nebennutzfläche | Keller, Estrich, Garage, Technik |
| FF | Funktionsfläche | Lift, Schacht, Haustechnik-Raum |
| VF | Verkehrsfläche | Korridor, Treppenhaus, Eingangsbereich |
| KF | Konstruktionsfläche | Wandquerschnitte, Schächte |
Konstanten in `elemente.py`:
```python
SIA_KATEGORIEN = {
"HNF": ("#a8d4c5", "Hauptnutzflaeche"),
"NNF": ("#d4c8a8", "Nebennutzflaeche"),
"FF": ("#c8a8d4", "Funktionsflaeche"),
"VF": ("#a8b8d4", "Verkehrsflaeche"),
}
```
## Standard-Modus vs. Flächen-Modus
**Standard** — Räume sind im Plan **transparent**. Nur der Raum-Stempel ist sichtbar (Bezeichnung + Fläche).
**Flächen-Modus** — Räume erhalten eine farbliche Überlagerung nach SIA-Kategorie. Umschaltung in der OBERLEISTE über Display-Mode-Switch.
## Raum-Stempel
Jeder Raum trägt einen Stempel mit:
- Raum-Bezeichnung (frei vergeben — `Wohnen`, `Schlafen 1`, `WC Damen`)
- Fläche in m² (automatisch aus Outline berechnet)
- Optional: Raum-Nummer und SIA-Kategorie
Stempel-Position automatisch im Centroid, manuell verschiebbar.
## Auswertung
### Raumliste
Export aller Räume als CSV mit:
| Geschoss | Nr | Bezeichnung | SIA | Fläche m² | Höhe m |
|---|---|---|---|---|---|
| EG | 1.01 | Wohnen | HNF | 28.4 | 2.50 |
| EG | 1.02 | Küche | HNF | 12.1 | 2.50 |
| EG | 1.03 | Korridor | VF | 6.8 | 2.50 |
| … | … | … | … | … | … |
### Flächen-Schema
Aggregierte Tabelle pro Geschoss:
| Geschoss | HNF m² | NNF m² | FF m² | VF m² | Summe |
|---|---|---|---|---|---|
| UG | — | 84.2 | 4.5 | 12.0 | 100.7 |
| EG | 102.4 | — | — | 18.6 | 121.0 |
| 1OG | 98.1 | — | — | 16.8 | 114.9 |
| **Total** | **200.5** | **84.2** | **4.5** | **47.4** | **336.6** |
Beide direkt aus den Raum-Metadaten generiert — keine separate Erfassung nötig.
## Integration ins Plan-Set
Raumliste und Flächen-Schema können als eigenes **Übersichts-Blatt** ins Plan-Set integriert werden (über LAYOUTS-Panel) oder als CSV exportiert werden.
content/features/schnitte-ansichten.md
+79
View File
@@ -0,0 +1,79 @@
---
title: Schnitte & Ansichten
linkTitle: Schnitte & Ansichten
weight: 3
---
Schnitte und Ansichten sind in DOSSIER **eigenständige Smart-Elemente** auf dem 3D-Modell — keine projizierten 2D-Pläne. Die vollständige Section-Style-API aus Rhino 8 wird direkt angesteuert.
## Schnitt-Perspektive
Schnitte werden über eine **Section-Plane** mit Position, Normal und Tiefe definiert. Die Section-Plane lebt im Modellraum, ist verschiebbar und folgt jeder Geometrie-Änderung automatisch.
Pro Schnitt einstellbar:
| Eigenschaft | Beschreibung |
|-------------------|-------------------------------------------------------------|
| Schnitt-Tiefe | Wie viel hinter der Plane sichtbar bleibt |
| Hidden-Line | Verdeckte Kanten ausblenden |
| Anschnitt-Hatch | Pattern + Farbe + Lineweight pro Layer |
| Beschriftung | Schnitt-Name (`Schnitt A-A`), Massstab im Plankopf-Bezug |
Schnittlinie wird automatisch in Grundriss-Layouts projiziert.
## Section-Style-API
Mit der CPython-3-Migration wurde `Rhino.DocObjects.SectionStyle()` direkt instanziierbar — `layer.SetCustomSectionStyle()` ist verfügbar. Das war der **konkrete Anlass** für den Sprung von IronPython 2.7 auf CPython 3.
Pro Layer wird gespeichert:
- **Schnittlinien-Stil** — Farbe, Lineweight, Linetype für gerade angeschnittene Kanten
- **Hatch-Pattern** — Pattern, Scale, Rotation, Farbe für die Schnittfläche
- **Hidden-Line-Stil** — separate Eigenschaften für verdeckte Geometrie
- **Anschnitt-Tiefe** — wie tief in den Layer "hineingeschnitten" wird
Die Section-Style-Daten leben als `Rhino.DocObjects.SectionStyle` direkt am Layer im `.3dm` — keine externen Konfigs.
## Ansichten (Elevations)
Ansichten sind Spezialfall einer Section-Plane:
- **Parallel-Projektion** statt Perspektive
- **Section-Plane** liegt vor der Geometrie (nicht durch sie hindurch)
- **Auto-Direction** aus der Kompass-Richtung (Nord, Ost, Süd, West) oder benutzerdefiniert
Werden über AUSSCHNITTE als Named View gespeichert und auf Layout-Blätter gezogen.
## Cross-Module-Verhalten
```text
SCHNITTE ──Section-Plane──▶ Display-Mode "Dossier-Plan"
│ │
│ ▼
│ Hidden-Line + Section-Hatch
▼
AUSSCHNITTE ──save with section──▶ LAYOUTS
│
▼
Plankopf-Feld "Massstab + Schnitt-Name"
```
## Display-Mode-Kopplung
Der [Massstab-Modus](../massstab) **Dossier-Plan** wertet aktive Section-Planes automatisch aus:
- Anschnitt-Geometrie wird mit dem Layer-Section-Hatch belegt
- Hidden-Line wird über die Plane berechnet (Rhino-natives Verfahren)
- Background weisst, Linien schwarz — direkt plottbar
## Convention
Schnittlinien-Namen folgen der Bauplan-Konvention:
| Beschriftung | Verwendung |
|--------------|---------------------------------------------|
| `A-A`, `B-B` | Längs- und Querschnitte |
| `C-C`, `D-D` | Treppenhaus, Schächte, Sonderschnitte |
| `D1`, `D2` | Detailschnitte (1:5 oder 1:20) |
Detailschnitt-Bereich kann als Rechteck im Grundriss markiert werden — Layout-Blatt zieht automatisch den Section-Cut + Detail-Beschriftung.
content/features/smart-elemente.md
+101
View File
@@ -0,0 +1,101 @@
---
title: Smart-Elemente
linkTitle: Smart-Elemente
weight: 2
---
Smart-Elemente sind parametrische Bauteile mit dem **Source ↔ Volume Pattern**: eine editierbare Source-Geometrie und ein automatisch generiertes Volumen.
## Pattern
```text
Source-Geometrie (vom User editiert)
│
▼ Regeneration bei Change
Volume (Brep, vom Plugin verwaltet)
```
Wird die Source verschoben oder verformt, regeneriert das Volumen automatisch — Wand-Joints, Decken-Aussparungen und Öffnungs-Cutouts werden mitgeführt.
## Bauteil-Typen
### Wände (Wand-System v1)
| Source | Volume |
|-------------------------|-----------------------------------------------------|
| Polyline (mit Bögen) | Brep mit Dicke × Höhe, Geschoss-OKFF als Basis |
**Polyline-Achse statt Einzel-Segmente:** Eine Wand ist ein zusammenhängender Polyline-Strang — gerade Teilstrecken, Bogen-Segmente und Knicke gehören zur selben Source. Joints zwischen Polylines werden weiterhin als Miter / T-Junction gerechnet, aber Knicke innerhalb einer Wand brauchen kein eigenes Joint-Setup mehr.
**Chain-Anchor:** Die Polyline trägt einen stabilen Anker auf einem festgelegten Knoten. Bei Modifikationen am Strang (verschieben, verlängern, Knoten einfügen) bleibt die Wand-Identität an diesem Anker — Material, UserStrings und Joint-Verknüpfungen wandern mit.
**Native Rhino-Grips:** Knoten der Polyline-Achse erscheinen direkt als Rhino-Grips. Verschieben eines Knotens triggert Volume-Regeneration plus Joint-Re-Calc in einem Idle-Tick — keine separate Edit-Mode-UI nötig.
**Cmd+Z stabil:** Undo/Redo über alle Joint-Operationen ist garantiert konsistent. Der Joint-Cache wird über die Polyline-Achse rekonstruiert, nicht aus dem stale Pre-Undo-State.
**Joint-Cache** pro Geschoss (`_JOINTS_CACHE_KEY`), invalidiert bei Add/Delete und nach Polyline-Edits über den Grip-Handler.
**Wand-Typen:** Tragwand · Trennwand · Brandwand · Aufschüttung
**Material-Cache:** Hex → MaterialIndex, stale-Check beim Lesen — der Cache wird beim Material-Delete in Rhino automatisch invalidiert (siehe [Materialien](../materialien)).
### Decken & Dächer
| Source | Volume |
|------------|---------------------------------------------------------|
| Outline | Brep-Extrusion mit konstanter Stärke, OKFF + Geschoss-Höhe |
- Aussparungen für Schächte als Sekundär-Curves
- Dächer mit Neigung (Pultdach, Satteldach, Walmdach)
### Öffnungen (Fenster / Türen)
| Source | Volume |
|---------|-----------------------------------------------------|
| Punkt | Rahmen + Sims + Flügel, schneidet Wand-Volumen aus |
- Bibliothek mit Standard-Typen (Holz / Aluminium / Kunststoff)
- Brüstungshöhe und Sturzhöhe pro Element parametrisch
- Cutout im Wand-Volumen wird automatisch nachgeführt
### Treppen
Geometrie-Typen:
- **Gerade Treppe** — Anfangs-/Endpunkt, Steigung
- **L-Treppe** — Dreipunkt, Zwischenpodest automatisch
- **Wendeltreppe** — Zentrum, Radius, Steigungswinkel
### Tragwerk
- **Stützen** — Punkt, Profil (Rechteck / Rund / I)
- **Träger** — Linie, I-Profil mit Schenkel-Höhe und -Breite
- **I-Profile** — Standardisierte Querschnitte (HEA / HEB / IPE)
## UI-Workflow
Im **ELEMENTE**-Panel:
1. Bauteil-Typ wählen (Wand, Decke, Öffnung, …)
2. Variante wählen (Tragwand, Pultdach, Holzfenster, …)
3. Source in Rhino zeichnen
4. Volumen erscheint sofort
## Properties
Das **ELEMENTE-PROPERTIES**-Panel zeigt für die Selektion:
- Element-Typ und -Variante
- Dicke / Höhe / Position
- Geschoss-Zuordnung
- UserStrings (`dossier_element_id`, `dossier_element_type`)
Änderungen werden direkt geschrieben — keine Apply-Button-Logik.
## Übersicht
Das **ELEMENTE-ÜBERSICHT**-Panel listet alle Smart-Elemente im Dokument tabellarisch — gefiltert nach Geschoss, Typ und Material. Ideal für Mengen-Audits und Konsistenz-Checks.
{{< callout type="warning" >}}
`elemente.py` ist **7'244 LOC** und enthält BIM-Logik aus echten Projekten. Nicht ohne expliziten Auftrag und Test-Plan refaktorisieren.
{{< /callout >}}
content/features/swisstopo-osm.md
+77
View File
@@ -0,0 +1,77 @@
---
title: Swisstopo & OpenStreetMap
linkTitle: Swisstopo & OSM
weight: 13
---
DOSSIER bringt **georeferenzierten Hintergrund** direkt in Rhino — über Schweizer Landeskarten-Tiles (Swisstopo) oder OpenStreetMap-Daten.
## SWISSTOPO-Panel
Direkter Import von Tile-Layern aus [api3.geo.admin.ch](https://api3.geo.admin.ch/):
| Layer | Verwendung |
|-------------------------------|-------------------------------------|
| Landeskarte 1:25'000 | Übersicht, Situation |
| Landeskarte 1:10'000 | Quartier-Plan |
| Orthofoto | Luftbild als Hintergrund |
| AV-Daten (Kataster) | Grundstücksgrenzen |
| AlMo-DOM (Höhenmodell) | Geländedaten als Höhenkurven |
### Workflow
{{% steps %}}
### Adresse oder Koordinate eingeben
Adresse oder LV95-Koordinaten ins SWISSTOPO-Panel eingeben. Karte zoomt auf die Stelle. Bei Adressen wird über die Swisstopo-Geocoder-API aufgelöst und das Ergebnis in LV95 zurückgegeben.
### Adress-Prefill aus Projektdaten
Liegt eine Adresse in der `dossier.project.json` (Bauherr-Adresse oder Bauadresse), wird sie direkt als Default ins SWISSTOPO-Panel übernommen. Ein Klick auf **Lokalisieren** zoomt sofort auf den Standort, ohne nochmal tippen zu müssen.
### Layer wählen
Tile-Layer aus der Liste auswählen, gewünschte Zoomstufe einstellen.
### Importieren
Tiles werden als PictureFrame in Rhino platziert — auf Layer `40_SITUATION`, georeferenziert in LV95 (alternativ WGS84).
### Terrain & m.ü.M
Wird **AlMo-DOM (Höhenmodell)** als Layer gewählt, importiert Dossier nicht nur die Höhenkurven, sondern ermittelt für den Projekt-Zentrum-Punkt die exakte **Höhe über Meer** (m.ü.M). Dieser Wert wird in der `dossier.project.json` als `projekt.hoehe_ueber_meer` abgelegt und vom Titelblock automatisch übernommen.
Optional kann aus den DOM-Daten ein **Terrain-Mesh** rekonstruiert werden — als Hintergrundgeometrie für Schnitte und Visualisierungen.
### Auf 0 verschieben
Optional: Projekt-Zentrum auf Welt-Nullpunkt verschieben, Tiles werden mit verschoben — kleine Koordinaten für die Geometrie, aber Real-World-Bezug ist als LV95-Offset und m.ü.M-Wert in der `dossier.project.json` gespeichert.
{{% /steps %}}
## OSM-Panel
Import von OpenStreetMap-Vektordaten:
- **Strassen** — als Curves auf Layer `40_SITUATION::STRASSEN`
- **Gebäude** — als Outlines mit Höhe (aus `building:levels`) auf `40_SITUATION::GEBAEUDE`
- **Grünflächen** — als Hatches auf `40_SITUATION::GRUEN`
- **Höhenkurven** — wenn SRTM-Daten vorhanden
Quelle: [Overpass API](https://overpass-api.de/). Cache lokal in `~/Library/Application Support/ch.gabrielevarano.Dossier/osm_cache/`.
### Bounding-Box
Im OSM-Panel werden Min/Max-Koordinaten der Bounding-Box gesetzt oder per Rechteck in Rhino gepickt. Daten werden für die Box geladen.
## Kombination
Typischer Workflow für die **Situations-Planung**:
1. Swisstopo Landeskarte 1:5'000 als Hintergrund-Bitmap
2. OSM-Strassen als editable Curves drüber
3. AV-Daten als Grundstücksgrenze
4. Eigenes Projekt mit Smart-Elementen plazieren
Alles auf `40_SITUATION`-Sublayern getrennt — über die OBERLEISTE schnell sichtbar/unsichtbar schaltbar.
content/features/symbol-library.md
+101
View File
@@ -0,0 +1,101 @@
---
title: Symbol-Library
linkTitle: Symbol-Library
weight: 6
---
Die Symbol-Library lebt im **PROJECT-SETTINGS**-Tab "Symbole" und macht ein klassisches Architekturbüro-Problem zentral verwaltbar: Möbel, Sanitär-Apparate, Bäume, Autos, technische Symbole — überall im Modell, aber konsistent in der Darstellung.
## 2D+3D Pair-Files
Jedes Symbol besteht aus zwei verknüpften Files:
```text
sofa-3sitz.3dm — 3D-Modell (Block-Definition)
sofa-3sitz.2d.3dm — 2D-Plandarstellung (Block-Definition)
```
Beim Plazieren entscheidet der View-Type:
- **3D-View / Perspektive** → 3D-File wird verwendet
- **Top-View im Grundriss** → 2D-File wird verwendet
- **Section-Plane aktiv** → Section-Cut wird aus dem 3D-File abgeleitet
So bleibt ein Sofa im Schnitt eine sauber gezeichnete 2D-Plandarstellung, in der Visualisierung aber ein vollständiges 3D-Möbel.
## Satellite-Picker
Statt Symbole in einem schwergewichtigen Browser zu suchen, öffnet DOSSIER einen **Satellite-Picker** — ein eigenständiges, kleines Fenster mit Live-Thumbnails:
- Floating-Window neben dem Modellraum
- Filter nach Kategorie (Möbel · Sanitär · Vegetation · Verkehr · …)
- Klick auf Thumbnail → Symbol wird in Rhino plaziert (Drag-Place)
- Mehrfach-Plazierung in Serie ohne Picker zu schliessen
Bleibt offen während aktivem Modell-Edit — typischer Workflow für Wohnungs-Möblierung.
## Multi-Format-Import
Symbole müssen nicht in `.3dm` vorliegen. CRUD im PROJECT-SETTINGS-Symbole-Tab unterstützt:
| Format | Verwendung |
|--------------|-----------------------------------------------------|
| `.3dm` | Rhino-native (Pair-Files werden so behandelt) |
| `.dwg` | AutoCAD-Möbelbibliotheken |
| `.obj` | Generische 3D-Modelle (z.B. von Polantis, Free3D) |
| `.fbx` | 3D-Modelle aus DCC-Tools |
| `.dae` | Collada — SketchUp-Export |
| `.stl` | Mesh-only — Grobgeometrie |
Beim Import wird das File in den projektbezogenen `symbols/`-Ordner kopiert, ein Block in der Rhino-Block-Tabelle registriert und das Thumbnail generiert.
## Auto-Thumbnails (Base64-PNG)
Thumbnails werden **automatisch** beim Import erzeugt:
1. Symbol wird headless in einer 256×256-Viewport gerendert
2. Iso-Ansicht für 3D-Files, Top-Ansicht für 2D-Files
3. PNG wird als **Base64-String** in die `dossier.project.json` geschrieben
Vorteil von Base64: Thumbnails sind teil der Projekt-Konfiguration — der Satellite-Picker kann sie ohne File-IO im Hintergrund anzeigen, und Library-Sharing wird trivial (Config kopieren = Thumbnails mitkopiert).
Cache-Größe pro Symbol typisch 4–12 KB.
## CRUD-Operationen
Volle Verwaltung im PROJECT-SETTINGS-Symbole-Tab:
- **Create** — Import-Button öffnet File-Picker, Format wird auto-detected
- **Read** — Liste mit Thumbnails, Filter nach Kategorie, Suche im Namen
- **Update** — Symbol-Eigenschaften (Name, Kategorie, 2D-Pair zuordnen) editieren
- **Delete** — Block-Definition aus Rhino entfernen, File aus `symbols/`-Ordner löschen, JSON-Eintrag entfernen
Lösch-Operation prüft, ob das Symbol im Modell verwendet wird, und bietet Replace-Optionen statt blockierender Hard-Delete.
## Datenhaltung
```text
projekt-ordner/
├── projekt.3dm
├── dossier.project.json
│ └── symbols: [
│ { id: "sofa-3sitz", name: "Sofa 3-Sitz",
│ file_3d: "symbols/sofa-3sitz.3dm",
│ file_2d: "symbols/sofa-3sitz.2d.3dm",
│ thumbnail: "data:image/png;base64,iVBORw0KGgo...",
│ category: "moebel" }
│ ]
└── symbols/
├── sofa-3sitz.3dm
├── sofa-3sitz.2d.3dm
├── tisch-esstisch.3dm
└── …
```
Symbol-Files relativ referenziert — Projekt verschieben = Symbole ziehen mit.
## Roadmap
**Library Phase C** (geplant): Cloud-Sync via GitHub-Releases — Team-Sharing einer projektübergreifenden Symbol-Library mit semantischer Versionierung. Siehe [Roadmap](../../docs/roadmap).
**Satellite-Windows-Restyle** (geplant): alle Satellite-Windows (Symbol-Picker, Material-Picker, …) im einheitlichen Pill-Style. Siehe [Roadmap](../../docs/roadmap).
content/features/text-editor.md
+71
View File
@@ -0,0 +1,71 @@
---
title: DOSSIER-Text Editor
linkTitle: Text-Editor
weight: 14
---
WYSIWYG Rich-Text Editor für Rhino-TextEntities mit RTF-Export. Im **TEXT-EDITOR**-Panel: Frame picken, formatieren, schreiben.
## Workflow
{{% steps %}}
### Text-Frame in Rhino picken
Im Modell ein Text-Frame (Rechteck oder TextEntity) selektieren — der Editor öffnet sich mit dem Frame als Container.
### Formatieren
Im React-WYSIWYG:
- **Fett** · *Kursiv* · <u>Underline</u> · ~~Strikethrough~~
- Schrift wählen aus den installierten System-Fonts
- Tab-Stops setzen
- Zeilenumbrüche
### Speichern
Der Editor schreibt RTF zurück in die TextEntity. Rhinos eingebauter Parser rendert das Ergebnis im Modellraum.
{{% /steps %}}
## RTF-Support
Rhinos TextEntity-RTF-Parser unterstützt:
| Code | Bedeutung |
|-----------|---------------------------------------|
| `\b` | Bold |
| `\i` | Italic |
| `\ul` | Underline |
| `\strike` | Strikethrough |
| `\fN` | Font (N = Font-Index in Font-Table) |
| `\tab` | Tab-Stop |
| `{}` | Gruppe |
| `\par` | Absatz (zwischen Gruppen für Newline) |
{{< callout type="warning" >}}
**Kein `\fs`** — eine TextEntity hat global eine Schriftgröße, keine per-Segment-Sizes. Wenn unterschiedliche Größen nötig sind, brauchst du separate TextEntities.
{{< /callout >}}
Quirks bei Newlines und Zeichen-Replace sind in `_runs_to_rtf` (`rhino/text_editor.py`) dokumentiert.
## TEXT-CREATE Sub-Panel
Für neue Text-Elemente:
- **Text-Styles** als Presets (`Plankopf`, `Notiz`, `Legende`, `Bemassung`)
- **Font-Apply** — Schrift global oder pro Selektion ändern
- **Selection-Settings** — Größe, Farbe, Justification für Multi-Selektion
Konsistenz über das ganze Projekt — Stile lassen sich aus einem Projekt in ein anderes übertragen.
## Plan-Beschriftung
Typische Anwendungen:
- Plankopf-Text (Adresse, Bauherr)
- Legenden im Modellraum
- Raum-Stempel-Override (statt Standard-Stempel)
- Schnitt-Beschriftungen ("Schnitt A-A", "M 1:50")
- Detail-Verweise mit Pfeil und Bezugsnummer
content/features/werkzeuge.md
+59
View File
@@ -0,0 +1,59 @@
---
title: Werkzeuge
linkTitle: Werkzeuge
weight: 15
---
Das **WERKZEUGE**-Panel ist eine Sammlung von Batch- und Wartungs-Tools. Schmal gehalten (58 LOC) — keine eigene Logik, nur Knöpfe für häufige Operationen.
## Verfügbare Tools
### Cache-Verwaltung
| Tool | Effekt |
|---------------------|------------------------------------------------------------|
| **Joint-Cache leeren** | `_dossier_joints_cache` invalidieren — bei verlorenen Joints |
| **Material-Cache leeren** | Hex→MaterialIndex-Cache resetten — nach Material-Delete in Rhino |
| **Hatch-Link leeren** | UUID→Hatch-Bindung verwerfen — nur als letzter Resort |
### Layer-Bereinigung
- **Leere Layer entfernen** — Sublayer ohne Objekte werden gelöscht
- **Ungenutzte Geschosse aufräumen** — Sublayer für gelöschte Geschosse entfernen
- **Default-Hierarchie wiederherstellen** — fehlende Standard-Layer (`10_GRUNDRISSE`, …) ergänzen
Siehe `clean.py` und `clean_layers.py`.
### Section-Style-Reset
Setzt alle Layer-spezifischen Section-Styles auf Default zurück — nützlich nach Plot-Style-Experimenten.
### Panel-Reset
`_reset_panels.py` — alle Bridges und Listener neu registrieren, ohne Rhino-Restart. Bei Python-Code-Änderungen nötig:
```text
_RunPythonScript <DOSSIER_PFAD>/rhino/_reset_panels.py
```
### Section-Inspection
`inspect_section.py` — Debug-Tool: zeigt für die aktive Section-Plane alle gefundenen Schnittkanten mit ihren Layer-Zuordnungen.
## ABOUT-Panel
Eigenes Sub-Panel mit:
- Plugin-Version
- Python-Runtime-Info (`sys.version`)
- Lizenz-Info
- Build-Datum
- Update-Check (über Launcher)
## Workflow-Position
WERKZEUGE läuft als eigenständiger Panel-Eintrag in der OBERLEISTE — wird selten direkt benötigt, aber praktisch wenn Caches stale werden oder ein Layer-Layout aus Versehen kaputt geht.
{{< callout type="info" >}}
Die meisten Tools sind **idempotent** — mehrfach aufrufen schadet nicht. Cache-Operationen invalidieren immer atomar, kein Halbzustand möglich.
{{< /callout >}}