The Problem
Architecture and structural engineering increasingly receive building models not as native Revit files but as IFC exports — from ArchiCAD, FreeCAD, Vectorworks, or international consultants working in open BIM workflows. Revit’s built-in IFC importer handles these by converting every element to a Direct Shape: a non-editable mesh proxy that carries no parametric behaviour, cannot be scheduled by type, does not participate in quantity takeoff, and cannot be joined to structural framing. For a structural practice that needs to annotate, analyse, and document a building received as IFC, this is a dead end. Every wall has to be redrawn by hand.
The IFCRevitImport suite is a Grasshopper-based pipeline that eliminates this rebuild. It takes IFC geometry and property data and produces fully native, parametric Revit walls and floors — correct type, correct level, correct location line — with all IFC Pset data written back to Revit shared parameters. The bridge between environments is Rhino.Inside for Revit, which runs Rhino 8 and Grasshopper inside an active Revit session, giving Grasshopper direct write access to the Revit document.
Development moved through eleven script iterations — seven for walls alone — as increasingly complex IFC geometry was encountered on real projects. Each iteration expanded what the pipeline could handle: from simple rectangular walls, through slanted walls and profiled openings, to heavily tessellated surfaces requiring geometric healing before any profile could be extracted.
Stage 01 — Geometry Extraction
The IFC model is opened in Rhino. Each element — wall or floor — arrives as a Brep solid whose geometry reflects whatever the originating software produced: sometimes clean extruded prisms, more often triangulated meshes or non-manifold solids with duplicate faces, inverted normals, or open boundary loops left by the IFC exporter.
For walls, the pipeline deconstructs each solid using Deconstruct Brep to separate its faces, edges, and vertices. Merge Faces consolidates coplanar faces that appear as separate triangles due to IFC tessellation — a 10 m² wall face might arrive as forty triangles that must be unified before any profile can be read from them. Cap Holes Ex closes any open boundary loops. The resulting cleaned solid is then sorted by face area: the largest planar face is the wall’s elevation surface, and its boundary is extracted as a closed planar profile curve.
This profile extraction was the hardest part of the pipeline to make robust. The first approach — extracting a simple baseline curve and extruding to height — failed as soon as walls had non-rectangular tops, slanted faces, or raked profiles. The profile-based approach (Add Wall (Profile)) handles arbitrary wall shapes, but it demands a clean, planar, correctly oriented closed curve as input. Getting that curve reliably from real-world IFC geometry required seven iterations of the extraction logic, each one handling a new failure mode encountered on an active project.
Floors use a parallel logic: the horizontal bottom face of each slab solid is extracted as the floor boundary, with openings in the slab identified as inner loops of the same face.
Stage 02 — Type Mapping
Each IFC element carries its properties inside standard property sets. The Query Element Parameters component reads the full Pset structure of every incoming element, extracting:
IfcMaterialandPset_WallCommon.Reference— the material description and reference code from the originating modelPset_DIMENSIONI—Altezza(height),Larghezza(width),Lunghezza(length),SuperficieLaterale(lateral surface area),Area,VolumePset_ID— the project’s WBS classification tree:WBS,WBS_Componente opera,WBS_Disciplina,WBS_Fase,WBS_LOTTO,WBS_Parte D'opera,WBS_SuboperaPset_ID.Uniclass— Uniclass 2015 classification codeIfcName,IfcDescription
An Element Type Picker component maps IFC material descriptions to GPA’s project wall type library. The mapping covers the full range of wall types used on the project: exterior walls at various thicknesses (A_M_Esterno_Generico_135, _80, _75, _70, _60, _55, _50), interior masonry and partitions (A_M_Interno_Blocchi laterizio_25, A_M_Interno_Cartongesso IDRO_12.5), fire-rated assemblies (A_M_Controparete_Cartongesso IDRO_7.5_EI60), CLT / cross-laminated timber (X40-muro esterno xlam), and curtain walls. Each incoming IFC material string selects one Revit wall type from this list; unmatched types fall back to a generic type for manual review.
Stage 03 — Native Element Creation
With a clean profile and a resolved Revit type, the Rhino.Inside components create the elements directly in the active Revit document:
Add Wall (Profile)instantiates a native Revit wall from the extracted profile curve, mapped wall type, level from the IFC storey, and location line set to Wall Centerline. TheAllowJoinsflag is passed through, and structural usage is set per element.Add Flooruses the extracted boundary loop (with slab openings as inner loops) and the mapped floor type.
The result in both cases is a Revit element indistinguishable from one modelled natively: it appears in wall and floor schedules, cuts correctly in sections and plans, can be joined to structural framing, carries thermal and acoustic parameters from its type, and responds to all standard Revit editing operations.
Stage 04 — Parameter Write-back
The final stage uses the Element Parameter component to write every extracted IFC Pset value to the corresponding shared parameters in the newly created Revit elements. WBS codes, Uniclass classifications, reference strings, and all dimension data from Pset_DIMENSIONI land directly in the Revit model parameters — without manual re-entry and without loss of the information chain from the originating consultant’s model.
This write-back is the part of the pipeline that makes the output usable for structural practice. A native Revit wall with no WBS code cannot be linked to a cost plan. A wall with the correct WBS_Fase and WBS_LOTTO values is immediately schedulable for quantity surveying, federated to the project’s cost breakdown structure, and traceable back to its IFC source.
Development Record
The pipeline exists in eleven saved versions in the project folder — an accurate record of the real iterative development process:
IFCRevitImport.gh— initial prototype, simple extrusion approachIFCRevitImport_02,_03— early parameter reading testsIFCRevitImport-SIMPLIFIED.gh— first simplified architecture without the parameter block-SIMPLIFIED-WALL.gh,-WALL-01.gh— profile approach introduced-WALL-01-curve.gh— curve-only extraction fallback for simple walls-WALL-01-profilethrough-WALL-07-profile— seven iterations of profile extraction geometry, each resolving a new failure mode-WALL-07-profile_single.gh— single-element test harness for geometry debugging261002_IFCRevitImport-SIMPLIFIED-wall.gh— production version-SIMPLIFIED-FLOOR.gh,-FLOOR-01.gh,261002_IFCRevitImport-SIMPLIFIED-Floor.gh,-Floor-02.gh— parallel floor script development
The eleven iterations are not redundancy — they are the engineering record of a problem that was harder than it first appeared, solved through systematic exposure to real project geometry.