Hi Jon, I would like to clarify whether it is a limitation of IFC and my misunderstanding of the structure of this type of document, or maybe the characteristics of components and how your plugin is built.
Let’s start with the fact that my intuition tells me to look at things as they are defined in Grasshopper for Rhino 8. Objects in Rhino can be modified via passthrough components in Grasshopper. I admit that I really like this system and it seems extremely intuitive to me.
In your ggIFC plugin we have many, many components, separate Decompose components and separate ones playing the role of “Compose”, there are many of them, but in addition their outputs and inputs do not match. Is it some issue related to the way the IFC format is constructed that we cannot pass all properties this way?
example IFC operations.gh (33.0 KB)
Rhino Model object workflow - passthrough components serving as Decompose and Compose. Different approach in ggIFC, varying list of outputs and inputs
Let’s say I want to modify some feature of an element in an IFC file and save the modified file being sure that I don’t lose any other data. Is it possible?
Modifying one property of an object while keeping other, unmodified properties - very readable, easy task
Decomposing outputs & Composing inputs - not possible?
Another, but similar task I was thinking about is splitting a giant IFC file into a series of smaller ones. The split file will still have the properties for the elements and I can run several IDS tests in parallel checking those properties. However, recomposing IFC files with a limited number of elements doesn’t look as easy as reversing a series of components to pack everything.
Split IFC File into multiple smaller files?
