RiR, Clusters, Hops and Grasshopper 2

Rhino.Inside Revit
1

Lately, I’m once again dealing with the preparation of hundreds of apartment building sheets.
I’m trying to make a robust, reusable solution. Once again I fooled myself that I could prepare a very compact definition, but the nature of this task and the readability concerns swelled every part of the definition again.

While the definition is in the WIP stage it’s better for me to have everything in one GH file and control the flow by disabling groups. I don’t like using multiple GH files at once, because communication between each other is a hassle.

I can’t use Hops because of technical limitations.

Making User Objects out of clusters would be perfect but they have long-standing issues with empty paths and potentially more problems.
There are also issues with unwanted Revit transactions when editing the cluster. Every time I open the cluster a new transaction is made. Editing and closing the cluster forces me to re-create elements.

I wanted to ask just a general question / signal the problem. Ideally, there should be a solution that will do everything that Clusters and Hops can and address the mentioned RiR issues. I wonder how Grasshopper 2 will deal with these problems but this is still very far away I’m afraid.
In the meantime, I would be happy to have some solution for a container that would visually shrink Grasshopper groups.

Do you have any concepts that users can look forward to?

2

Hi Jakub,

Rhino.Inside.Revit complicates this a bit due Elements being project specific, so .ghdata in/out between projects of Revit Elements is generally not going to work.

Hops/Clusters aren’t a viable option due to the concerns you’ve mentioned.

Grasshopper 2 is going to take some time to gain traction and we’ll cross that bridge when we get there. At this time i’m not seeing anything along the lines you are talking about in terms of functionality.

Personally i’m a big fan of smaller GH scripts vs spaghetti. Yes, this requires multiple GH files that need to be run in sequence but in my view is easier to maintain.

The issue is how to rebuild a list/tree in a new file, its easier just to keep adding on to the original definition. This is how we get spaghettified.

One way is to send and receive, like i did in this recent post , if working with Rhino.Inside.Revit you would want a list/tree of Element Ids to rebuild in the next definition.

Maintaining tree structure is the problem, getting used to rebuilding lists/trees is the solution.

1 Like