Das Archicad-Dateiformat PLN

Was ein PLN-Projekt enthält

Archicad verwendet .pln für Projekte und .pla für Projektarchive. PLN speichert Modell und erzeugte Ansichten zusammen mit Projekteinstellungen, Attributen und Bibliotheksverweisen. Archive können referenzierte Ressourcen bündeln. Graphisoft beschreibt diese Rollen in der Dokumentation der Projektdateitypen.

Ausgangspunkt des Readers ist die gespeicherte Datenbank. Aktive Objekte bestimmen den gespeicherten Projektzustand; Beziehungen verbinden Bauelemente mit ergänzenden Datensätzen. Zum Lesen einer Wand können Datensätze für Grundriss, Platzierung, Geschossbezug und Öffnungen nötig sein.

ROF-Container und aktives Verzeichnis

Die gemessenen Dateien beginnen mit der acht Byte langen ASCII-Signatur ROF FDB samt abschließendem Leerzeichen. Graphisoft verwendet ROF für Random Object File und BL für BLock. Im gemessenen Layout belegt der Header 32 Bytes; die erste BL-Allokation beginnt bei Byte 32. Allokationsausdehnungen verwenden Einheiten von 16 Bytes.

Eine gespeicherte Datei kann historische Verzeichnisschnappschüsse und veraltete Allokationen enthalten. Der Reader folgt den aktiven Einträgen und prüft Identität und Ausdehnung jeder referenzierten Allokation. Damit werden dekodierte Objekte dem aktuellen gespeicherten Zustand zugeordnet.

Zwei Speicherschichten mit QuickLZ-Komprimierung

Physisch wechseln BL-Allokationen und komprimierte Gruppen einander ab. Eine gemessene Gruppe enthält die dekodierte Byteanzahl, eine Chunkanzahl, QuickLZ-Chunks mit Längenpräfix und einen Ausrichtungsabschluss. Äußere Chunks werden auf höchstens 1 MiB entpackt und besitzen unabhängige Wörterbücher. Das Entpacken legt den logischen BL-Heap frei.

Einzelne Allokationsinhalte verwenden drei beobachtete Kodierungen: wörtliche Bytes, Nullbyte-Masken oder eine weitere QuickLZ-Chunkfolge. Eine Nullmaske bestimmt gespeicherte Bytes und zu Null zu erweiternde Bytes. Innere Chunks werden auf höchstens 256 KiB entpackt; eine Chunkgrenze kann innerhalb eines Bildes oder Objektdatensatzes liegen.

QuickLZ-Header besitzen Formen mit drei und neun Bytes. Ein Chunk mit kurzem Header in einem erstellten Archicad-29-Projekt zeigte, dass der Reader beide verarbeiten muss. Verbrauchte komprimierte Bytes und deklarierte Ausgabelängen werden vor der Datensatzinterpretation geprüft. Ein Metadatenwort neben den Inhaltslängen bleibt ungeklärt; der Reader stützt sich auf validierte Strukturprüfungen.

ODB-Datensätze verbinden Elemente mit ihren Daten

Die Object Database (ODB) unterscheidet Objektidentität und Klassenidentität. Eine Objekt-GUID bezeichnet ein gespeichertes Objekt, eine Klassen-GUID dessen Datensatztyp. Geprüfte Metadatendeskriptoren ordnen im Untersuchungskorpus Klassen-GUIDs Namen wie Wall, Beam, Column, Ceil für eine Decke und VBElem::FreeShape für ein Morph zu. Deskriptoren enthalten auch serialisierte Versionsinformationen.

Assoziationen verknüpfen diese Objekte. Ein gemessener Eintrag mit Einzelreferenz enthält Opcode, Assoziations-GUID und Zielobjekt-GUID. Andere gemessene Formen enthalten eine Anzahl und mehrere Ziel-GUIDs. Assoziationsdeklarationen können Endpunktrollen beschreiben; Endbereiche der einzelnen Objektdatensätze liefern die konkreten verknüpften Identitäten.

Einige ältere Wanddatensätze enthalten einen nutzbaren Grundriss direkt im Datensatz. Erstellte Archicad-29-Wände unserer Kontrollprojekte speichern ihn in verknüpften VBD::WallVRDData-Objekten. Validierte Beziehungen führen zu den Polygondaten. Vor dem Aufbau der Wandflächen prüft die Geometrierekonstruktion Platzierung, vertikale Ausdehnung und unterstützte Öffnungsbeziehungen.

Die eingebettete Vorschau als eigener Projektdatensatz

Der gemessene Container besitzt einen reservierten Vorschau-Datensatz. Enthält er ein gespeichertes Bild, kann der Reader das Projekt-PNG aus dem dekodierten Inhalt extrahieren. Der Datensatz kann auch ein leeres Vorschaufeld besitzen. Die Verfügbarkeit hängt somit vom gespeicherten Projekt ab.

Die Vorschau liefert eine gespeicherte Bildreferenz. Die 3D-Szene wird aus Modelldatensätzen aufgebaut und lässt sich aus verschiedenen Richtungen prüfen. Öffnen Sie die PLN-Livedemo des Pavillons, um das dekodierte Gebäude mit Dach, Wandöffnungen und Gelände zu erkunden.

Was der Browser-Reader darstellen kann

Unterstützt werden Wände mit ausgeschnittenen Tür- und Fensteröffnungen, Decken, geneigte Dächer, Zonen, Träger, Stützen, Morphs, Netze und Gelände. Die Unterstützung von Türen und Fenstern umfasst den Ausschnitt in der zugehörigen Wand. Eine gespeicherte eingebettete Projektvorschau kann ebenfalls ausgelesen werden. Der Umfang hängt von den gespeicherten Elementdatensätzen und Geometriedarstellungen ab.

Dateien aus Archicad 25, 27 und 29 wurden dekodiert und getestet. Die gespeicherte Darstellung der einzelnen Elemente bestimmt, welche Geometrie angezeigt wird. Prüfen Sie die sichtbaren Elemente für Ihre konkrete Besprechung.

Der Reader liest ausgewählte Bytebereiche und dekomprimiert die für unterstützte Geometrie erforderlichen Datensätze lokal im Browser. Die Szene verwendet Meter und ein Koordinatensystem mit Y nach oben. Geometrieprüfungen und ausdrückliche Dekodiergrenzen bestimmen den akzeptierten Umfang. Ungeklärte Klassenlayouts und Feldbedeutungen bleiben Gegenstand weiterer Untersuchungen.

Die gemessene Implementierung erklärt die getrennten Schritte Dateierkennung, Dekomprimierung, Auswahl aktiver Objekte und Geometrierekonstruktion. Den praktischen Ablauf erläutert PLN-Datei online öffnen. Exporte verwenden erfolgreich dekodierte Geometrie.

Diese Anleitung beschreibt die an Beispieldateien gemessenen Binärstrukturen unseres Readers und die unterstützten Geometriepfade. Die getesteten Dateien stammen aus Archicad 25, 27 und 29. Einige Klassenlayouts, Feldbedeutungen und Geometriedarstellungen sind weiterhin ungeklärt; die Abdeckung variiert je Projekt. Die Aussagen gelten für diesen untersuchten Implementierungsumfang.

Häufige Fragen