Navisworks → IFC exporter documentation

Everything the BIMCamel IFC exporter does, and the order to do it in. The plug-in is free and open source, runs inside Autodesk Navisworks Manage and Simulate 2024–2027, and exports NWD, NWF and NWC models to IFC4 or IFC2x3. This guide covers both ways people use it: the one-click export when you just need geometry out, and the mapped, checked deliverable you repeat every revision.

The one-click export

When you need geometry out of Navisworks and into IFC with no configuration.

Open the pane (Ribbon tab) — Open your model in Navisworks, then click BIMCamel → IFC exporter on the ribbon. The pane docks like any other Navisworks panel and remembers where you put it.
Leave the defaults (Export tab) — IFC4, units read from the model, the whole visible model, balanced geometry quality, instancing on and validation on. Every default is chosen so the first click produces a valid, correctly placed file.
Export IFC (Export tab) — Pick a filename and the export runs, then writes a full report: element counts, what did not make it into the file and why, timings and the validation result. Without mapping rules every element exports as IfcBuildingElementProxy — an honest geometry hand-off, and the report says exactly how many.

The mapped, checked deliverable

The workflow a BIM coordinator repeats every revision — prepare, scope, discover, review, verify, export, save — where each step is done once and reused through export profiles.

Prepare selection sets in Navisworks (Navisworks tab) — Save a selection or search set for everything you want classified. A search set is already an IF/THEN rule — "Category = Walls AND Name contains External" — so building it once in Find Items keeps the mapping live as the model changes. This is also the moment to deactivate DataTools links: they run a database query per object and can dominate the whole export.
Pick the scope (Export tab) — Whole visible model, current selection, the active section box, one saved set, or batch — multiple sets exported to one IFC each. The scope decides what every later step measures.
Run Smart setup (Export tab) — One button runs every auto-detect in order: reload sets, sample the model for property sets, propose the four semantic roles, propose set→class mapping rules, and preview the result. It prints what it did — sets found, roles filled versus kept, rules added — and never overwrites anything you typed.
Review the data (Data tab) — Check the four semantic roles point at the right source properties: Type, Level, Material and Classification. Untick property sets you do not want shipped — excluded sets are never even read, so this also makes the export faster.
Finish the mapping (Mapping tab) — Complete the rules Smart setup could not guess, add PredefinedTypes and classification codes, and name the classification system. Press Preview after edits: it resolves the rules against your scope and reports mapped versus proxy counts, the per-class breakdown and property coverage — before anything is written.
Set the coordinates once per project (Coordinates tab) — Choose the base point (how large the stored coordinates are) and, if the deliverable is georeferenced, the CRS and survey point (where the model sits on Earth). On a federation, check the model origins report — differing origins are normal, mixed declared units are not.
Read the Pre-flight panel (Export tab) — The trust check before you commit: live rows for schema, units, georeferencing and federation agreement, plus scanned rows for element counts, rule-match rate, storey coverage and role coverage. Green means current, amber means something will silently not be written, and each amber row points at the tab that fixes it.
Export, then save a profile (Export tab) — Export IFC and read the report. Then save a profile from the title bar — schema, scope, coordinates, roles, parameter rules and the whole mapping grid in one .json. Next revision: load the profile, run Smart setup to pick up anything new, preview, export. The revision diff tells you what changed since last time.

The pane, tab by tab

Export

Run the export: what schema, how much of the model, and the checks before you commit.

Smart setup — one button running every auto-detect in dependency order.
Output — IFC schema (IFC4 or IFC2x3) and source units (read from the model by default).
Scope — whole visible model, current selection, active section box, one saved set, or batch.
File options — geometry quality, size splitting, instancing, post-export validation, size and time breakdown.
Pre-flight — the readiness checks, live and scanned.
Report — the full account of what the export actually did.

Data

What each element carries into the IFC: property sets, materials, quantities and the four semantic roles.

What to export — properties, materials and colours, base quantities written as Qto_ base-quantity sets.
Property sets to include — the checklist Smart setup fills; nothing scanned means everything exports. Scan selection instead reads only the elements you picked in Navisworks.
Semantic roles — which source property carries Type (IfcElementType), Level (IfcBuildingStorey), Material (IfcMaterial) and Classification (IfcClassificationReference). Blank turns a role off.
Parameter mapping — rename a source property or move it into a different target property set.

Mapping

Which IFC class each Navisworks set becomes, and the classification codes that travel with it.

The rule grid — one row per set: IFC class, optional PredefinedType, optional classification code.
Preview — resolves the rules against the current scope and reports mapped versus proxy counts, the per-class breakdown, property coverage and a geometry estimate.
Classification and groups — the classification system name written as IfcClassification, and exporting each mapped set as IfcGroup, IfcSystem or IfcZone.

Coordinates

Where the model sits: the local base point, and the real-world survey point.

Base point — geometry origin (default, keeps stored coordinates small), model origin, or a custom point, with a live preview of the resulting origin.
Georeferencing — IFC4 IfcMapConversion: a CRS such as EPSG:27700, the survey point of the model origin in that CRS, and grid rotation.
Federated model origins — every loaded model's origin, rotation and units, and whether they agree.

Structure

The names written into the IFC spatial hierarchy.

