Revit to Rhino using RhinoInside

Hello there,

At first thank you so much for creating this wonderful addons in GH dev team.

Is it possible to bring changes back from Revit to Rhino. For example created wall in Revit using RhinoInside tool CreateWall and selected Line in Rhino to build wall inside revit. If i change wall in Revit will the Rhino Line gets updated? Do you have any nodes for that?

1 Like


Well, no so direct, but you can connect any Revit curve like element to a curve parameter in Grasshopper, it will be updated every time you move the Revit element.
Latter you can Bake it when you want it into the Rhino model.


Does it help?


Hi @kike

Thank you so much Sir! This is exactly what i was looking to do. I will try and post back soon. That “P” node is Element.Geometry node?

And also when we update Line in Rhino it Deletes old and Create new Element inside Revit rather than updating existing element with the same id. Do you have any nodes to update existing ones without deleting.


You are welcome.

Well, in reality, you have both, Preview and Geometry.

Preview extracts meshes, basic materials, and wires from Revit elements. Just for display or analysis.
The second one converts Revit element geometry to Rhino geometry. Right now extracts breps when Revit geometry is just planar faces. I’m still working in to make it work with curvy surfaces as well.

1 Like

Thanks that makes sense to me now.

Is it possible to update existing elements without deleting them and creating new?

No, right now there is no component that works that way, just to keep the code “simple”.
I’m sure it has all the sense updating instead of recreating all the time.
Could you please explain to me a bit more in detail what problems is causing in your case the way it works now. Thanks.

If you select One Curve in Rhino and CreateWall in Revit, assign value to that wall parameter “Comments” as “Test” and then if you modify Curve in Rhino it Recreates New Wall Element inside revit you will see that Value “Test” is gone. Hope i explained well. Once again thanks for looking into this :slight_smile:


I pushed a change into the repo that should fix the case you are describing.

In any case, I agree with you that should be nodes that update elements.
The first one that comes into my mind is the Element.ParameterSet, in this case, is obvious that should update without recreating the element.

Anyway thanks for pointing out this case.

Thank you Sir! Does Element.SetParameter coming soon?

You can test it compiling the “revit/wip” branch from here


Please have you got à gha for test this ! It’s wonderful plugin

We are currently working on an installer.
As soon as is available I will post it here.


Thanks, I can’t wait!

Dear @Kike!

Refering to this post I would like to explain a bit more in detail why it is important in our case to update the elements with the same Revit ID instead of deleting those.
We use another software in our follow-up process for fabrication and construction. This software works with revit models and we add status parameters to the elements to follow-up our process. When we are setting our Revit model up in this other software, it uses the elements Revit ID to link additional information to the model elements (fabrication status, package information etc.). If we modify the model later with Rhino.Inside.Revit all the additional data which is stored in this software will be erased because of the new Revit IDs.
It is not an option that we should have a final model and after we can start the work in the other software. The two process run parallel from certain design phase.
Do you have any idea how can we solve this problem?
Thank you in advance!

Hi @zsolt.gutleber,

We are aware of that problem, and we are working into address it.
The first thing we are trying to warrant is in the case the user runs two times same Grasshopper definition over the same model with the same input values, no object is replaced even in different sessions.

The prototype we have is able to remember, between sessions, which component creates which element. When Grasshopper runs a new solution over the same model it is able to reuse those elements, but there are ocassions when the Revit API does not allow us to modify an element the way the user is asking for.
In those cases Rhino.Inside replaces the previous element with a new one. It keeps all the parameters from the previous Element that fit in the new one, this includes BuiltIn, Project and Shared parameters.

To talk about something specific, changing a wall base curve from a line to an arc implies a replacement, this is a kind of change Revit API do not allow.
An other example may be changing the sketch of a floor, there are ways of moving the edges, but if the change implies a new edge, as long as I know, the only way to do that is replacing the floor with a new one.
There are many others.

One thing we are also considering, for those cases where it is not possible to reuse the same Element, is to save the original UniqueId in the replacement and provide a way for third parties to acces it. This way a third party software will be able to know this “new” element is a replacement of the previous one and will have the possiblity of update their indexes acordingly.

We are “near” to release a version with that behaviour implemented.
I guess that would be easier to answer once it is released, but would that work for you?


Hi @Kike!

Thank you very much for your great explanation! I’m absolutely sure that you will find the way to develop this feature. Rhino.Inside.Revit is already a excellent plugin and a huge help for us.
We are looking forward the new release!

Hey! just a couple of workaround ideas:

You can bake your rhino geometry to a loadable family and then place instances of that family in your project. You can update them by saving a new version of that family and loading it into the project. The ID of the placed instances will keep.

This is of course dependant on you not needing system families (walls, floors, ceilings, roofs …) as you can´t load those. But for Structural Framing. Furniture, or whatever your following process can accept as Generic Models, it works quite well.

Alternatively, if your “follow up” software accepts IfcGUID values as well as Revit ID to track changes to revit elements, you can just edit those values in (read value before an update, delete old instances, create new ones, write old ifcGuid to new elements) - but that is a big IF.

(edit: removed stuff about conceptual massing, as turns out it doesn’t work)

1 Like

Thank you @half.baked! We will try these workarounds as well and I was thinking about that big IF option :slight_smile: too, but we haven’t had enough time to try it so far.