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.
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.
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!
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
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
(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)
@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.
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 ), 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)
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 notRevitTopography. 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.
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.
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.
), so that won’t really solve the problem.
