I am attempting to understand how the subcategories are created using Rhino.Inside.Revit, and I thought I made a nice breakthrough seeing the subcategories are created. However, the subcategories and the geometry are not linked. I am not sure what might be incorrect, especially because I tried to link the geometries independently before sending them to the main Category component.
If a list of objects are fed into the Add Family Form component, then it will be one objects with a series of Breps in it. In the example I Grap[hted up the output on the Add SubCatergory output to match the Tree inputs of Breps.
I am also not a big fan of adding multiple wires directly into an input as is Geometry input of the New Family. I think using and intentional merge component or the like is a better practice.
If you can send us the 3dm file in addition to the GH you already sent that would be great. You can just Export Selected the objects you want to get into Revit and send that smaller 3DM file if you want.
Scott thank you so much! If simply merging the lists is what I need to do to avoid a lot of data confusion then that it what I will do.
One of my biggest hurdles is visualizing these data streams and understanding how they need to be organized for each function.
Is the intentional merge component you are talking about the pink component here? I tried looking through the whole component library and was not able to find it.
The bench solids needs to be cleaned up to be accepted by Revit as a subcategory, but I am not sure then why the wood slats are not accepted either.
Generally your definition is fine. And it seems you do understand how to create sub-categories. But, it is in the small details that this can get complicated. Just to illustrate how many choices there are here to answer, let’s go thru some issues below that may help. Since 4 benches with many slats is more complicated, to start I only use one bench.
It is probably best first to do only one bench at a time to best understand that choices that need to be made. I deleted the other 3 benches, but kept the original structure of the definition. Here is the one I am working with:
The New Family component has an overwrite toggle. That should be set to True if any changes are going to be made to the Family definition after the first run, which would mean any fixes you do would not change anything. So, set Overwrite to True, so the Family definition updates:
You can see from the list of objects collected by elefront that there is one open trimmed surface in the collection. Revit is not going to like that much. So finding it and deleting it is a good idea. I run Selsrf command in Rhino to find that surface and delete it.
After that the Family component still throws and error. It has to do with open edges. Upon closer inspection, there are very small edges on the bench. I run Edge Analysis in Rhino and look for naked edges.
You can see the original definition is very close to this. And the subcategories are correct.
Now if all 4 benches need to be extracted and placed in 4 different Families, then Japhy’s example above shows how that would work. That takes one more Tree branching structure to keep the components to the 4 benches separate.