When importing a surface from Rhino that is intended to be a wall. Is there a way to specify the location line of the wall be created in Revit? It seems as though it always brings it in at the center line of the Revit wall.
Hi @bspkdesign,
Yes, center of wall is the default behavior. You can specify the default behavior on import behavior for walls - which is applied globally at the moment.
A few ideas:
- I could expose a Grasshopper parameter for walls so it can be readily specified per-wall there (would that be helpful?)
- I could try to add support for a Semantic property that would allow users to control this within Rhino itself.
For now - check this out:
Nathan,
Thank you for the response. Let me expand on my question. I have to Surfaces in Rhino that define a ‘Design Surface’ for a room. The measured distance is 7’-6" between walls. When I translate the geometry to Revit, regardless on specifying location line, the geometry always comes in at the center line of the imported geometry. Is there a way to control this? See attached Images:
@bspkdesign ah, I see what you mean here - There are some known limitations with Revit API wall creation - namely with how wall locations are assigned:
- Creating a new Wall assumes the centerline of the wall is always used at the point of creation.
- Changing the Wall location line will change where the wall “grips” appear, but will not change the original centerline wall creation.
Therefore any wall created will be based on “Wall Centerline”
Even changing the Location Line assumption does not move the location (a known Revit API limitiation)
So the way around this is…
- In Rhino, define a set of surfaces representing the centerline of your wall assembly. This means you have to create some surfaces distinct from your current surfaces. This will give you the most flexibility with the resultant Revit element
- In Rhino, use “Walls-FaceBased”: Revit does allow face-based walls to have a defined location line (like Finish Face:Interior) when they are created that will reflect the desired condition.
Face-based walls seem to work here but they take longer to create and surface normals/face direction can be unpredictable when translated to Revit. You also can’t directly edit a Face-based wall.
Here is an image of two similar sets of parallel walls. Both have Finish Face:Interior Set. One pair has their normals reversed so you can see how the walls are being applied differently.
Thank You Nathan. This is what I am working on right now. It is shop drawings for a Stair in one of our projects.
@bspkdesign
Would you want to have all studs/assembly represented in Revit as you’ve drawn them here? If so, another option could be to combine portions of your assembly into blocks, and load them into Revit as families. You could assign Rhino materials to different components and adjust your drawing Revit graphics with the use of Materials and Subcategories.
I mocked up a wall assembly with studs, drywall, and some insulation as an example. These objects are modeled on typical Rhino layers with some material assignment. They are combined as a block (see attached Rhino model.)WallAssembly.3dm (157.8 KB)
I imported the objects in - Rhino material names are coordinate with the Revit material names so they get assigned. The family can be cut and all of the individual stud and other assembly geometry is represented.
You can also dimension to this imported geometry which may be useful for shops.
This is great! Thank You. Do you have access to the Stair part of the Revit API for Conveyor?
@bspkdesign For now, you could try a similar block technique to get your exact Rhino-modeled stair solids and assembly in - combine your elements as a block, import and update definitions and instances.
There are some API stair methods but for native parametric stairs, they require the “defining geometry” as inputs (such as the profile, path, etc.) which are not readily derived from Rhino solids that a user may have modeled.
We could try to expose a category that could work to classify DirectShapes as the stair category but it would lack some attributes that a Block-Family import would have.
Nice!!!