Project, site and building names written to IfcProject, IfcSite and IfcBuilding.
The fallback storey name for elements with no Level value — real storeys come from the Level role on the Data tab, with elevations read from the model's grid levels when they are named.

Key concepts

Base point versus survey point

These answer different questions and are set separately. The base point answers "how big are the numbers stored in the file?" — it never moves the model, because the placement chain puts everything back at its world position regardless. Geometry origin, the default, keeps coordinates small, which is what viewers want and what Revit requires: it refuses geometry more than about ten miles from the origin. The survey point answers "where is this model on Earth?" — it becomes the IFC4 IfcMapConversion, written only when you actually supply a CRS or offsets, because an empty map conversion is worse than none.

Why elements export as IfcBuildingElementProxy

Navisworks has no IFC classes: it has geometry, a tree and properties. Something has to decide that a given element is an IfcWall, and that something is a mapping rule or a semantic role. Anything unmapped falls back to IfcBuildingElementProxy — a valid IFC element with the right geometry and properties but no semantic type. That is the correct answer for a pure geometry hand-off, and the wrong one for a data deliverable, so the preview, the Pre-flight panel and the export report all count proxies separately and say why each one happened.

How mapping rules compose

Rules do not compete — they compose per assignment kind, earlier rule winning. A broad rule mapping every wall to IfcWall and a narrow rule giving external walls a Uniclass code both apply to an external wall: it gets the class from the first and the code from the second. A row may set a class, a code, or both. Rules bind to sets by display name, so renaming a set in Navisworks orphans its rule, and two sets sharing a name make rules bind to the first — the Pre-flight panel warns about exactly that.

What IFC2x3 cannot carry

Choose IFC2x3 only when the receiving software demands it. It has no IfcMapConversion, so georeferencing cannot be written (the placement still carries the world offset), and a handful of newer classes have no 2x3 equivalent — elements you deliberately mapped to them fall back to proxy. The exporter never does this silently: those elements are counted separately in the preview, the Pre-flight panel and the report, each time with the note that exporting IFC4 keeps them.

Reading the Pre-flight panel

Rows come in two kinds and the panel keeps them honest. Live rows — schema, units, georeferencing, federation agreement — recompute every time you open the tab. Scanned rows — element counts, rule-match rate, storey and role coverage — come from the last Smart setup or Preview, carry the time and scope they were measured under, and lose their green tick the moment you change a setting they depended on. Severity follows one rule: unset is normal, contradiction is amber. No mapping rules is a deliberate geometry hand-off; no CRS is a normal local-grid project; federated models with different origins are federation working correctly. Amber is reserved for data that will silently not be written.

Profiles and the weekly loop

A profile is a .json holding the export settings — schema, scope, coordinates and georeferencing, the semantic roles, parameter rules, the full mapping grid, classification system, spatial names and split settings. It is what turns a carefully mapped export into a repeatable one: save it beside the deliverable, and next revision load it, run Smart setup to pick up anything new in the model, preview, export. Old profiles load in new versions; list ticks and the theme are not stored.

What this exporter cannot do

Navisworks carries triangulated geometry and properties, so these are genuine limits of the source, not gaps in the plug-in.

Mesh geometry only — every element is written as triangulated surfaces (IfcFacetedBrep or IfcTriangulatedFaceSet). No parametric solids, no extrusion profiles: the result is for coordination, review, QTO and handover, not for re-authoring.
No spaces or rooms — Navisworks does not carry IfcSpace, so there are no space boundaries and no space-based COBie sheets.
No openings or voids — IfcOpeningElement and void/fill relationships cannot be reconstructed, because openings reach Navisworks as geometry that is already cut.
No material layer sets — materials export as names and colours, not as IfcMaterialLayerSet build-ups.
No element connectivity — IfcRelConnects relationships are not present in the source.

Troubleshooting

The plug-in does not appear after copying the bundle manually

Windows kept the browser's "downloaded file" mark on the DLLs and Navisworks refuses to load them (PLUGIN_LOAD_02 / 0x80131515). Run the setup executable, which strips the mark automatically, or unblock the files in PowerShell.

Windows SmartScreen blocks the installer

The installer is unsigned. Click More info, then Run anyway. Every release publishes a SHA-256 checksum next to the download so you can verify it first.

The export takes far longer than the model size suggests

An active DataTools or external-database link runs a query per object. Deactivate it under Home → DataTools and export again. The report detects the symptom and names the fix when it happens.

Everything exported as IfcBuildingElementProxy

No mapping rule matched. Run Smart setup on the Export tab, review the proposals on the Mapping tab, and press Preview to see the counts before exporting again.

Every element landed on one storey

The Level role is pointing at a property that is either missing or the same for everything — the Pre-flight panel shows one distinct storey when this happens. Fix the Level role on the Data tab.

The model is far from the origin, or Revit refuses the import

Keep the base point on Geometry origin so stored coordinates stay small, and put the real-world position in the survey point on the Coordinates tab.

A class you mapped still exported as a proxy

That class has no IFC2x3 entity and the export used IFC2x3. Export IFC4 to keep it — the preview and report count these separately from unmapped elements.

A saved set is missing from the Mapping dropdowns

The list reloads whenever you open the Mapping tab, and sets inside folders are included. A Find Items search only appears once you have saved it as a set in Navisworks.