Hi!
Correct me if I’m wrong but, as far as I understand, the IFC-specs do allow aggregates within types. Why BBIM doesn’t allow this behaviour?
I can predict some cascading problems with it (solving the geometry, changing within instances, all the dependent stuff) but it is methodologically correct, right?
@bruno_perdigao I'll test it with my use case later this week and report back.
I'm creating assembly of various element type and copying fine.
Changing the element type representation changes in all copies. It's magic!
IMHO I think the next step is to turn the assembly into an "assembly type", place it in the Types collection and create a way to make the copy using BIMTool.
From the user's point of view, it is more similar to the way other types are treated.
And maybe it's the answer to @VDobranov
@VDobranov@walpa Yes, the ideal scenario would be to make it work as a type. As far as I know, the IFC-specs do allow the IfcElementAssemblyType, but it's not clear about how to implement the duplication of its children. I still want to try another approach when I have the time (hopefully soon). I want to explore this idea, and try to make the duplicates share representation.
The IfcRelDefinesByObject page has some insightful pics explaining how the types should aggregate occurences which are defined by their own types:
(and with Representations)
@VDobranov Wouldn't you like to create another topic with this theme?
Replicate your last post there and put a reference to this thread.
IMO, makes it easy for anyone to search for this in the future. :)
It’s been three months already, but thanks to a burst of activity lately, I seem to have managed to create an example file with IfcRelDefinesByObject relations.
Moreover, I’ve tried to leap further and made nested aggregations, which, in my own opinion, is the biggest thing about all this concept. I am sure that the apex of its development are infinitely nested aggregations, modelling all kinds of physical hierarchies (fractals!)
This is how I see the zoomed out scheme:
(for example: frame > column > base > bolt group > bolt kit > individual nut)
The resulting file consists of two assemblies each made of two sub-assemblies and concrete slab. Sub-assemblies are made of 5 sheets and an insulation part. All physical parts are based on types. Sub-assembles and assemblies are based on their own types too.
All aggregated elements have an ObjectPlacement.PlacementRelTo referenced to ObjectPlacement of their immediate aggregation. They also inherit ObjectPlacement.RelativePlacement from the objects that define them. Thus, when the relative placement of the original object changes, all of its copies repeat the changes with respect to placements of their aggregating objects.
But this approach do not work well with BBIM or IfcOpenShell’s high-level functions as far as I understand: if I move an object from BBIM UI its local placement is created anew instead of changing existing one. I couldn’t befriend aggregate.assign_object either. I realize that a good portion of these problems are due to my own inexperience, but it is what it is.
Because of all this, I was able to take advantage of the nested aggregations only through Python scripts:
That’s it for now. I haven’t touched any other sides of the topic (Representations, Materials, PSets, etc.) but I think they are already more developed than placements.
File attached to the post if anyone is interested.
@VDobranov Good work!
Is the workflow you used to model IfcElementAssemblyType the same as IfcElementAssembly?
How did you instantiate IfcElementAssemblyType? Did you use BimTool?
Please post a video showing how you did it.
Thanks
Unfortunately, there is no way to achieve it through the UI (at least, I didn’t come with any).
So everything is done through Python-scripting. Rather messy one, to be fair.
I’ve prepared small IFC-file through BBIM, which have usual template stuff and three types of physical objects (IfcPlateType for sheets, IfcBuildingElementPartType for insulation and IfcSlabType for concrete base).
Everything else is made through the algorithm:
1. Create physical instances of 5 IfcPlates (sheets);
2. Assign them representations;
3. Assign them IfcPlateType;
4. Assign them spatial container (IfcBuildingStorey);
5. Create local placement for them relative to the container;
6. Adjust their local placements to make box-like model out of them;
7. Repeat for 1 IfcBuildingElementPart (insulation);
8. Create IfcElementAssemblyType which will typify sub-assemblies;
9. Aggregate all 6 physical instances with just created IfcElementAssemblyType through custom "aggregate_assign_object" function (as dumb as possible);
10. Create instances of 2 IfcElementAssembly (sub-assemblies);
11. Assign them the IfcElementAssemblyType;
12. Assign them spatial container (IfcBuildingStorey);
13. Create local placement for them relative to the container;
14. Use recursive function "copyPartsFromType" which take all the instantiated objects that decompose the type (and relating objects in recursion), shallow copies them, assigns Relating Object to each copy through custom function mimicking the "assign_type", then aggregates them into corresponding sub-assembly, and finally makes the local placement of sub-assembly as the reference placement for each copy;
15. Adjust the local placements of the sub-assemblies;
16. Create IfcSlab (concrete base) and everything that comes after as with IfcPlates;
17. Then repeat the process for several main assemblies with assigning sub-assemblies and the slab to a main assembly type, instantiating it and RelDefiningByObject all its content through recursion.
18. Flush the model into a file.
@VDobranov This is really good. I was looking on working on IfcRelDefinesByObject just about a week back. Will test this out now.
The links for the python file and the ifc file doesn't work though
Comments
Hi!
Correct me if I’m wrong but, as far as I understand, the IFC-specs do allow aggregates within types. Why BBIM doesn’t allow this behaviour?
I can predict some cascading problems with it (solving the geometry, changing within instances, all the dependent stuff) but it is methodologically correct, right?
@bruno_perdigao I'll test it with my use case later this week and report back.
I'm creating assembly of various element type and copying fine.
Changing the element type representation changes in all copies. It's magic!
IMHO I think the next step is to turn the assembly into an "assembly type", place it in the Types collection and create a way to make the copy using BIMTool.
From the user's point of view, it is more similar to the way other types are treated.
And maybe it's the answer to @VDobranov
@VDobranov @walpa Yes, the ideal scenario would be to make it work as a type. As far as I know, the IFC-specs do allow the IfcElementAssemblyType, but it's not clear about how to implement the duplication of its children. I still want to try another approach when I have the time (hopefully soon). I want to explore this idea, and try to make the duplicates share representation.
@walpa @bruno_perdigao continuing my spelunking of specs I've found this info if it helps:
(and with Representations)
@VDobranov Wouldn't you like to create another topic with this theme?
Replicate your last post there and put a reference to this thread.
IMO, makes it easy for anyone to search for this in the future. :)
i can split this convo.
It’s been three months already, but thanks to a burst of activity lately, I seem to have managed to create an example file with IfcRelDefinesByObject relations.
Moreover, I’ve tried to leap further and made nested aggregations, which, in my own opinion, is the biggest thing about all this concept. I am sure that the apex of its development are infinitely nested aggregations, modelling all kinds of physical hierarchies (fractals!)
This is how I see the zoomed out scheme:
(for example: frame > column > base > bolt group > bolt kit > individual nut)
The resulting file consists of two assemblies each made of two sub-assemblies and concrete slab. Sub-assemblies are made of 5 sheets and an insulation part. All physical parts are based on types. Sub-assembles and assemblies are based on their own types too.
All aggregated elements have an ObjectPlacement.PlacementRelTo referenced to ObjectPlacement of their immediate aggregation. They also inherit ObjectPlacement.RelativePlacement from the objects that define them. Thus, when the relative placement of the original object changes, all of its copies repeat the changes with respect to placements of their aggregating objects.
But this approach do not work well with BBIM or IfcOpenShell’s high-level functions as far as I understand: if I move an object from BBIM UI its local placement is created anew instead of changing existing one. I couldn’t befriend aggregate.assign_object either. I realize that a good portion of these problems are due to my own inexperience, but it is what it is.
Because of all this, I was able to take advantage of the nested aggregations only through Python scripts:
That’s it for now. I haven’t touched any other sides of the topic (Representations, Materials, PSets, etc.) but I think they are already more developed than placements.
File attached to the post if anyone is interested.
@VDobranov Good work!
Is the workflow you used to model IfcElementAssemblyType the same as IfcElementAssembly?
How did you instantiate IfcElementAssemblyType? Did you use BimTool?
Please post a video showing how you did it.
Thanks
Thanks @walpa !
Unfortunately, there is no way to achieve it through the UI (at least, I didn’t come with any).
So everything is done through Python-scripting. Rather messy one, to be fair.
I’ve prepared small IFC-file through BBIM, which have usual template stuff and three types of physical objects (IfcPlateType for sheets, IfcBuildingElementPartType for insulation and IfcSlabType for concrete base).
Everything else is made through the algorithm:
1. Create physical instances of 5 IfcPlates (sheets);
2. Assign them representations;
3. Assign them IfcPlateType;
4. Assign them spatial container (IfcBuildingStorey);
5. Create local placement for them relative to the container;
6. Adjust their local placements to make box-like model out of them;
7. Repeat for 1 IfcBuildingElementPart (insulation);
8. Create IfcElementAssemblyType which will typify sub-assemblies;
9. Aggregate all 6 physical instances with just created IfcElementAssemblyType through custom "aggregate_assign_object" function (as dumb as possible);
10. Create instances of 2 IfcElementAssembly (sub-assemblies);
11. Assign them the IfcElementAssemblyType;
12. Assign them spatial container (IfcBuildingStorey);
13. Create local placement for them relative to the container;
14. Use recursive function "copyPartsFromType" which take all the instantiated objects that decompose the type (and relating objects in recursion), shallow copies them, assigns Relating Object to each copy through custom function mimicking the "assign_type", then aggregates them into corresponding sub-assembly, and finally makes the local placement of sub-assembly as the reference placement for each copy;
15. Adjust the local placements of the sub-assemblies;
16. Create IfcSlab (concrete base) and everything that comes after as with IfcPlates;
17. Then repeat the process for several main assemblies with assigning sub-assemblies and the slab to a main assembly type, instantiating it and RelDefiningByObject all its content through recursion.
18. Flush the model into a file.
As I said, messy. Hope it somehow helps…
@VDobranov This is really good. I was looking on working on
IfcRelDefinesByObjectjust about a week back. Will test this out now.The links for the python file and the ifc file doesn't work though
In fact, your posts in the chat room are exactly what prompted me to further try this)
Thanks for the flagging! I just realised that the repository was private, now public.
some contribution ;)
Thanks for sharing python file.