Rhino to Revit: Turning Design Geometry Into a Model You Can Document

The handover that keeps going wrong

A design team spends four months in Rhino. The massing resolves, the facade rationalises, the client signs off. Then the model lands on your desk with a one-line brief: “can you Revit this?”

Two weeks later the project is behind. The geometry came across, technically. It sits in the Revit model as a beautiful, useless lump. It does not schedule. It does not tag. Windows will not host in it. It does not bound rooms, so the MEP team has no spaces to work with. The file has grown to 900 MB and views take forty seconds to open.

Nothing went wrong with the transfer. The transfer worked exactly as designed. What failed was the assumption underneath it: that geometry and a BIM model are the same thing.

They are not. Rhino describes shape. Revit describes a building: elements that belong to categories, carry parameters, host other elements, define enclosure, and roll up into schedules. When you move a Rhino model into Revit you are not moving a file. You are deciding how much of that building meaning you are going to rebuild, and who pays for it.

This guide is written from the receiving side. You are the BIM coordinator or modeller who now owns a documentable, coordinatable, schedulable Revit model, and you have to make that call.

Decide the outcome before you touch the geometry

The single biggest time saver on a Rhino handover is a fifteen minute conversation before any file moves. Write down what the Revit model has to do, because the answer changes the route entirely.

Ask these five questions:

1. Does this geometry need to appear in a schedule? If the facade panels need a panel schedule with type, area and finish, imported geometry is already ruled out.
2. Does anything need to host in it? Doors, windows, curtain panels, light fixtures. Imported geometry hosts nothing.
3. Does it need to bound space? Rooms, areas and MEP spaces need real room-bounding elements. An imported wall bounds nothing.
4. Will it be tagged or dimensioned on a drawing? Tags need a taggable element. Dimensions need clean, planar reference geometry.
5. Will it go out as IFC for coordination or checking? If a rule-based checker has to classify it, category assignment matters.

If the answer to all five is no, the geometry is context or reference. Link it, keep it light, move on. If the answer to two or more is yes, you are rebuilding in Revit and the only question is how much of the rebuild you can automate.

That single distinction, reference geometry versus building elements, decides everything that follows.

The three routes, and what each one actually costs

There are three honest ways to get Rhino geometry into Revit. Everything else is a variation on one of them.

	Rhino.Inside.Revit	Imported geometry (SAT, DWG, DirectShape)	Native remodelling
Output	Real Revit elements (walls, floors, families, adaptive components) or categorised DirectShapes	Import symbols or DirectShapes	Real Revit system families and loadable families
Schedules	Yes, full parameters	Limited. Category-level only, no type data	Yes
Tags and dimensions	Yes	No tags. Dimensioning is unreliable	Yes
Hosting	Yes, on real host elements	No	Yes
Room bounding	Yes	No	Yes
Compound structure and material takeoff	Yes on system families	No layers, so no takeoff by layer	Yes
IFC export class	Correct class from the category	IfcBuildingElementProxy unless mapped	Correct class
Updates when design changes	Re-run the definition	Reload the link	Manual rework
Setup effort	High up front, low per iteration	Very low	Low up front, high per iteration
Best for	Repetitive, rule-driven geometry: facades, panel arrays, structure	Context, massing, reference, one-off sculptural forms	Everything standard, and anything that must be documented

Read that table as a cost model, not a ranking. Each route is correct for something. The mistake is picking one by habit rather than by what the model has to do.

Route 1: Rhino.Inside.Revit

Rhino.Inside.Revit, McNeel’s free plugin, loads Rhino and Grasshopper inside the Revit process. Both applications share one memory space, so Grasshopper components can read Revit elements and write new ones directly. You need a licensed Rhino on the machine, and the Revit and Rhino versions have to be compatible.

This is the only route that turns rule-driven Rhino geometry into genuine Revit elements at scale. The components that matter in practice:

• Add Wall, Add Floor, Add Roof. Feed a Rhino curve or surface, get a real system family with a compound structure, room bounding, and a material takeoff by layer.
• Add Component. Place loadable family instances at points or on faces. This is how a panelised facade becomes a schedule of real panels rather than a mesh.
• Add Adaptive Component. Drive a 3, 4 or n-point adaptive family from a Grasshopper point grid. For any panelised surface this is usually the right answer, because every panel is a taggable, schedulable family instance that carries its own parameters.
• Add DirectShape. The escape hatch for genuinely freeform geometry, but with a category assigned so it is at least filterable and classifiable.

