I am familiar with how a component family can be created an placed into Revit, but I am wondering if there is a way I can divide them into types based on some key user attributes with RiR.
For instance, I have a panel that I want to keep them in one family, but few different types based the following parameters. Is it possible for current or near releases?
Morning Japhy, that is what in my head too, but I couldn’t think a way that make the the dimension change actually happen in the type, without manually assigning reference planes in Revit.
To my knowledge, the process of “Draw Reference Plane” – “Draw a Revit Dimension” – “Set Up a Parameter” – " Assign the Parameter to the Revit Dimension", without opening a family file, is not capable with current release.
That would get very granular for each Family. Its quite easy to create these relationships via the UI vs a programmatic solution that would require the user to organize and manage each aspect.
Similar to this recent request for Nested families.
Yeah, nested family is similar. It could be another useful feature, but it could be messy too, depends on how users actually use it. To me, the difference between “Nested Family” and “Divided Family into types” are something very likely to the difference between “Recursion” and “Iteration”, subtle and context related.
I am asking about “Divided Family into types”, because we have some sophiscated Rhino models that have controls for key dimensions. Rebuilding it in Revit or manually setting up the dimension parameter is a redundant of labor and causes mis-interpretation of design intent.
In the Rhino to Revit process, for instance, a panel type(“type” in natural language, not Revit terminology) will have different general widths and heights. If I use family to control it, I will have about 100 families, but if they are at the type level, the amount of family will be reduced to about 15-20.
I am not sure how Revit handles heavy geometry data, but I have a gut feeling that creating types and use parameter to control the general shapes will lighten the model and result a better performance. It is crucial for the team.
About the “Nested Family”, in lots of cases I met, Revit couldn’t handle it well in a large project, especially when it is beyond 3 layers. It is mostly used for furniture, doors, curtain walls(a little different, by still nested family, you are the expert about the code beyond it). In my practice, I am trying to reduce the amount of “Nested Family” to that magic number or no nested family at all.
There are a lot of ways to setup families (like projects), some of which will be slower than others.
What you are describing seems pretty straight forward, but hard to say without example data/geometry.
I will be back to this thread next week to upload a simplified sample. Sorry that I can’t just upload what I have due to NDA.
Hi Japhy, I attached 2 simple files to illustrate the issue.
In the Rhino file there are 5 blocks for different window frames. They actually act as 2 kinds of window frames with their own variations. I am trying to use PARAMTER X and the dimension to mimic what they would be in Revit.
In Revit file it can be simplified as 2 or 3 families with its own types. Not sure if I am correct, my assumption is when those 5 frames are 5 families, the Revit file size will be larger and its performance will be affected while there are, for instance, 5000 pieces of them.
Currently, when a parameter is related to change geometry, RiR seems can only reach to the “Family” level, which will have a potential performance risk for Large project. It is why I am asking if RiR can support some geometry-related parameters settings in Revit Family, so it can be functional at Revit’s Type level. If there is no difference for the performance between using family to hold every different object and separating them with Family-Type hierarchy, then what I said is not necessary.
FamilyTypeInstance_rh.3dm (163.5 KB)
FamilyTypeInstance_rv.rvt (732 KB)
In the post earlier in the Thread i showed accessing the parameters at the Type Level. Unless I’m misunderstanding something.
Using Types is the right approach.
Yeah… there is some misunderstanding. Sorry Japhy, I am not a native speaker, will try my best to think in English. The method you show is to change the design with parameters existed in Revit already. In that way, a user needs to set up the family in Revit first, RiR is used only for pushing fixed geometry into a Revit family file.
If I built up 4000 panels with 30 different frame types(type in common sense, not Revit types) in a sophisticated GH script, I need to go into each of those types to set up the parameters what I already did in GH again.
I am wondering if a smoother workflow is possible for the scenario above.
Ideally, a user can use GH components like “New Component Family” to add dimension parameters to each different type as type parameters, without going back to Revit interface, without editing those families one by one, again and again.
In summary, the question is how do I set up a Revit file similar to what I uploaded with RiR, instead of how to utilize it.
Have a good weekend!
You can coordinate your parameters from Rhino to Revit, but to make a proper Revit Family you will need to do so with the Revit UI.
got it 
This is a question we hear often. At the core of the problem, there is a boundary between Rhino and Revit that cannot be crossed. I will try to explain.
Simply put either Grasshopper or Revit needs to be in control of any element. Although there are places control can be blurred.
What is possible:
What is not possible:
It is understandable that certain model geometry may be easier to define with Grasshopper. But technically there is no way to determine if Revit’s Parametric Family engine will be able to create the same geometry.
Please ask any questions you have about this. I would like to determine a clearer way of explaining the limitation/
Hey Scott,
Thank you for the explanation! From a developer’s perspective, it is clear what is possible and what is not possible between the 2 platforms. I have no questions about “What is possible,” which is what I am currently doing for some workflows. Japhy’s workflow from “Duplicate Type” can solve most non-Geometry-related data transfers.
For “what is not possible,” the first sentence you describe is not exactly the expectation. The expectation is “Baking Key Dimension Parameters”. In most cases, those Key Dimension Parameters are linear and straightforward for a single-family/type element. Setting them up for the entire project is tedious and different for every project or even after every client meeting.
Changing a geometry-related Type parameter will cause an unexpected ripple effect in the BIM model. It is the current nature of Revit BIM Configuration. It has been decades since parametric design theory was applied to AEC projects. At this point, most BIM managers will not have the “Full Automatic Level of Development” fantasy with parametric tools. An “Ultimate Modeling History Backtracking” is tempting but harmful to the model’s performance. Controls after baking with the original grasshopper script are not necessary, even if it is possible. The element will probably be released from GH control after the key Dimension Parameter is baked or the control happens in a different script on a different GH canvas.
Few points why I insist the “not possible” could be “partially possible”: (Only from a user’s perspective, if it is a hardcore tech issue, I will shut up.)
When a user wants to use RiR baking geometries into Revit’s Category|Family|Type|Instace Hierarchy, this person is already in the mindset of at which level or context the geometries parameters could work for the project, instead of an attitude that “I want a full control of all the geometries.” Certain flexibility of form control from GH has to be given up, so the whole BIM set is robust.
1.1. Revit has limited geometry control using Dimension Parameter, even with Dynamo. Users need to understand it. When geometry control is linear, Revit’s way of setting up form should not becomes the limitation of setting up parameters. Even in Revit, they are different steps: Set up the geometry, Dimension it, Set up Dimension Parameter.
1.2. The Revit UI nature has already limited what Dimension Parameter can be applied anyway. In this case, the purpose of using GH in this process is not to be creative anymore. It is about the massive operation.
Revit’s UI is not a solid point to bring up. Revit’s UI system is outdated compared with new Software used in other Industries like gaming or app development. Its UI system is also deeply integrated with some rigid logic that developers set up 20 years ago at the bottom level for the users to compromise. For instance, a software with similar parameter user setting logic from a similar era is iTunes. Lots of users like Apple’s products but not iTunes. Users may not understand the software development process and details, but they know what a bad design is.
For the Key Parameters, keeping a family/type linear and simple that fits Revit’s requirement is a wicked problem that actual product or project designers need to figure out. There is no software can fully predict how users are going to use it. When Binary and Aggregation challenge realities, they always fail. Even though there will be fails and errors, they are not determined by the Software Platforms. Fails and erros in RiR is similar to what happened between Rhino and Grasshopper. When the Grasshopper script crashes Rhino, no one has the authority to blame the developers. There are existing Geometry and Logic Laws beyond software development that not everyone can see, but everyone needs to follow.
3.1 There are also limitations to how a software platform can express those laws. Revit and Rhino are fine as 2 software platforms that do not follow the exact logic and are not connected all the time, especially for geometries. Professional software users don’t expect one tool to do everything. In some cases, the expectation is the tedious workload can be reduced.
To sum up, giving or not giving a limited dimensional parameter control for Rhino. Inside Revit will not hurt its greatness. If the feature exists, it saves tremendous time for a team with advanced Rhino and Grasshopper skills while tediously setting up how abstractive planes need to be associated with geometries in a not user-friendly UI system.
There is no need to describe how great a tool RiR is and how it will change the AEC design process. Unfortunately, a tool as excellent as RiR also triggers fantasies from the power pyramid tip of the AEC Industry. Something needs to be done to buffer that fantasy from falling to people who are actually doing all the spaghetti operations.
