Create a window-family (test) which contains a nested family (glassfilling --- shared, generic model)
I label that nested family so it can be exchanged
So basicly what I expect to happen is when export this family (test) to ifc I get an IfcWindow which can be decomposed into Glassfilling.
Same as a curtainwall can be decomposed into members / plates etc.
Any thoughts on why it doesn't work like this / can it be achieved?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When you specify a shared nested family, we do export that as a separate object. When we export a family that contains that, we share the geometry, but we don't explicitly "contain" the families within. It seems like an interesting idea - although I'm not sure if all software is prepared for doors and windows to be containers - so I'd ask the thread two questions:
Is this what people would generally expect?
IFC doesn't allow a container to have its own geometry - so, e.g., an IFCWINDOW contains sub-elements with geometry, or it contains geometry. What do we do with geometry in the window that isn't in a nested family?
Thanks,
Angel
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I do think people expect a relation between elements just like the example Joris gave.
I’m not sure how to do something like that in IFC. You are talking about a container. But IFC has the ability to establish a relation between objects with IfcRelDecomposes. IfcGroup is not specific enough. And I think that a curtainwall is an IfcElementAssembly
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A curtainl wall is actually just IfcCurtainWall. We can use IfcRelDecomposes and have the top level object be, for example, an IfcWindow. That would be required, vs. IfcGroup or IfcElementAssembly, for the classification. However, IFC requires that either:
All of the geometry of the IfcWindow be directly in the IfcWindow, or
All of the geometry of the IfcWindow be contained in the entities related via IfcRelDecomposes.
So what do we do with a Revit window that has (for example) 2 shared, nested sub-windows, plus extra geometry? Where does the extra geometry go?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well if IFC simply requires one of these 2 options and if you ask me. I do not have a problem with a new/extra Id. As discussed before. Or give the user simply the option to generate more elements than Revit has. At least the whole assembly of objects have a direct relation with each other. And an indirect relationship with the original Revit GUID, containing the nested and shared and the only nested geometry.
But perhaps IFC or some other software have a statement about new Id's to and this is simply out of the question. Just curious about other opinions.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
Relations between shared families in IFC are definitely wanted! The option Angel describes with 2 shared, nested sub-windows and extra geometry is in my opinion not consistent. There are different principals used in 1 (host) family, so as long as you use 1 principal it will work. Or all geometry in a (window) family or everything nested. I prefer using a host family in Revit just as host and load the family’s. In that case the example doesn’t apply. It is a consistency within the workflow.
@Angel: Creating a connection between shared family’s which will be very useful (we now link them with an extra parameter within Revit) If you are looking into the subject can you add the (known) issue with the DOOR Operation in 2D? See attachment. This only occurs with shared family’s…or hopefully send an solution for this problem.
Operation is only filled out in the shared family containing the door panel, so if you can split the nested families with relations you might solve this problem as well…
Thanks
Example:
Create a window-family (test) which contains a nested family (glassfilling --- shared, generic model)
I label that nested family so it can be exchanged
So basicly what I expect to happen is when export this family (test) to ifc I get an IfcWindow which can be decomposed into Glassfilling.
Same as a curtainwall can be decomposed into members / plates etc.
Any thoughts on why it doesn't work like this / can it be achieved?
Hi Joris,
When you specify a shared nested family, we do export that as a separate object. When we export a family that contains that, we share the geometry, but we don't explicitly "contain" the families within. It seems like an interesting idea - although I'm not sure if all software is prepared for doors and windows to be containers - so I'd ask the thread two questions:
Thanks,
Angel
A curtainl wall is actually just IfcCurtainWall. We can use IfcRelDecomposes and have the top level object be, for example, an IfcWindow. That would be required, vs. IfcGroup or IfcElementAssembly, for the classification. However, IFC requires that either:
So what do we do with a Revit window that has (for example) 2 shared, nested sub-windows, plus extra geometry? Where does the extra geometry go?
Well if IFC simply requires one of these 2 options and if you ask me. I do not have a problem with a new/extra Id. As discussed before. Or give the user simply the option to generate more elements than Revit has. At least the whole assembly of objects have a direct relation with each other. And an indirect relationship with the original Revit GUID, containing the nested and shared and the only nested geometry.
But perhaps IFC or some other software have a statement about new Id's to and this is simply out of the question. Just curious about other opinions.
Hi,
Relations between shared families in IFC are definitely wanted! The option Angel describes with 2 shared, nested sub-windows and extra geometry is in my opinion not consistent. There are different principals used in 1 (host) family, so as long as you use 1 principal it will work. Or all geometry in a (window) family or everything nested. I prefer using a host family in Revit just as host and load the family’s. In that case the example doesn’t apply. It is a consistency within the workflow.
@Angel: Creating a connection between shared family’s which will be very useful (we now link them with an extra parameter within Revit) If you are looking into the subject can you add the (known) issue with the DOOR Operation in 2D? See attachment. This only occurs with shared family’s…or hopefully send an solution for this problem.
Operation is only filled out in the shared family containing the door panel, so if you can split the nested families with relations you might solve this problem as well…
Thanks
hi angel,
Is there any progress on this item?
Can we expect any relationship between shared elements in the future export?
Hi Angel,
Just seeing if there is an update on this?