The real value is not the first run. It is the second one. When the facade rationalises again at Stage 4, you re-run the definition instead of remodelling three hundred panels. On a project with genuine geometric repetition, that payback arrives within one design change.

The honest cost: someone on the team has to know Grasshopper properly, and the definition becomes a project deliverable that needs its own version control and its own owner. If nobody owns it, it rots the moment that person rolls off.

Route 2: Imported geometry, and exactly what breaks

Sometimes reference geometry is all you need, and importing is the correct, cheap answer. Use it deliberately, and understand the ceiling.

Prefer Link CAD over Import CAD. Revit links SAT, DWG, DXF, DGN and SKP. A link updates when the design team reissues, it can be unloaded when it is not needed, and it never merges its junk line styles and layers into your project. Imported CAD dumps line patterns, text styles and layers into the model permanently, and those are a well known source of template drift.

Wrap it in a family when you need a category. The standard trick is to create a Generic Model family, link or import the SAT inside it, assign the family a sensible category and subcategory, then load and place it once in the project. The wrapper gives you category-based visibility control, a place to put shared parameters, and a schedulable element. It does not give you real building behaviour.

DirectShape is the better technical option. A DirectShape is a Revit element that holds arbitrary geometry but is assigned a real category, so it filters, schedules at category level, exports to IFC with a plausible class, and can carry parameters. Rhino.Inside.Revit creates them cleanly. This is as close as imported geometry gets to being a citizen of the model.

Now the ceiling. Whatever wrapper you use, imported geometry:

• Does not host. No doors, no windows, no wall openings, no face-hosted fixtures.
• Does not bound rooms, areas or MEP spaces. Room bounding requires walls, floors, roofs, ceilings, columns, curtain systems or room separation lines. Your imported facade gives the MEP team nothing to place spaces against.
• Has no compound structure. No layers means no material takeoff by layer, which quietly removes it from any 5D quantity workflow.
• Does not join, cut or wrap. No wall joins, no automatic cleanup at junctions, so plans and sections will need 2D patching.
• Cannot be tagged. Dimensioning to it works only where you can find a stable reference, which on triangulated geometry you often cannot.

The pattern to internalise: imported geometry is LOD 300 shape carrying LOI 100 data. It looks finished in a 3D view and is empty everywhere the model actually gets used.

Route 3: remodel it natively, and stop apologising for it

Remodelling has a bad reputation because it sounds like wasted work. Often it is the fastest route to a model that survives documentation.

Remodel natively when the geometry is mostly orthogonal, when it is standard construction wearing an interesting skin, when the design is still moving, or when nobody available knows Grasshopper well enough to build and maintain a definition.

The efficient version is not remodelling from scratch. It is:

1. Link the Rhino geometry as SAT or DWG, positioned correctly.
2. Set it as a background reference with a halftone or a dedicated subcategory.
3. Model native Revit elements against it, snapping to its edges.
4. Unload the link once the native model is ahead of it.

On a typical mid-rise where only the facade is genuinely complex, teams that go straight to native modelling for the structure, cores, slabs and internal walls, and reserve Rhino.Inside for the facade alone, finish ahead of teams that try to convert everything. Split the model by how geometrically interesting each part really is, rather than treating the whole handover as one problem.

Units, tolerance, and the triangulated mesh trap

Three technical failures cause most of the frustration on this route. All three are preventable before export.

Units. Rhino models carry a document unit that people rarely check. A Rhino model set to millimetres exported into a Revit project set to feet, or the reverse, produces geometry off by a factor of 304.8 or 1/304.8. Set the Rhino document units to match the Revit project units before exporting, and check one known dimension after import. A quick sanity check on a single door opening catches this in ten seconds.

Tolerance. Rhino works to an absolute tolerance you set per document, typically 0.001 to 0.01 mm depending on the template. Revit has a hard floor: it rejects curves shorter than roughly 1/32 inch, about 0.8 mm, and refuses geometry it considers degenerate. Rhino surfaces built with sliver faces, near tangent edges or micro trims fail conversion and either drop silently or arrive triangulated. Ask the design team to rebuild and run a clean check before handover.

