The Archicad PLN File Format

What a PLN project contains

Archicad uses .pln for a project and .pla for a project archive. A PLN carries the model and generated views together with project settings, attributes and library references. An archive can bundle referenced resources with that project. Graphisoft describes these roles in its project file type documentation.

The useful starting point for a reader is the stored database. Its active objects identify the saved project state, and their relationships connect building elements with supporting records. Reading a wall may therefore involve several records for its footprint, placement, floor relationship and openings.

The ROF container and its active directory

The measured files begin with the eight-byte ASCII signature ROF FDB , including a trailing space. Graphisoft’s storage terminology expands ROF to Random Object File and BL to BLock. In the measured layout the header occupies 32 bytes, with the first BL allocation beginning at byte 32. Allocation extents use 16-byte units.

The active directory is essential because a saved file can also contain historical directory snapshots and stale allocations. The reader follows active entries and checks each referenced allocation’s identity and extent. Those checks tie the decoded objects to the current saved state.

QuickLZ compression has two storage layers

At the physical level, BL allocations alternate with compressed groups. In the measured grammar, a group contains a decoded byte count, a chunk count, length-prefixed QuickLZ chunks and an alignment trailer. Outer chunks expand to at most 1 MiB and use independent dictionaries. Expanding those groups reveals the logical BL heap.

Individual allocation payloads then use one of three observed encodings: literal bytes, zero-byte masks, or another QuickLZ chunk sequence. A zero mask indicates which bytes are stored and which expand to zero. Inner QuickLZ chunks expand to at most 256 KiB, and a chunk boundary can pass through the contents of an image or object record.

QuickLZ headers have both three-byte and nine-byte forms. A short-header chunk in an authored Archicad 29 project established the need to handle both in our reader. Exact packed-byte consumption and declared decoded lengths are checked before the result is interpreted as records. A metadata word beside the payload lengths remains unresolved in our research; the reader relies on its validated structural checks.

The ODB record model connects elements to their data

The Object Database, or ODB, separates object identity from class identity. An object GUID identifies one stored object, while a class GUID identifies its record type. Checked metadata descriptors in the research corpus map class GUIDs to names such as Wall, Beam, Column, Ceil for a slab, and VBElem::FreeShape for a morph. Descriptor records also carry serialized version information.

Associations connect those objects. A measured single-reference association entry contains an opcode, an association GUID and a target object GUID. Other measured forms carry a count followed by several target GUIDs. Association declarations can describe endpoint roles, while the per-object tails supply the actual linked identities.

Walls make this concrete. Some legacy wall records carry a usable inline footprint. Authored Archicad 29 walls in our controls keep the footprint in linked VBD::WallVRDData objects. Following the validated relationship gives the reader the relevant polygon data. Geometry reconstruction then checks placement, vertical span and supported opening relationships before producing wall surfaces.

The embedded preview is a separate project record

The measured container has a reserved project-preview record. When an image is saved there, the reader can extract the project PNG from its decoded payload. The record can also be present with an empty preview field. This explains why preview availability depends on the saved project.

The preview provides a saved visual reference. The 3D scene is assembled from model records, so you can inspect it from different viewpoints. Open the live pavilion PLN to see the decoded building and navigate around its roof, wall openings and terrain.

What the browser reader can render

The supported scope includes walls with door and window openings cut through them, slabs, pitched roofs, zones, beams, columns, morphs, meshes and terrain. Door and window support represents the opening in the host wall. Files from Archicad 25, 27 and 29 have been decoded and tested, with coverage depending on the element representation stored in each file.

The reader accesses selected byte ranges and decompresses the records needed for supported geometry. Parsing runs locally in the browser, and the resulting scene uses meters with a Y-up coordinate system. Geometry checks and explicit decoding limits define the accepted scope. Unresolved class layouts and field meanings remain subjects for further research.

This guide describes our measured implementation scope. It provides a basis for understanding why file identification, decompression, active-object selection and geometry reconstruction are separate steps. For the practical workflow, see opening a PLN file online. Exports use the geometry that the viewer successfully decodes.

Frequently asked questions