Rhino 8 - Design to Production - Rhino.Inside vs Native BIM in Rhino

Rhino.Inside Revit
, , , ,
1

Rhino 8 released a number of drafting, annotation, and data management features. I’ve seen mixed reviews about Rhino’s drafting capabilities as a full production tool, but these discussions go back to 2022 Rhino 8 for Architects - Rhino / Rhino for Windows - McNeel Forum

Rhino’s drafting and data management capabilities seem to have changed with the addition of line styles, dynamic 2D drawings and some new Elefront-like data tools. Grasshopper now has access to a lot of these drafting features.

Has anyone used Rhino to produce architectural construction drawings? We use a computationally heavy workflow and would love to keep everything in Rhino.

The features that we would need to produce architectural drawings and in Rhino are listed below. I’ve included plugins that we are exploring to deliver these features.

  1. BIM objects to draw architectural floor plans and sections. We are looking at VisualARQ. I’ve seen mixed reviews on the forum.

  2. Data Schedules. For data Elefront has been great and Rhino 8’s new features can replace Elefront. Schedules are a different story. VisualARQ appears to be able to generate schedules but does not have any interface to manage data through an data grid. The only tool I’ve found is AntFarm - data management for Rhino and GH - Pre-Release out now - News - McNeel Forum but it is not actively maintained. There doesn’t seem to be any good solution to managing and presenting data within your model in a coherent way.

  3. 2D drawings & Document Managment. This seems to have changed in Rhino 8 Rhino - Features (rhino3d.com) It looks like there is now also a layout panel. Rhino - Layout Management (rhino3d.com)

  4. Collaboration: Curious about what workflows structural engineers and MEP engineers are using. Right now Revit would be the standard to bring in Structural and MEP and Architectural drawings all in one place. Could Speckle Home | Speckle replace Revit with an online tools to bring all this data into one model and then back into Rhino?

For those of you thinking why not use Rhino.Inside, we have been using Rhino.Inside to migrate Rhino models to Revit for documentation. Managing the flow of data back and forth is a bit of a challenge to keep everything synced. The main issues we are running into are:

1)Geometry Conversion The current geometry conversion engine to push Rhino to Revit is not 100% reliable. It’s been getting better, from the early WIP tests, but I want to spend time designing not resolving geometry conversion issues.

  1. Complex Workflow Management Revit is just plain complex and rigid. Overall it’s additional work to manage the Rhino.Inside process. I find our team spending a lot of time figuring out which family vs direct shape to convert to that will look right and also tag correctly. There is also the question of what to model in Revit and what to model in Rhino. All doable, but it requires a carefully crafted workflow.

  2. Detailing and Fabrication happens outside Revit Fabrication drawings and details are difficult to produce in Revit. We find ourselves using AutoCAD and Rhino to produce details and fabrication drawings. Other than dynamic blocks Rhino’s drafting is fairly robust. Other firms I’ve worked at have imported PDF from AutoCAD into Revit for detail pages.

This got me wondering. . . . why am I using Revit? Apparently, I’m not alone in my frustration Letters to Autodesk (letters-to-autodesk.com)

Instead of running Rhino inside Revit why not bring BIM capabilities to Rhino?

Should we invest in improving the Rhino to Revit workflow or invest in bringing BIM to Rhino?

3 Likes
2

Thanks for putting this together, its a great topic and relevant to a lot of Rhino Users.

One aspect of Rhino is its lack of constraints, to allow users to make their workflows the way want to. This feature has its pro/cons, one of which is its not a ‘turnkey solution’ to many standard workflows.

A good example is Revit in its ability to do some of these workflows really well but highly constrains the user and the ability to take things to 100%.

The new GH1 components are opening up a lot of potential workflows, particularly in arena creating your own standards. Note that these are still in development and as the features get filled in over the upcoming months we will be going into more depth on these workflows.

Turning Rhino into a native BIM object modeler isn’t on anyone’s radar, to make it more flexible and developable for all Users is a major goal (Architecture is only a small part of the user base)

At this time the best (most efficient) BIM workflows are going to be hybrids with other applications.

1 Like
3

Blockquote “At this time the best (most efficient) BIM workflows are going to be hybrids with other applications.”

Or potentially using a plugin to bring some BIM capabilities to Rhino?

I’m also curious to hear how firms are using Rhino.Inside in practice. How much modeling is being done in Revit natively vs inside Rhino. What has been successful?

1 Like
4

Hey @Benjamin_Paolo_Fortu - (we overlapped at SHoP for a bit, though I don’t recall us spending any project time together)

We’re just getting started on a new project in my current office and will be looking to hybridize our drawing set as much as possible. We’re primarily a Revit office when it comes to documentation, but a subset of us are extremely well versed in Rhino/GH and thus the RIR workflow. We’ll look to let each software do what it does best - in our case, relying on Revit for traditional 2D drawings like plans, elevations, and sections (referencing Rhino/GH-created geometry as natively populated into Revit as often as can be), while using Rhino-based drafting with these new annotation tools where it makes sense (ie unrolled drawings, diagrammatic axons, sequencing diagrams, etc) - drawings that Revit doesn’t nicely produce. Recently I’ve gone more of the in-between route, populating unrolled drawings into Revit drafting views for annotation, but the thought is that maybe the compiled drawing set will be output from the two models side-by-side. There are other issues, like drawing indices, revision tracking, tagging, etc that we’ll have to consider, but the overall ambition we’re setting out with is to let Rhino-created geometry exist more fully as Rhino documentation where it makes sense. As you’ve mentioned, this is often better for downstream partners like fabricators anyways.

That’s our current thinking - ask me again in a year and we’ll see how this all shakes out…