Mesh versus NURBS. Revit’s geometry kernel does not accept every NURBS surface Rhino can produce. High degree surfaces, heavily trimmed surfaces and anything derived from a subdivision or mesh workflow get converted to a triangulated mesh on the way in. A smooth double-curved canopy that was 4 MB in Rhino can land as a 200 MB mesh in Revit, and that mesh regenerates in every view that shows it. If the geometry has to be smooth, rationalise it into planar or single-curved panels in Rhino first. Panelisation is a design decision, and it belongs upstream of the transfer, not downstream of it.

Placement: shared coordinates and the far-from-origin trap

Rhino has no concept of a survey point. Designers routinely model wherever the site survey happened to land, which can be hundreds of kilometres from the Rhino origin if the survey was in a projected coordinate system.

Bring that straight into Revit and you hit a wall the platform will not move for. Revit’s precision is tied to distance from its internal origin. Push elements far enough out and you get inaccurate snapping, unreliable dimensions, visual jitter, and eventually Revit’s complaint that elements are too far apart. Revit starts objecting once model extents run to about 20 miles, and precision degrades noticeably well before that.

The workflow that holds:

1. Ask the design team for the real world coordinate of one identifiable point, plus the project north rotation.
2. In Rhino, move the geometry so that point sits at or near the Rhino origin before export. Do the translation upstream, where it is a single move, not downstream where it is a coordination problem.
3. In Revit, place the geometry against the internal origin, then use Acquire Coordinates from the survey link or Publish Coordinates to the site model so the federated set agrees.
4. Record the applied translation in the BIM Execution Plan. Six months later nobody remembers the offset, and the next consultant to join will need it.

Coordinates are the one thing worth being pedantic about on day one. Everything else on this list is recoverable. A model set out wrong is not.

What imported geometry does to your IFC and your QA

If the project runs openBIM coordination, this is where geometry-only transfer becomes visible to everyone else on the project.

Revit exports elements to IFC classes based on category. Imported geometry with no meaningful category lands as IfcBuildingElementProxy. Clash detection still works, because Solibri and Navisworks will clash any solid against any other solid. Rule-based checking does not. Any rule that says “all external walls must have a fire rating” or “all doors must carry a type reference” simply skips your proxies, and your Information Delivery Specification checks return a clean pass on a model that contains nothing checkable.

That is the failure mode worth naming: proxy geometry does not fail QA loudly. It passes quietly by being invisible to the rules. If you must ship imported geometry, assign categories deliberately, map the IFC export classes in the export setup, and tell the checking team which elements are proxies so their rule set accounts for them.

Common mistakes

• Converting everything. The whole model does not need the same treatment. Sort geometry into “must be documented” and “reference only” first.
• Accepting the file without a conversation. A fifteen minute call about units, origin, panelisation and tolerance saves days.
• Importing rather than linking. Imports are permanent and they pollute the template with foreign line styles and layers.
• Treating a 3D view as proof it worked. It looks right in 3D and fails in every schedule, tag, room and section.
• Placing geometry at survey coordinates. Precision loss and warnings you cannot fix later without moving the whole model.
• Building a Grasshopper definition nobody owns. If one person holds it and leaves, the facade is frozen.
• Not telling the design team what broke. If they never learn that their sliver surfaces cost you two days, the next handover is identical.

How to start

If a Rhino model is landing on your desk next week:

1. Run the five questions above and write the answers down. Schedules, hosting, room bounding, tagging, IFC. Circulate them.
2. Split the geometry into two buckets: documented elements and reference geometry. Route each bucket separately.
3. Agree the exchange in writing. Units, origin point and rotation, file format, panelisation level, naming, and reissue cadence. Two paragraphs in the BEP is enough.
4. Test on one small piece first. One bay, one panel type, one floor. Take it all the way to a sheet with a tag and a schedule line before you commit to a route for the whole building.
5. Only then scale up. If the test bay documented cleanly, the method holds. If it did not, you have lost a morning rather than a fortnight.

The transfer is never really the hard part. The hard part is being clear about what the Revit model owes the rest of the project, and choosing the route that delivers it. Get that decision right and Rhino to Revit stops being a recurring crisis and becomes a normal, planned step in the workflow.

Working through Revit families, shared parameters and coordination workflows in depth is exactly what the courses at Archgyan Academy are built around, taught from live project practice rather than theory.