Initial commit: DOSSIER Hugo website
This commit is contained in:
@@ -0,0 +1,143 @@
|
||||
---
|
||||
title: DOSSIER
|
||||
layout: hextra-home
|
||||
toc: false
|
||||
---
|
||||
|
||||
{{< hextra/hero-badge >}}
|
||||
<div class="hx:w-2 hx:h-2 hx:rounded-full" style="background: #5fa896; box-shadow: 0 0 8px rgba(95,168,150,0.55);"></div>
|
||||
<span>Pre-Release 0.1.0 · Aktiv in Entwicklung</span>
|
||||
{{< /hextra/hero-badge >}}
|
||||
|
||||
<div class="hx:mt-8 hx:mb-6">
|
||||
<div class="dossier-logo-card">
|
||||
<div class="dossier-logo-text">DOSSIER</div>
|
||||
<div class="dossier-logo-sub">Rhino 8 Plugin · Teil von OpenBureau</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="hx:mb-12">
|
||||
{{< hextra/hero-subtitle >}}
|
||||
Ein Design-Studio für Rhino — smarte Bauteile, Schnitte, Plan-Vorlagen, Materialien, Symbole und SIA-416-Räume. Modell-Qualität und Planabgabe direkt aus 3D, ohne BIM-Cloud.
|
||||
{{< /hextra/hero-subtitle >}}
|
||||
</div>
|
||||
|
||||
<div class="dossier-hero-actions">
|
||||
<a href="/docs/" class="dossier-btn dossier-btn-primary">Erste Schritte</a>
|
||||
<a href="https://git.kgva.ch/karim/DOSSIER" class="dossier-btn dossier-btn-secondary">Quellcode ↗</a>
|
||||
</div>
|
||||
|
||||
<div class="dossier-meta hx:mb-12">
|
||||
<span class="dossier-meta-item">AGPL-3.0</span>
|
||||
<span class="dossier-meta-item">Rhino 8+</span>
|
||||
<span class="dossier-meta-item">macOS & Windows</span>
|
||||
<span class="dossier-meta-item">CPython 3.9</span>
|
||||
<span class="dossier-meta-item">Open Source</span>
|
||||
</div>
|
||||
|
||||
<div class="hx:mt-12 hx:mb-8 hx:text-center">
|
||||
<p style="font-size: 10px; letter-spacing: 0.2em; text-transform: uppercase; color: var(--dossier-accent); margin-bottom: 12px;">ANSATZ</p>
|
||||
<h2 style="font-family: 'Playfair Display', serif; font-size: clamp(26px, 3.5vw, 40px); font-weight: 400; line-height: 1.2; margin: 0 auto 16px; max-width: 580px;">Aus Rhino ein vollständiges Design-Studio machen</h2>
|
||||
<p style="font-size: 13px; line-height: 1.8; color: var(--dossier-text-3); max-width: 620px; margin: 0 auto;">Rhino ist stark in der Geometrie — Dossier ergänzt das, was bis zur Planabgabe fehlt: smarte Bauteile, Schnitte und Ansichten, projektweite Material- und Symbol-Library, SIA-Räume, Layout-Set und Beschriftung. Kein BIM-Datenbank-Overhead, keine Cloud — die `.3dm` bleibt die einzige Quelle.</p>
|
||||
</div>
|
||||
|
||||
{{< hextra/feature-grid >}}
|
||||
|
||||
{{< hextra/feature-card
|
||||
title="Smart-Elemente"
|
||||
subtitle="Wände, Decken, Dächer, Öffnungen, Treppen und Tragwerk als parametrische Bauteile mit Source ↔ Volume Pattern. Wand v1 mit Polyline-Achse, Chain-Anchor und nativen Rhino-Grips — Cmd+Z über alle Joints stabil."
|
||||
style="background: radial-gradient(ellipse at 50% 80%,rgba(95,168,150,0.10),hsla(0,0%,100%,0));"
|
||||
>}}
|
||||
|
||||
{{< hextra/feature-card
|
||||
title="Geschosse & Ebenen"
|
||||
subtitle="Multi-Geschoss-Clipping mit Top-View-Z-Guard und Snap-Bar pro Geschoss. Layer-Hierarchie (10_GRUNDRISSE/EG/WÄNDE, …) wird automatisch aufgebaut und mit den Smart-Elementen verknüpft."
|
||||
style="background: radial-gradient(ellipse at 50% 80%,rgba(95,168,150,0.08),hsla(0,0%,100%,0));"
|
||||
>}}
|
||||
|
||||
{{< hextra/feature-card
|
||||
title="Schnitte & Ansichten"
|
||||
subtitle="Schnitt-Perspektive mit voller Section-Style-API — Hatch-Pattern für Schnittflächen, Hidden-Line-Removal, Schnittlinien-Stil pro Layer. Anlass für die CPython-3-Migration."
|
||||
style="background: radial-gradient(ellipse at 50% 80%,rgba(95,168,150,0.12),hsla(0,0%,100%,0));"
|
||||
>}}
|
||||
|
||||
{{< hextra/feature-card
|
||||
title="Project-Settings (5 Tabs)"
|
||||
subtitle="Zentraler Dialog für Voreinstellungen + Projektdaten, Materialien (PBR + Texturen), Linientypen, Schraffuren und Symbole. Daten leben im .3dm — keine externen Konfigs."
|
||||
style="background: radial-gradient(ellipse at 50% 80%,rgba(95,168,150,0.10),hsla(0,0%,100%,0));"
|
||||
>}}
|
||||
|
||||
{{< hextra/feature-card
|
||||
title="Material-Library"
|
||||
subtitle="ArchiCAD-style List/Detail mit Auto-Regen, Materialvorschau und Material/Ebene-Separation. Linetypes per .lin- und Hatches per .pat-Import direkt ins Projekt."
|
||||
>}}
|
||||
|
||||
{{< hextra/feature-card
|
||||
title="Symbol-Library"
|
||||
subtitle="2D+3D Pair-Files mit Satellite-Picker. Multi-Format-Import (.3dm/.dwg/.obj/.fbx/.dae/.stl), automatische Base64-PNG-Thumbnails und CRUD direkt aus Rhino."
|
||||
>}}
|
||||
|
||||
{{< hextra/feature-card
|
||||
title="SIA-416 Flächen"
|
||||
subtitle="Räume mit HNF / NNF / FF / VF-Kategorisierung. Im Standardmodus transparent, im Flächenmodus farbliche Überlagerung. CSV-Export und aggregierte Schemata direkt aus der Klassifikation."
|
||||
>}}
|
||||
|
||||
{{< hextra/feature-card
|
||||
title="Layouts & PDF-Export"
|
||||
subtitle="Plan-Sets aus Named Views, Titelblock-Vorlagen mit Bürodaten aus dem Projekt, Stapelexport als Vektor-PDF oder PNG. Benennung und Reihenfolge folgen dem Planverzeichnis."
|
||||
>}}
|
||||
|
||||
{{< hextra/feature-card
|
||||
title="Massstab & Display-Modes"
|
||||
subtitle="Viewport-Skala 1:N mit Auto-DPI über CoreGraphics, PlotWeight-Synchronisation und Display-Mode-Kopplung an Ausschnitte. Display-Mode Dossier-Plan (Hidden-Line, weisser Hintergrund, Section-Hatch) in aktiver Entwicklung."
|
||||
>}}
|
||||
|
||||
{{< hextra/feature-card
|
||||
title="Gestaltung & Overrides"
|
||||
subtitle="Regelbasierte Overrides (Bedingung → Aktion), Plot-Sync für Farbe / Lineweight / Linetype / Hatch und Preset-Verwaltung cross-doc."
|
||||
>}}
|
||||
|
||||
{{< hextra/feature-card
|
||||
title="Ausschnitte & Kamera"
|
||||
subtitle="Viewport-Snapshots (Kamera + Display + Layer-Sichtbarkeit) als wiederherstellbare States. Verknüpfung an Massstab und Layout."
|
||||
>}}
|
||||
|
||||
{{< hextra/feature-card
|
||||
title="Swisstopo & OSM"
|
||||
subtitle="Schweizer Landeskarten-Tiles und OSM-Daten als georeferenzierter Hintergrund. Adress-Prefill aus Projektdaten, Terrain-Import als Höhenmodell und m.ü.M-Bezug für die Situation."
|
||||
>}}
|
||||
|
||||
{{< hextra/feature-card
|
||||
title="DOSSIER-Text Editor"
|
||||
subtitle="WYSIWYG Rich-Text Editor für TextEntities mit RTF-Export. Fett / Italic / Underline / Strike, Tab-Stops und Multi-Font-Support im Modellraum."
|
||||
>}}
|
||||
|
||||
{{< hextra/feature-card
|
||||
title="Dimensionen"
|
||||
subtitle="Bemassungs-Panel für Wand-Dicken, Geschoss-Höhen und Öffnungs-Masse. Konsistente Stile, automatische Aktualisierung bei Modell-Änderungen."
|
||||
>}}
|
||||
|
||||
{{< hextra/feature-card
|
||||
title="Werkzeuge"
|
||||
subtitle="Batch-Operationen für wiederkehrende Aufgaben — Layer-Bereinigung, Section-Style-Reset, Joint-Cache-Clear, Material-Index-Refresh."
|
||||
>}}
|
||||
|
||||
{{< hextra/feature-card
|
||||
title="Tauri-Launcher"
|
||||
subtitle="Standalone-App für Projekt-Verwaltung, Settings-Sync, Auto-Updates und Window-Layouts. System-Tray, file-based IPC zu Rhino — beide Apps laufen unabhängig voneinander."
|
||||
icon="sparkles"
|
||||
>}}
|
||||
|
||||
{{< /hextra/feature-grid >}}
|
||||
|
||||
<div class="dossier-stack-bar">
|
||||
<span class="dossier-stack-label">Aufgebaut auf</span>
|
||||
<div class="dossier-stack-items">
|
||||
<span class="dossier-stack-item">RhinoCommon</span>
|
||||
<span class="dossier-stack-item">CPython 3.9</span>
|
||||
<span class="dossier-stack-item">React + Vite</span>
|
||||
<span class="dossier-stack-item">Eto.Forms WebView</span>
|
||||
<span class="dossier-stack-item">Tauri 2</span>
|
||||
<span class="dossier-stack-item">AGPL-3.0</span>
|
||||
</div>
|
||||
</div>
|
||||
@@ -0,0 +1,38 @@
|
||||
---
|
||||
title: Dokumentation
|
||||
linkTitle: Dokumentation
|
||||
next: docs/erste-schritte
|
||||
weight: 1
|
||||
sidebar:
|
||||
open: true
|
||||
---
|
||||
|
||||
Willkommen zur DOSSIER-Dokumentation. DOSSIER ist ein **Rhino 8 Plugin** für architektonisches Entwerfen mit smarten Bauteilen — Teil von **OpenBureau**.
|
||||
|
||||
{{< cards >}}
|
||||
{{< card link="erste-schritte" title="Erste Schritte" icon="play" subtitle="Installation, Setup, erster Workflow." >}}
|
||||
{{< card link="../features" title="Features" icon="cube" subtitle="Alle Panels und ihre Funktionen." >}}
|
||||
{{< card link="../launcher" title="Launcher" icon="desktop-computer" subtitle="Standalone-App für Projekte und Settings." >}}
|
||||
{{< card link="architektur" title="Architektur" icon="template" subtitle="Module, Bridge-Pattern, Sticky-Storage." >}}
|
||||
{{< card link="roadmap" title="Roadmap" icon="map" subtitle="Erledigt, in Arbeit, geplant." >}}
|
||||
{{< card link="../faq" title="FAQ" icon="question-mark-circle" subtitle="Häufige Fragen und Antworten." >}}
|
||||
{{< /cards >}}
|
||||
|
||||
## Auf einen Blick
|
||||
|
||||
Dossier bündelt den gesamten architektonischen Workflow in Rhino:
|
||||
|
||||
- **Modellieren** mit smarten Bauteilen (Source ↔ Volume Pattern, Wand v1 mit Polyline-Achse)
|
||||
- **Strukturieren** über Geschosse, Multi-Geschoss-Clipping und eine automatische Layer-Hierarchie
|
||||
- **Schneiden & Anschauen** mit der vollen Section-Style-API und Schnitt-Perspektive
|
||||
- **Material- & Symbol-verwalten** projektzentral aus den Project-Settings (PBR-Texturen, 2D+3D-Symbol-Pairs)
|
||||
- **Auswerten** nach SIA 416 (HNF / NNF / FF / VF)
|
||||
- **Darstellen** mit Massstab, Display-Modes und Overrides
|
||||
- **Beschriften** mit Bemassung, Raumstempeln und Rich-Text
|
||||
- **Ausgeben** als Plan-Set in PDF oder PNG
|
||||
|
||||
## Laufzeit
|
||||
|
||||
DOSSIER läuft als **CPython 3.9** über Rhinos neuen Python-3-Engine. Die UI wird in einem React-WebView-Panel über Rhinos Eto.Forms-Layer eingebettet (inline via `LoadHtml`).
|
||||
|
||||
Lese die [Architektur-Übersicht](architektur) für Details zum Bridge-Pattern und den Sticky-Storage-Konventionen.
|
||||
@@ -0,0 +1,142 @@
|
||||
---
|
||||
title: Architektur
|
||||
linkTitle: Architektur
|
||||
weight: 2
|
||||
---
|
||||
|
||||
DOSSIER ist als **Plugin-Verbund** aufgebaut: jedes Feature lebt in einem eigenen Modul, alle teilen sich ein gemeinsames Bridge-Pattern für die React-↔-Python-Kommunikation.
|
||||
|
||||
## Module-Map
|
||||
|
||||
| Modul | LOC | Rolle |
|
||||
|----------------------|------:|----------------------------------------------------------------|
|
||||
| `panel_base.py` | 697 | Fundament: BaseBridge, WebView-IO, Panel-Registration, Icons |
|
||||
| `rhinopanel.py` | 798 | EBENEN — Zeichnungsebenen, Layer-Hierarchie, Presets |
|
||||
| `elemente.py` | 7'244 | ELEMENTE — Wände, Decken, Öffnungen, Treppen, Tragwerk, Räume |
|
||||
| `gestaltung.py` | 1'635 | GESTALTUNG — Selektions-Attribute (Farbe, Lineweight, Hatch) |
|
||||
| `oberleiste.py` | 981 | OBERLEISTE — Top-Bar, Display, Massstab, Snaps, Settings |
|
||||
| `massstab.py` | 1'096 | MASSSTAB — Viewport 1:N, Auto-DPI, PlotWeight |
|
||||
| `overrides.py` | 797 | Engine — regelbasierte Overrides (Bedingung → Aktion) |
|
||||
| `overrides_panel.py` | 226 | UI für Overrides-Engine |
|
||||
| `ausschnitte.py` | 708 | AUSSCHNITTE — Viewport-Snapshots (Kamera + Display + Layer) |
|
||||
| `dimensionen.py` | 613 | DIMENSIONEN — Bemassung (Wand-Dicken, Geschoss-Höhen, …) |
|
||||
| `layouts.py` | 749 | LAYOUTS — Plan-Editor, Titelblock, PDF-Export |
|
||||
| `werkzeuge.py` | 58 | WERKZEUGE — Quick-Tools (Batch) |
|
||||
| `layer_builder.py` | 436 | Helper — Ebenen-Hierarchie aufbauen, Sublayer-Sync |
|
||||
| `startup.py` | 136 | Init — liest `dossier.project.json`, lädt Module selektiv |
|
||||
|
||||
## Tragende Patterns
|
||||
|
||||
### Bridge-Pattern (Pflicht für jedes Panel)
|
||||
|
||||
```python
|
||||
class MyBridge(panel_base.BaseBridge):
|
||||
def __init__(self):
|
||||
panel_base.BaseBridge.__init__(self, "mymodule")
|
||||
|
||||
def _on_ready(self):
|
||||
self.send("STATE_SYNC", {...}) # WebView fertig geladen
|
||||
|
||||
def handle(self, data):
|
||||
t = data.get("type")
|
||||
if t == "ACTION": self._do_action()
|
||||
|
||||
def _bridge_factory():
|
||||
b = MyBridge()
|
||||
_install_listeners(b) # Rhino-Events registrieren
|
||||
return b
|
||||
|
||||
panel_base.register_and_open(
|
||||
"mymodule", "MY PANEL", PANEL_GUID_STR,
|
||||
_bridge_factory,
|
||||
icon_spec=("foundation", "#5fa896"), # Material-Icon + Petrol
|
||||
min_size=(400, 300),
|
||||
)
|
||||
```
|
||||
|
||||
### React ↔ Python Kommunikation
|
||||
|
||||
- **React → Python**: `document.title = "RHINOMSG::{json}"` — gepollt im Idle-Handler
|
||||
- **Python → React**: `bridge.send(type, payload)` → `webview.ExecuteScript("window.onRhinoMessage(…)")`
|
||||
- **Chunking**: Messages > 200 KB werden in `panel_base.handle_raw` automatisch gesplittet und reassembliert. Subklassen kümmern sich nicht drum.
|
||||
|
||||
### Source ↔ Volume Pattern
|
||||
|
||||
Jedes Smart-Element hat:
|
||||
|
||||
1. eine **Source-Geometrie** (Achse / Outline / Punkt) — vom User editierbar
|
||||
2. ein generiertes **Volume** (Brep) — automatisch regeneriert bei Source-Änderungen
|
||||
|
||||
Beispiel Wand: Source = Achs-Linie, Volume = Brep mit Dicke × Höhe.
|
||||
|
||||
### Sticky-Storage (Cross-Module-State)
|
||||
|
||||
Konventionen für `sc.sticky`-Keys:
|
||||
|
||||
- `"{modul}_bridge"` — Bridge-Instanz
|
||||
- `"{modul}_listeners"` — Bool-Flag: Listener bereits registriert?
|
||||
- `"_dossier_*"` — globale States (z.B. `_dossier_joints_cache`)
|
||||
- `"{modul}_*_cache"` — Modul-Cache
|
||||
|
||||
### Listener-Hookup (Idempotent)
|
||||
|
||||
```python
|
||||
def _install_listeners(bridge):
|
||||
flag = "mymodule_listeners"
|
||||
sc.sticky["mymodule_bridge"] = bridge
|
||||
if sc.sticky.get(flag): return # Schon registriert
|
||||
Rhino.RhinoApp.Idle += _on_idle
|
||||
Rhino.RhinoDoc.ActiveDocumentChanged += _on_view_change
|
||||
sc.sticky[flag] = True
|
||||
```
|
||||
|
||||
## Datenhaltung
|
||||
|
||||
- **Geschosse** in `doc.Strings["dossier_ebenen"]` als JSON
|
||||
- **Smart-Elemente** als Rhino-Objekte mit UserStrings — `dossier_element_id`, `dossier_element_type`, …
|
||||
- **Section-Styles** über `Rhino.DocObjects.SectionStyle()` + `layer.SetCustomSectionStyle()`
|
||||
- **Settings**: `~/Library/Application Support/ch.gabrielevarano.Dossier/dossier_settings.json`
|
||||
|
||||
Eine `.3dm`-Datei bleibt eine Datei — keine externen Datenbanken.
|
||||
|
||||
## Layer-Hierarchie
|
||||
|
||||
```text
|
||||
10_GRUNDRISSE
|
||||
└── EG
|
||||
├── 20_WAENDE
|
||||
├── 30_DECKEN
|
||||
├── 31_DAECHER
|
||||
└── 40_TREPPEN
|
||||
└── 1OG (gleiche Sublayer)
|
||||
20_SCHNITTE
|
||||
30_ANSICHTEN
|
||||
00_RASTER · 01_VERMESSUNG · 40_SITUATION · 90_REFERENZEN · 99_KONSTRUKTION
|
||||
```
|
||||
|
||||
## Cross-Module-Pfade
|
||||
|
||||
| Sender → Empfänger | Trigger | Effekt |
|
||||
|-----------------------------|-------------------------------|---------------------------------------------------------|
|
||||
| `rhinopanel` → `elemente` | Apply von Ebenen-Struktur | `elemente_bridge._regenerate_all()` regeneriert Wände/Decken |
|
||||
| `elemente` → `rhinopanel` | Wand/Decken-Delete | `ebenen_bridge_ref._send_state()` |
|
||||
| `oberleiste` → `overrides` | Preset-Auswahl in Topbar | `overrides_bridge._send_state()` |
|
||||
| `massstab` ↔ `ausschnitte` | Viewport-/Zoom-Wechsel | Bi-direktional Skala lesen / setzen |
|
||||
| `gestaltung` ↔ `rhinopanel` | Hatch-Pattern auf Selektion | Pattern + Scale + Rotation-Signatur vergleichen |
|
||||
|
||||
## Konventionen
|
||||
|
||||
- **Python-Identifier ohne Umlaute** — `ue/oe/ae` statt `ü/ö/ä` in Code-Bezeichnern, Layer-Codes, UserString-Keys. UI-Strings dürfen Umlaute.
|
||||
- **`LoadHtml`-inline** statt `file://`-URL — Rhinos WKWebView blockiert sonst `<script type="module">` durch CORS.
|
||||
- **TextEntity-RTF** — Rhinos eingebauter Parser unterstützt nur `\b \i \ul \strike \fN \tab {}` plus Newline-via-`\par`. **Kein `\fs`** (eine TextEntity hat global eine Schriftgröße).
|
||||
- **Sticky-Reads** immer mit `is not None`-Check.
|
||||
|
||||
## Launcher-Anbindung
|
||||
|
||||
Der **Dossier-Launcher** (`launcher/`) ist eine separate Tauri-2-App. IPC zu Rhino läuft **dateibasiert**, nicht über Socket:
|
||||
|
||||
- Settings: `~/Library/Application Support/ch.gabrielevarano.Dossier/dossier_settings.json`
|
||||
- Live-Push: `pendingApplyLayout`-Key, `oberleiste.tick_idle()` pollt und cleart
|
||||
- System-Tray mit Quick-Open der letzten 5 Projekte
|
||||
|
||||
Rhino läuft ohne Launcher, Launcher läuft ohne Rhino.
|
||||
@@ -0,0 +1,111 @@
|
||||
---
|
||||
title: Erste Schritte
|
||||
linkTitle: Erste Schritte
|
||||
weight: 1
|
||||
next: docs/architektur
|
||||
---
|
||||
|
||||
DOSSIER in **5 Minuten** zum Laufen bringen.
|
||||
|
||||
## Voraussetzungen
|
||||
|
||||
| Tool | Version |
|
||||
|--------|------------------------------------------|
|
||||
| Rhino | 8 (Mac · Windows getestet, primär Mac) |
|
||||
| Python | CPython 3.9 (Rhino 8 Script-Editor-Engine) |
|
||||
| Node | ≥ 20 (nur für UI-Builds — fertige Distribution braucht das nicht) |
|
||||
|
||||
Optional — für den Standalone-Launcher:
|
||||
|
||||
| Tool | Version |
|
||||
|---------------|------------------------------------------------|
|
||||
| Rust toolchain| ≥ 1.77 (`rustup`) |
|
||||
| Build-Tools | siehe [Tauri Prerequisites](https://v2.tauri.app/start/prerequisites/) |
|
||||
|
||||
## Installation
|
||||
|
||||
{{% steps %}}
|
||||
|
||||
### Repository klonen
|
||||
|
||||
```bash
|
||||
git clone https://git.kgva.ch/karim/DOSSIER.git
|
||||
cd DOSSIER
|
||||
npm install
|
||||
```
|
||||
|
||||
### Frontend bauen
|
||||
|
||||
```bash
|
||||
npm run build # → dist/index.html (inline-fähig)
|
||||
```
|
||||
|
||||
### Plugin in Rhino starten
|
||||
|
||||
In Rhino 8 den Initialisierer über `_ScriptEditor` öffnen — die Datei `rhino/startup.py` laden und auf **Run** klicken. Sie liest die `dossier.project.json` neben der `.3dm` und lädt nur die dort gelisteten Module (oder alle, falls keine Projekt-Datei vorhanden).
|
||||
|
||||
Für automatisches Laden bei jedem Rhino-Start: Rhino-Optionen → *General* → *Run these commands every time a model is opened*:
|
||||
|
||||
```text
|
||||
_-RunPythonScript "<DOSSIER_PFAD>/rhino/startup.py"
|
||||
```
|
||||
|
||||
{{< callout type="info" >}}
|
||||
**`<DOSSIER_PFAD>`** durch den absoluten Pfad zum geklonten Repository ersetzen — z.B. `/Users/dein_user/STUDIO/DOSSIER` auf macOS oder `C:\Users\dein_user\STUDIO\DOSSIER` auf Windows. Rhino expandiert `~` in diesem Kontext nicht.
|
||||
{{< /callout >}}
|
||||
|
||||
Der Launcher trägt diesen Eintrag automatisch mit dem korrekten Pfad ein.
|
||||
|
||||
### Auto-Reset nach Änderungen
|
||||
|
||||
Bei Python-Änderungen die Panels neu laden:
|
||||
|
||||
```text
|
||||
_RunPythonScript <DOSSIER_PFAD>/rhino/_reset_panels.py
|
||||
```
|
||||
|
||||
{{% /steps %}}
|
||||
|
||||
## Erster Workflow
|
||||
|
||||
{{% steps %}}
|
||||
|
||||
### Projekt anlegen
|
||||
|
||||
In Rhino `DossierInit` aufrufen. Bürodaten, Projektnummer und Phasenbezeichnung werden im `.3dm` hinterlegt und in jedem Plankopf eingesetzt.
|
||||
|
||||
### Geschosse definieren
|
||||
|
||||
Im **EBENEN**-Panel Geschosse mit Name (`EG`, `1OG`, …), Höhe und OKFF anlegen. Dossier baut daraus die Layer-Hierarchie:
|
||||
|
||||
```text
|
||||
10_GRUNDRISSE
|
||||
└── EG
|
||||
├── 20_WAENDE
|
||||
├── 30_DECKEN
|
||||
├── 31_DAECHER
|
||||
└── 40_TREPPEN
|
||||
└── 1OG (gleiche Sublayer)
|
||||
```
|
||||
|
||||
### Smart-Elemente platzieren
|
||||
|
||||
Im **ELEMENTE**-Panel das gewünschte Bauteil wählen — Wand, Decke, Öffnung, Treppe, Tragwerk oder Raum. Source-Geometrie zeichnen (Achse, Outline, Punkt), Volumen wird automatisch generiert.
|
||||
|
||||
### Plan generieren
|
||||
|
||||
**Named Views** für Grundrisse, Schnitte und Axonometrien speichern. Im **LAYOUTS**-Panel Vorlage wählen, Views auf das Blatt ziehen, Plannummer vergeben. Dossier erzeugt das Layout mit Titelblock und passt den Massstab automatisch an.
|
||||
|
||||
### Export
|
||||
|
||||
Stapelexport aller Pläne als PDF oder PNG aus dem **LAYOUTS**-Panel. Optional mit Plannummer-Suffix im Dateinamen und Vektordaten für die Druckfreigabe.
|
||||
|
||||
{{% /steps %}}
|
||||
|
||||
## Wo geht's weiter?
|
||||
|
||||
{{< cards >}}
|
||||
{{< card link="../features" title="Features" subtitle="Alle Panels im Detail." >}}
|
||||
{{< card link="architektur" title="Architektur" subtitle="Module, Bridges, Sticky-Storage." >}}
|
||||
{{< card link="../faq" title="FAQ" subtitle="Häufige Fragen." >}}
|
||||
{{< /cards >}}
|
||||
@@ -0,0 +1,122 @@
|
||||
---
|
||||
title: Roadmap
|
||||
linkTitle: Roadmap
|
||||
weight: 3
|
||||
toc: true
|
||||
---
|
||||
|
||||
DOSSIER ist ein **Design-Studio für Rhino**, keine BIM-Cloud. Der Fokus liegt auf **3D-Modell-Qualität** und sauberer Planabgabe direkt aus dem Modell — keine externe Datenbank, keine Zwangs-Synchronisation, keine Cloud-Lock-in.
|
||||
|
||||
Diese Seite hält den Status der grösseren Bauteile fest. Detail-Issues und Bugfixes laufen auf [Gitea](https://git.kgva.ch/karim/DOSSIER/issues).
|
||||
|
||||
## Erledigt
|
||||
|
||||
Die folgenden Bauteile sind im aktiven Einsatz und Teil der Pre-Release 0.1.0:
|
||||
|
||||
### Wand-System v1
|
||||
|
||||
Polyline-Wand mit **Chain-Anchor**, **Cmd+Z** über alle Joints stabil, native Rhino-**Grips** für Achs-Editierung. Siehe [Smart-Elemente](../../features/smart-elemente).
|
||||
|
||||
### Schnitte & Ansichten
|
||||
|
||||
Schnitt-Perspektive plus die volle **SectionStyle-API** (Schnittlinien-Stil, Section-Hatch, Hidden-Line-Removal). War der **konkrete Anlass** für die Migration von IronPython 2.7 zu CPython 3. Siehe [Schnitte & Ansichten](../../features/schnitte-ansichten).
|
||||
|
||||
### Geschoss-Management
|
||||
|
||||
**Multi-Geschoss-Clipping** mit konfigurierbaren Modi, **Top-View Z-Guard** gegen versehentliche Z-Drifts und **Snap-Bar** pro Geschoss. Siehe [Geschosse & Ebenen](../../features/geschosse).
|
||||
|
||||
### Project-Settings (5 Tabs)
|
||||
|
||||
Zentraler Dialog für Voreinstellungen + Projektdaten, Materialien, Linientypen, Schraffuren und Symbole. Siehe [Project-Settings](../../features/project-settings).
|
||||
|
||||
### Material/Library-System
|
||||
|
||||
**ArchiCAD-style List/Detail**-UI, **Auto-Regen** über die Smart-Element-Hierarchie, **`.lin`/`.pat`-Import** für Linetypes und Hatches, bewusste **Material/Ebene-Separation**. Siehe [Material-Library](../../features/materialien).
|
||||
|
||||
### Symbol-Library — Phase A + B
|
||||
|
||||
**2D+3D Pair-Files**, **Satellite-Picker** als persistenter Floating-Window, **Multi-Format-Import** (`.3dm` · `.dwg` · `.obj` · `.fbx` · `.dae` · `.stl`), **Auto-Thumbnails** als Base64-PNG und volle **CRUD**-Operationen. Siehe [Symbol-Library](../../features/symbol-library).
|
||||
|
||||
### Swisstopo-Integration
|
||||
|
||||
**Adress-Prefill** aus den Projektdaten, **Terrain-Import** aus dem AlMo-DOM-Layer und **m.ü.M** in der Plankopf-Variable. Siehe [Swisstopo & OSM](../../features/swisstopo-osm).
|
||||
|
||||
### Launcher (Tauri 2)
|
||||
|
||||
Standalone-App für Projekt-Management, **Auto-Update** über `tauri-plugin-updater`, **System-Tray** mit Quick-Open und **file-based IPC** zu Rhino. Siehe [Launcher](../../launcher).
|
||||
|
||||
## In Arbeit
|
||||
|
||||
### Display-Mode "Dossier Plan"
|
||||
|
||||
{{< callout type="warning" >}}
|
||||
Game-Changer für Plan-Qualität direkt aus 3D — kein Umweg über separate 2D-CAD-Dateien.
|
||||
{{< /callout >}}
|
||||
|
||||
Drei kombinierte Effekte:
|
||||
|
||||
- **Hidden-Line-Removal** über die aktive Section-Plane (Rhino-natives Verfahren)
|
||||
- **Weisser Hintergrund**, Layer-Display-Farben werden zu reinem Schwarz remappt
|
||||
- **Section-Hatch** aus der Layer-Property-Tabelle gerendert (siehe [Schnitte & Ansichten](../../features/schnitte-ansichten))
|
||||
|
||||
Ziel: Wettbewerbs- und Konkurrenz-Pläne ohne Plot-Konvertierung über AutoCAD oder ArchiCAD. Siehe [Massstab & Display-Modes](../../features/massstab).
|
||||
|
||||
## Geplant
|
||||
|
||||
### Raumstempel-Redesign (4 Stufen)
|
||||
|
||||
Der aktuelle Raum-Stempel zeigt Bezeichnung + Fläche, hat aber einen **Wert-Bug** beim Refresh nach Outline-Änderung. Geplant:
|
||||
|
||||
1. **Stufe 1 — Wert-Bug fixen** — Centroid-Berechnung und Fläche werden synchron neu gelesen, Cache-Invalidation greift bei Polyline-Replace.
|
||||
2. **Stufe 2 — Massstäblich-Modus** — Stempel-Schrift folgt dem aktiven Massstab (1:50 → grössere Schrift als 1:100), nicht der Welt-Geometrie.
|
||||
3. **Stufe 3 — Settings-Dialog** — pro Projekt definieren, welche Felder am Stempel erscheinen (Nr · Bezeichnung · SIA · Fläche · Höhe · Material).
|
||||
4. **Stufe 4 — Wettbewerb-Features** — alternative Stempel-Sets für Wettbewerbsabgaben (anonymisierte Codes, vereinfachte Geometrie).
|
||||
|
||||
### Custom Linetype-Editor
|
||||
|
||||
Visueller **Pattern-Editor** für `.lin`-kompatible Linetypes — Drag-Handles für Strich/Lücke-Längen, Live-Preview im Massstab des aktiven Layouts. Der `.lin`-Import existiert bereits (siehe [Materialien](../../features/materialien)); der Editor schreibt in denselben Datentyp.
|
||||
|
||||
**User-Pause** — kommt nach dem Display-Mode "Dossier Plan".
|
||||
|
||||
### PBR-Erweiterungen
|
||||
|
||||
Drei konkrete Lücken im aktuellen Material-Editor:
|
||||
|
||||
- **Separate Roughness-Textur** — heute nur Roughness-Slider, geplant ist eine zusätzliche Roughness-Map (PNG, Graustufen)
|
||||
- **UV-Rotation** — Texturen können bisher nur skaliert werden, nicht rotiert
|
||||
- **Bump-Strength-Slider** — Normal-Map-Intensität soll feinjustierbar werden, statt nur ein/aus
|
||||
|
||||
### Library Phase C — Cloud-Sync
|
||||
|
||||
Symbol-Library erweitern um **Team-Sharing** über GitHub-Releases:
|
||||
|
||||
```text
|
||||
Bürobibliothek-Repo (GitHub)
|
||||
├── releases/v1.4.0/
|
||||
│ ├── symbols/sofa-3sitz.3dm
|
||||
│ ├── symbols/sofa-3sitz.2d.3dm
|
||||
│ └── manifest.json (semver, thumbnails, kategorien)
|
||||
```
|
||||
|
||||
Im PROJECT-SETTINGS-Symbole-Tab wird die Bürobibliothek-URL gesetzt, DOSSIER pullt periodisch Releases und mergt sie mit der projekt-lokalen Library. Pull-Request-Workflow für neue Symbole vom Team.
|
||||
|
||||
### Satellite-Windows-Restyle
|
||||
|
||||
Alle Satellite-Floating-Windows (Symbol-Picker, Material-Picker, Hatch-Picker, …) auf einheitliches **Pill-Style** umstellen — runde Ecken, weicher Schatten, einheitliche Header-Höhe. Konsistente UX über alle Picker-Tools.
|
||||
|
||||
## Strategischer Anker
|
||||
|
||||
DOSSIER bleibt:
|
||||
|
||||
- **Lokal** — `.3dm` + `dossier.project.json` ist alles, kein Server zwingend nötig
|
||||
- **Schweizer-Standard-aware** — SIA 102 / SIA 416, Swisstopo, m.ü.M direkt eingebaut
|
||||
- **AGPL-3.0** — Open Source, keine Telemetrie, keine versteckten Kosten
|
||||
- **Rhino-nativ** — kein eigenes Datei-Format, alle Daten in Rhinos eigenen Tabellen (Materials, Linetypes, Hatches, UserStrings)
|
||||
|
||||
Was DOSSIER **nicht** ist:
|
||||
|
||||
- Keine BIM-Cloud, kein zentraler Server
|
||||
- Keine IFC-Schema-Konformität (es ist kein BIM-Tool)
|
||||
- Kein Ersatz für ArchiCAD / Revit — Dossier bündelt Rhino-Workflows, ersetzt aber keine Statik-Software, kein Mengen-Auswertungs-Tool, keine Quantity-Take-Off
|
||||
|
||||
Wenn dir ein Feature fehlt, das in diesen Rahmen passt → [Issue auf Gitea](https://git.kgva.ch/karim/DOSSIER/issues).
|
||||
@@ -0,0 +1,82 @@
|
||||
---
|
||||
title: FAQ
|
||||
linkTitle: FAQ
|
||||
weight: 4
|
||||
toc: true
|
||||
---
|
||||
|
||||
Häufige Fragen zu DOSSIER. Bei Bugs oder weiteren Fragen → [Issue auf Gitea](https://git.kgva.ch/karim/DOSSIER).
|
||||
|
||||
## Für wen ist Dossier gedacht?
|
||||
|
||||
Für **Architekturbüros**, die Rhino bereits im Entwurf und in der Ausführungsplanung einsetzen und den gesamten Weg bis zur fertigen Planabgabe im Modell halten möchten — ohne Umweg über separate CAD-Programme.
|
||||
|
||||
## Was ist die Idee?
|
||||
|
||||
Rhino aus der reinen Modellierumgebung in ein **vollständiges Design-Studio** überführen. Smart-Elemente, Plan-Verwaltung, Vorlagen, Beschriftung und Ausgabe gehören in einem Architekturprojekt zusammen — Dossier bündelt sie an einem Ort. Wo Konventionen aus der Branche existieren (SIA 416, Layer-Naming), werden sie kuratiert übernommen, statt das Rad neu zu erfinden.
|
||||
|
||||
## Welche Rhino-Version wird unterstützt?
|
||||
|
||||
**Rhino 8** für **macOS** (primär getestet) und **Windows** (untestet, aber kompatibel). Eine Portierung auf ältere Versionen ist nicht geplant — Dossier verwendet die neue CPython-3-Engine und Section-Style-APIs, die erst mit Rhino 8 verfügbar sind.
|
||||
|
||||
## Ist Dossier kostenlos?
|
||||
|
||||
**Ja.** Der gesamte Quellcode steht unter **GNU AGPL-3.0-or-later**. Keine Telemetrie, keine versteckten Kosten. Eigene Builds aus dem Repo oder die fertige Distribution.
|
||||
|
||||
## Wie ersetzt Dossier den klassischen Layout-Workflow?
|
||||
|
||||
Dossier baut **auf** Rhinos Layout-Konzept auf und legt darüber die projektbezogene Verwaltung, die in einem vollständigen Plan-Workflow fehlt: Plan-Sets, zentrale Vorlagen, Titelblock-Master und Stapelexport. Manueller Layout-Aufbau pro Blatt entfällt.
|
||||
|
||||
## Wie funktioniert die SIA-416-Flächenauswertung?
|
||||
|
||||
Jeder Raum trägt eine **Kategorie** (HNF, NNF, FF, VF) als Metadatum. Diese Information bleibt für die normale Plandarstellung **unsichtbar** — die Räume sind im Standardmodus transparent. Erst ein eigener **Flächen-Anzeigemodus** überlagert die Geometrie mit den definierten Kategoriefarben.
|
||||
|
||||
Die Klassifikation selbst dient primär der **Schema- und Listenerzeugung**: Flächentabellen, aggregierte HNF/NNF/FF/VF-Summen und der Raum-CSV-Export greifen direkt darauf zu. Siehe [Räume (SIA 416)](../features/raeume-sia416).
|
||||
|
||||
## Wo werden die Plandaten gespeichert?
|
||||
|
||||
Im **`.3dm`-Dokument selbst**, als zusätzliche Metadaten an Named Views, Layouts und Layern. Es entstehen **keine externen Datenbanken** — eine Datei bleibt eine Datei. Backup-Strategie ist trivial: `.3dm` kopieren.
|
||||
|
||||
## Welche Python-Runtime läuft?
|
||||
|
||||
**CPython 3.9** über Rhinos neue Script-Editor-Engine (Rhino 8). Die Migration von IronPython 2.7 ist abgeschlossen (verifiziert 2026-05-17 auf Mac Rhino 8.31). Verifikation in Rhino:
|
||||
|
||||
```text
|
||||
_RunPythonScript <DOSSIER_PFAD>/rhino/startup.py
|
||||
# Erste Zeile sollte zeigen: [STARTUP] Python: 3.x ...
|
||||
```
|
||||
|
||||
## Ist Dossier stabil genug für den Produktivbetrieb?
|
||||
|
||||
**Noch nicht.** Aktuell befindet sich Dossier in der **Pre-Release-Phase 0.1.0**. Funktionen können sich ändern, Bugs sind möglich. Eigene Backups der `.3dm`-Dateien sind empfohlen. Smart-Elemente in echten Projekten haben aber bereits 6+ Monate produktiven Einsatz hinter sich.
|
||||
|
||||
## Werden Wände und Decken bei Modell-Änderungen automatisch nachgeführt?
|
||||
|
||||
**Ja.** Das Source-↔-Volume-Pattern triggert Regeneration bei jeder Source-Geometrie-Änderung. Wand-Joints, Decken-Aussparungen und Öffnungs-Cutouts werden mitgeführt — ohne manuelles Refresh.
|
||||
|
||||
Caches haben jedoch bekannte Stale-Risiken (siehe [Werkzeuge](../features/werkzeuge)) — Undo/Redo invalidiert den Joint-Cache aktuell **nicht** automatisch.
|
||||
|
||||
## Kann ich zum Projekt beitragen?
|
||||
|
||||
**Ja.** Issues und Pull Requests sind willkommen auf [Gitea](https://git.kgva.ch/karim/DOSSIER). Besonders wertvoll sind:
|
||||
|
||||
- konkrete Bug-Reports mit Minimal-`.3dm`
|
||||
- Workflow-Verbesserungen aus dem realen Büroalltag
|
||||
- Titelblock-Vorlagen für andere Büros
|
||||
- Übersetzungen / Internationalisierung
|
||||
|
||||
Lies vorher die [Architektur-Übersicht](../docs/architektur).
|
||||
|
||||
## Wo kriege ich Hilfe?
|
||||
|
||||
| Kanal | Verwendung |
|
||||
|--------------------|-------------------------------------------|
|
||||
| **Gitea Issues** | Bugs, Feature-Wünsche, allgemeine Fragen |
|
||||
| **karimgabrielevarano.xyz** | Entwickler-Kontakt |
|
||||
| **GitHub Discussions** | (nicht eingerichtet) |
|
||||
|
||||
## Warum Open Source?
|
||||
|
||||
Bürowissen sollte nicht in proprietären Tools eingesperrt sein. Plan-Workflows sind in der Branche gut etabliert — ein Tool, das diese Konventionen sauber umsetzt, gehört allen.
|
||||
|
||||
AGPL-3.0 stellt sicher, dass Verbesserungen wieder ins Projekt fliessen.
|
||||
@@ -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 >}}
|
||||
@@ -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.
|
||||
@@ -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)
|
||||
@@ -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
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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 >}}
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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 >}}
|
||||
@@ -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.
|
||||
@@ -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).
|
||||
@@ -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
|
||||
@@ -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 >}}
|
||||
@@ -0,0 +1,100 @@
|
||||
---
|
||||
title: Dossier-Launcher
|
||||
linkTitle: Launcher
|
||||
weight: 3
|
||||
toc: true
|
||||
---
|
||||
|
||||
Der **Dossier-Launcher** ist eine separate **Tauri 2** Standalone-App. Sie verwaltet Projekte, hält Settings, liefert Auto-Updates und lebt im System-Tray. Aktuell produktiv im Einsatz für Projekt-Switching, Window-Layout-Push und Plugin-Settings.
|
||||
|
||||
## Was er macht
|
||||
|
||||
{{< cards >}}
|
||||
{{< card title="Projekt-Verwaltung" icon="collection" subtitle="Liste aller DOSSIER-Projekte mit Pfad, letztem Zugriff und Phase." >}}
|
||||
{{< card title="Settings-Sync" icon="cog" subtitle="Schreibt Plugin-Settings in dossier_settings.json — Rhino liest live." >}}
|
||||
{{< card title="Auto-Updates" icon="cloud-download" subtitle="Über tauri-plugin-updater, signiert mit Code-Signing-Key." >}}
|
||||
{{< card title="System-Tray" icon="desktop-computer" subtitle="Quick-Open der letzten 5 Projekte, ohne Hauptfenster zu öffnen." >}}
|
||||
{{< card title="Window-Layouts" icon="template" subtitle="Live-Push von Window-Layouts an laufende Rhino-Session." >}}
|
||||
{{< card title="Recent-Cache" icon="clock" subtitle="recent.json — letzte 50 geöffnete Projekte für Quick-Access." >}}
|
||||
{{< /cards >}}
|
||||
|
||||
## Technologie
|
||||
|
||||
| Komponente | Stack |
|
||||
|--------------|------------------------------------|
|
||||
| Frontend | React + Vite (`launcher/src/`) |
|
||||
| Backend | Rust + Tauri 2 (`launcher/src-tauri/`) |
|
||||
| Update-Plugin| `tauri-plugin-updater` |
|
||||
| Tray-Plugin | `tauri-plugin-tray` |
|
||||
| IPC zu Rhino | Dateibasiert (kein Socket) |
|
||||
|
||||
## Settings-Files
|
||||
|
||||
Pfad-Hierarchie:
|
||||
|
||||
1. **Primär** (Launcher schreibt):
|
||||
`~/Library/Application Support/ch.gabrielevarano.Dossier/dossier_settings.json`
|
||||
2. **Legacy-Fallback** (read-only):
|
||||
`~/Library/Application Support/RhinoPanel/dossier_settings.json`
|
||||
|
||||
Recent-Cache:
|
||||
`~/Library/Application Support/ch.gabrielevarano.Dossier/recent.json`
|
||||
|
||||
## Bekannte Settings-Keys
|
||||
|
||||
| Key | Beschreibung |
|
||||
|----------------------|-------------------------------------------------------|
|
||||
| `windowLayout` | Aktives Window-Layout (XML-Display-Name) |
|
||||
| `autoApplyLayout` | Bool — Layout beim Projekt-Wechsel anwenden? |
|
||||
| `pendingApplyLayout` | Pending Layout-Name — wird von `oberleiste.tick_idle()` gepollt und gelöscht |
|
||||
| `rhinoApp` | Pfad zum Rhino-App-Bundle |
|
||||
| `templatePath` | Default-Template für neue Projekte |
|
||||
|
||||
## Window-Layouts auf Mac
|
||||
|
||||
Mac Rhino 8 speichert Window-Layouts als **XML** unter:
|
||||
|
||||
```text
|
||||
~/Library/Application Support/McNeel/Rhinoceros/8.0/settings/Scheme__Default/workspaces/<GUID>.xml
|
||||
```
|
||||
|
||||
Display-Name aus dem `<RhinoUI name="…">` Attribut. Der Launcher liest diese Datei direkt — kein `.rwl` wie auf Windows.
|
||||
|
||||
**Apply** via Reflection über `Rhino.UI.WindowLayout.*`, Fallback `_-SetActiveLayout "Name" _Enter`.
|
||||
|
||||
## Live-Push Workflow
|
||||
|
||||
```text
|
||||
Launcher ─writes─▶ pendingApplyLayout key ──▶ dossier_settings.json
|
||||
│
|
||||
▼
|
||||
Rhino-Plugin: oberleiste.tick_idle() ─polls─▶ liest + clearet
|
||||
│
|
||||
▼
|
||||
Window-Layout aktiv
|
||||
```
|
||||
|
||||
Polling-Intervall: 500 ms im Rhino-Idle-Handler. Latenz spürbar < 1 s.
|
||||
|
||||
## Setup
|
||||
|
||||
```bash
|
||||
cd launcher
|
||||
npm install
|
||||
npm run tauri dev # Development-Mode
|
||||
```
|
||||
|
||||
Release-Build mit Code-Signing:
|
||||
|
||||
```bash
|
||||
cd launcher
|
||||
./scripts/release.sh # → schreibt latest.json für Updater
|
||||
```
|
||||
|
||||
Voraussetzungen siehe [Tauri Prerequisites](https://v2.tauri.app/start/prerequisites/).
|
||||
|
||||
## Standalone
|
||||
|
||||
**Rhino läuft ohne Launcher** — Settings haben sinnvolle Defaults, Plugin funktioniert direkt aus dem PackageManager-Install.
|
||||
|
||||
**Launcher läuft ohne Rhino** — Projekt-Verwaltung, Settings-Editor und Updates funktionieren auch ohne installiertes Rhino. IPC ist bewusst dateibasiert.
|
||||
Reference in New Issue
Block a user