c0a5de194f
- Move Display-Mode "Dossier Plan" to shipped; describe walls as multilayer with T-/L-/X-joints and Sturz/Brüstung openings; expand stairs depth and configurable 2D plan display - Drop BIM framing and identity-by-negation throughout - Replace named CAD product comparisons with generic phrasing - Remove unsupported "6+ months in production" claim - Use "Python 3.9" instead of "CPython 3.9" in user-facing copy - Rename "Tauri-Launcher" card to "Launcher" and drop sparkles icon Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
97 lines
3.6 KiB
Markdown
97 lines
3.6 KiB
Markdown
---
|
|
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 Python-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
|