IFC (openBIM) exchange

Read and write ISO 16739 IFC files: import a coordination model to see it beside your design, import an alignment natively so it becomes real geometry you can edit, and export your design as IFC 4.3 for the rest of the project team.

IFC support is an optional module. If the IFC entries are missing from the menu, your build was made without it — nothing else in the application changes.

What the versions mean for you

Version	What you can do
IFC 2x3 and IFC 4	Import buildings and models as geometry with their properties. These versions have no alignment entities at all — nothing is lost by us, the format simply cannot carry a road or rail alignment.
IFC 4.3	Everything above, plus alignments (horizontal, vertical and cant) that import as native yucad3d geometry — and this is the version we export. natively. Export to 2x3 / IFC 4 also works: every downgrade the older schema forces is listed in the export report, never applied silently.

Measured, not assumed. The import path is verified against a 285-file public corpus (buildingSMART samples + the IfcOpenShell test files): 2x3 and IFC 4 files import with their geometry, GlobalId identity and typed property sets intact — across the corpus every harvested property kept its schema type. The only failures are deliberately malformed fuzz files from the parser test-suite.

Importing

IFC ▸ Import IFC Model reads a file in three passes, and tells you in the message log exactly what each one produced:

Geometry. Every product with a shape becomes a display mesh. Each object keeps its IFC GlobalId, its class (IfcWall, IfcSlab …) and its property sets — click one in 3D and the Properties dock shows them.
Alignments (4.3 only). Each alignment becomes a real alignment node: line, arc, clothoid, the Bloss / cosine / sine / Helmert transition family and the cubic parabola all map to native segments; the vertical layout becomes a profile with parabolic and circular curves; a cant layout becomes a stored cant profile.
Structure. The spatial tree (site, building, road, railway, bridge and their parts) and the layer entities (course, pavement) appear in the Object Browser with their properties.

Refusals are loud, and that is the point. If a file contains an alignment segment whose exact definition is not published — the Viennese bend, or a vertical clothoid — that alignment is refused BY NAME with the reason, and the rest of the file still imports. yucad3d will not silently approximate one curve type with another: a 4 cm surprise you never asked for is worse than a message you can act on.

Editing IFC as IFC

An imported model keeps a live link to its file. Property values shown for a picked object are editable: changing one writes into the IFC file in memory, and IFC ▸ Save IFC Edits writes it back to disk.

Undo works normally — one undo restores both the value you see and the value in the file.
Types are preserved: a property the schema defines as a boolean stays a boolean. If what you type cannot be that type, the edit is refused and nothing changes.
Nothing touches the file on disk until you save.

Merging two files

IFC ▸ Merge IFC Files asks for a base file, a file to merge in, and where to write the result. Objects carry a GlobalId, and two files can legitimately contain the same one; the merge never resolves that silently — duplicates are given a fresh GlobalId (the copy IS a new object) and the counts are reported.

Exporting

IFC ▸ Export Alignments (IFC 4.3) writes the document as native IFC 4.3: alignments with their horizontal, vertical and cant layouts, the spatial structure, and imported models as tessellated products that keep their original GlobalId and class.

Exporting to an older version is refused with a loss report listing exactly what that version cannot carry, rather than quietly writing a file that has lost your alignments.

Validation

Exports are checked against the official buildingSMART Validation Service — STEP syntax, IFC schema and normative rules all pass. Two advisories remain by choice: we do not invent station referents, and we do not invent a coordinate reference system. Both are real data the file simply does not have; fabricating them would make the file look better and BE worse.

Practical notes

Situation	What happens
File with Turkish (or any non-ASCII) characters in its path	Works. Paths are handled as UTF-8 end to end.
Corrupt or non-IFC file	Reported as a failed import; the application keeps running.
Large model	Products import as one display mesh grouped by object, so a building with thousands of parts does not flood the Object Browser.
Round-tripping your own export	Re-importing an exported alignment reproduces the geometry to within a micrometre — the export and import share one definition of the maths.