Rhino <> Revit for landscape architecture

I need some tips for my colleagues in our landscape department for good work workflows for working with landscape in Rhino and moving / coordinating them to Revit. I’m a Revit guy so I’m mostly used to working with all the orthogonal tools so I need some tips to avoid newbie traps.

Since Revit is very poor at handling the types of forms and edges common to landscape projects that is where my focus will be. What’s a good way to bring a Rhino surface into Revit as a Revit Toposurface? What about roads and curbing? Can they usefully be mapped to Revit Model Categories?

Links, tutorials and advice are very welcome. I haven’t been able to find much myself.


With a simple script, you can send a Rhino surface to Revit as a Topography using Grasshopper🦗.


Thanks @gokermu ! With some quick help from our friend @cyril we got it to work. Revit seems to be a bit picky about the meshes it will accept so I’d love some pointers on that. Otherwise I’ll just have to start experimenting.

Still looking for general tips on Rhino <> Revit for landscape architecture.


1 Like

@DuncanNZ, my experience is that for toposurfaces you need to work with 2.5D meshes. While Rhino can handle full 3D geometry, Revit can’t.



Essentially, for any XY coordinate you can only have one Z value, so no overhangs, caves etc.



Hope this helps!


Is it possible to export meshes as topography directly from Rhino without going the Grasshopper way?

There is no obvious way of doing it via the UI:

1 Like

Not yet, but that’s something that could be added relatively easily! cc @clrkng

We’re also undergoing a broader effort to improve these CAD>BIM and BIM<>BIM flows where metadata needs to be “enriched” or “mapped”, so stay tuned!


Looking forward to it!

The reason I’d like to see it directly in Rhino is because some of our users don’t have any Grasshopper skills. Probably this could be done with grasshopper player (though triggering the send component is not trivial) but dedicated UI would be much appreciated!

1 Like

Hey @mariuszhermansdorfer , this should be fairly straightforward to add in Rhino! I just opened an issue here and I’ll let you know once it’s complete :slight_smile:

1 Like

Ok, I just added Topography to our Rhino toolbar! This will be available with our next 2.7.0 release, but if you would like to test the feature sooner, I can create a new Rhino beta release now :slight_smile:

(Keep in mind that you may need to delete the staged .rui file in your Rhino appdata folder before updating your Rhino connector release to see the new toolbar)

1 Like

Awesome @clrkng!

If it’s not too much hassle, it would be great to get my hands on it soon. Unless you’re planning on releasing the 2.7 version in the next days.

Keep up the good work!

@DuncanNZ, another common issue I’ve found is that sometimes Rhino meshes aren’t properly welded. This typically happens when you extrude edges. In this basic example you can visually see 8 vertices, but further analysis shows that it’s actually 12.

This will cause the following error in Speckle:

One or more points shared the same XY location (even with different elevations). This is not permitted for topography surfaces.
Parameter name: points

Welding the mesh in Rhino prior to export helps fix the issue:

@teocomi, @clrkng could welding be done on the converter side? Maybe make this optional if having unwelded meshes is desired for some applications?

We usually tend to try and keep the geometry as unmodified as possible, and leave all decision making to the modelling platforms of choice.

I do agree that it makes it slightly confusing to know what’s accepted and what not, and if something will work when received (we’re working on some reporting and preview upgrades that will make this better)

We could look into enforcing this on the Revit side, but you could still send meshes that Revit will not accept as valid topographies (such as a bunny, or a sphere, an entire building :sweat_smile:), so that won’t really solve the problem.

Maybe a more “sturdy” solution would be to throw an error when the same XY is shared by any 2 or more points. This will directly prevent you from creating it (at least in Grasshopper).

In Rhino, I guess we could try to weld it by default, but I’d rather let the user know what’s wrong and let them make a decision, than take a decision ourselves that will only be valid 10% of the time (meaning, most meshes out there don’t meet this restriction) :slight_smile:

This is more of a personal opinion, as I haven’t discussed this with the team. What do you think @mariuszhermansdorfer?


Currently, our Rhino BIM components produce generic Speckle BuiltElements : in this case, using the new Topography command will attach Topography schemas to your Rhino meshes and not RevitTopography. The only geometry check I am implementing on assignment is preventing closed meshes from generating Topography.

We will probably add Revit-specific support in Rhino BIM in the future, but I do not think additional checks like XY coordinate sharing makes sense for the generic Topography schema, as that failure is Revit-specific and there may be other modelling platforms that can handle redundant mesh XY vertices in their topography class.


Makes sense! Hadn’t thought of different support between both GhBIM and RhinoBIM when writing my reply

I guess for the Gh RevitTopography node it would still make sense to add that validation though.

1 Like

Yah, shouldn’t be too difficult to add the check for the Revit node as a set comparison of mesh coords by XY points! I would agree on throwing a descriptive error instead of by default welding the input mesh, in line with your point about not making assumptions & modifying geometry

Agreed, an error message in Rhino/GH interface would be great to have! Also, maybe try making it a bit more user friendly to include a few suggestions on how to fix it?

Something like:

Oops, selected geometry can’t be used as a Revit toposurface. One or more points shared the same XY location (even with different elevations). Try welding all mesh vertices and verify that there are no vertical or overhanging faces.


Just released 2.6.2 for Rhino which includes Topography support - let me know if you run into any issues :slight_smile:

1 Like

As @clrkng suggests such an error in the RhinoGH interface would suggest Speckle cannot accept the object. That’s probably not true. The error message should be in Revit when trying to receive the element.

“The current stream includes an object from Rhino Mapped to Topography which is invalid. Please see our documentation for suggestions on how to fix this issue”

I still think the error message should also be displayed on the Rhino side. Imagine you finish your part of the assignment in Rhino, hit publish to Revit, verify that the model was uploaded to the server and… leave for 2 weeks of holidays. Two days later, when I open Revit and want to continue from where you left off, the toposurface doesn’t import.

The exporter choice already determines that we want it to be a Revit-compatible surface, so it’s good to warn users early that it will not work at the destination.

I like the link to documentation in the error message, though.

Hey @clrkng, thanks for the heads-up!

It works as expected - I can tag Rhino meshes as Topography and send them to Revit without ever opening Grasshopper! Sweet :slight_smile:

A few suggestions:

  1. The font/background color combination in the comment section is very difficult to read:

  2. Each time a toposurface is imported into Revit, it defaults to Material - ‘By Category’. Is there any way of preserving the last applied material?

1 Like