Archicads PLN-filformat

Vad ett PLN-projekt innehåller

Archicad använder .pln för projekt och .pla för projektarkiv. PLN lagrar modellen och genererade vyer tillsammans med projektinställningar, attribut och biblioteksreferenser. Ett arkiv kan paketera refererade resurser med projektet. Graphisoft beskriver rollerna i dokumentationen om projektfiltyper.

Läsarens utgångspunkt är den lagrade databasen. Aktiva objekt identifierar projektets sparade tillstånd och relationer kopplar byggnadselement till stödjande poster. Att läsa en vägg kan därför kräva flera poster för dess planform, placering, våningsrelation och öppningar.

ROF-behållaren och dess aktiva katalog

De uppmätta filerna börjar med ASCII-signaturen ROF FDB på åtta byte, inklusive ett avslutande blanksteg. Graphisoft använder ROF för Random Object File och BL för BLock. I den uppmätta layouten upptar huvudet 32 byte och den första BL-allokeringen börjar vid byte 32. Allokeringarnas utsträckning anges i enheter om 16 byte.

En sparad fil kan även innehålla historiska katalogögonblicksbilder och gamla allokeringar. Läsaren följer aktiva poster och kontrollerar varje refererad allokerings identitet och utsträckning. Kontrollerna knyter de avkodade objekten till det aktuella sparade tillståndet.

QuickLZ-komprimering i två lagringslager

På fysisk nivå växlar BL-allokeringar med komprimerade grupper. I den uppmätta strukturen innehåller en grupp antal avkodade byte, antal block, QuickLZ-block med längdprefix och en avslutning för justering. Yttre block expanderas till högst 1 MiB och har oberoende ordböcker. När grupperna expanderas framträder den logiska BL-heapen.

Enskilda allokeringsinnehåll använder någon av tre observerade kodningar: bokstavliga byte, nollbytemasker eller en ny följd av QuickLZ-block. En nollmask anger vilka byte som lagras och vilka som expanderas till noll. Inre QuickLZ-block expanderas till högst 256 KiB, och en blockgräns kan gå genom en bild eller objektpost.

QuickLZ-huvuden finns i former på tre och nio byte. Ett block med kort huvud i ett skapat Archicad 29-projekt visade behovet av att hantera båda. Exakt förbrukning av komprimerade byte och deklarerade avkodade längder kontrolleras innan resultatet tolkas som poster. Ett metadataord intill innehållslängderna är fortfarande oklart; läsaren förlitar sig på validerade strukturkontroller.

ODB-postmodellen kopplar element till deras data

Object Database (ODB) skiljer på objektidentitet och klassidentitet. Ett objekt-GUID identifierar ett lagrat objekt medan ett klass-GUID identifierar posttypen. Kontrollerade metadatabeskrivningar i provmaterialet kopplar klass-GUID till namn som Wall, Beam, Column, Ceil för bjälklag och VBElem::FreeShape för morph-objekt. Beskrivningsposter innehåller även serialiserad versionsinformation.

Associationer kopplar ihop objekten. En uppmätt associationspost med en enda referens innehåller en operationskod, ett associations-GUID och ett målobjekts-GUID. Andra uppmätta former innehåller ett antal följt av flera mål-GUID. Associationsdeklarationer kan beskriva ändpunkternas roller medan slutdelarna i objektposterna anger de faktiskt länkade identiteterna.

Vissa äldre väggposter innehåller en användbar planform direkt i posten. De Archicad 29-väggar som skapats i våra kontrollprojekt lagrar planformen i länkade VBD::WallVRDData-objekt. Den validerade relationen leder till relevanta polygondata. Geometrirekonstruktionen kontrollerar sedan placering, vertikal utsträckning och de öppningsrelationer som stöds innan väggytor skapas.

Den inbäddade förhandsvisningen som separat projektpost

Den uppmätta behållaren har en reserverad post för projektförhandsvisning. När en bild har sparats där kan läsaren hämta projektets PNG-bild ur det avkodade innehållet. Posten kan också ha ett tomt förhandsvisningsfält. Tillgängligheten beror därför på det sparade projektet.

Förhandsvisningen ger en sparad bildreferens. 3D-scenen byggs av modellposter och kan granskas från olika håll. Öppna den interaktiva PLN-paviljongdemon för att utforska den avkodade byggnadens tak, väggöppningar och terräng.

Vad webbläsarläsaren kan rendera

Stödet omfattar väggar med utskurna dörr- och fönsteröppningar, bjälklag, lutande tak, zoner, balkar, pelare, morph-objekt, nät och terräng. Stödet för dörrar och fönster avser öppningen genom värdväggen. En inbäddad projektförhandsvisning kan också hämtas när en sådan har sparats. Omfattningen beror på projektets lagrade elementposter och geometrirepresentationer.

Filer från Archicad 25, 27 och 29 har avkodats och testats. Den sparade representationen av varje element avgör vilken geometri som visas. Kontrollera de synliga elementen för att fastställa vad din granskning kan omfatta.

Läsaren hämtar valda byteintervall och dekomprimerar de poster som behövs för geometrin som stöds lokalt i webbläsaren. Scenen använder meter och ett koordinatsystem med Y uppåt. Geometrikontroller och uttryckliga avkodningsgränser bestämmer omfattningen. Oklara klasslayouter och fältbetydelser undersöks vidare.

Den uppmätta implementationens omfattning förklarar varför filidentifiering, dekomprimering, val av aktiva objekt och geometrirekonstruktion är separata steg. Se Öppna en PLN-fil online för det praktiska arbetsflödet. Exporter använder den geometri som visaren lyckas avkoda.

Den här guiden beskriver de binärstrukturer som har uppmätts i exempelfiler och används av vår läsare, samt de geometrivägar som stöds. De testade filerna kommer från Archicad 25, 27 och 29. Vissa klasslayouter, fältbetydelser och geometrirepresentationer är fortfarande oklara, och täckningen varierar mellan projekt. Slutsatserna gäller den undersökta implementationens omfattning.

Vanliga frågor