This is creating confusion in my head. Seems like that the former SolidModel is now ModelMesh and now the SolidModel is complaining about missing options as input which I could not find so far.
Plus: I realized that the Material Style seems to be lost when I use the new component in contrast to the old one in the contaxt of modifying components. Is this intended behaviour?
Edit: Or maybe it is because I have at the same time also another version where I created a new IfcProduct from it as it seems like the modified export is somehow overwritten by that other component. Seems like I am also loosing my properties.
Edit 2: Yes this seems to be it. I disabled it and was rerunning the solver and it seems to be ok now.
Here’s an example where the options component is used to convert geometry.
I need to improve the arrangement/location of the options component and geometry conversion components.
Styling is better achieved using IfcStyledItem, very few implementations recognize styling by material. But I’m not sure I understand the issue you describe. Posting a gh script with instructions would be helpful.
In the meantime, regarding the styling. I’ll try to explain with screenshots and if needed I can clean the file (still warming up and testing) and provide it later but I think I already kind of figured it out.
So basically I am trying to get more familiar with the bake options. And therefore in Test 1 modified an existing object.
… also a re-export of Test 1 has now the charactersitics of the new element (or better, it’s lacking those from the original element). I think now as I try to explain it seems to be logic as as far as I have understood the bake is always taking all global gg components into consideration. So it seems like the ggIFC Modify object is overwritten by the newly created object.
If I disable the above highlighted parts and run the solver again the Test 1 output is the same again. Well maybe you could give me some insights about the different bake components to better understand what’s working and what’s not.
Thanks for the further info, it seems helpful for me to try and respond. Here’s some insights into modifying IFC objects.
A typical Grasshopper object is isolated and stands alone, and relatively primitive. Think of a number, text, mesh, brep, point etc.
As the object is passed around from component to component, it’s immutable (or can’t be changed). If an object needs to be modified, it’s duplicated and the copy is modified or edited.
IFC objects use common references, and objects have bi-directional relationships. If you modify an object, it’s editing the original, not a duplicate/copy. This also means that recalculating a script that the changes are not always reverted (which would be a significant challenge for me to support properly).
The primary intention of the gg IFC plugin is to generate models using a graphical programming approach. But as you see, users have found it useful to edit/manipulate existing objects.
But if you are editing the script, or expecting unchanged and unchanged elements, you need to recompute the whole script (including file reading) and ensure only desired components are active.
Thanks for confirmation and clarification. It’s pretty smart but as you explain different than the workflow of most Grasshopper workflows I am used too.
However I still have not really figured out what’s the difference between IFC Read and IFC Import or what’s the IFC Bake / Stream / Stream Bake and what may be the different use cases.
Read imports directly from a file path, where as IFC import can parse from a text object in Grasshopper (ie text panel or other text outputs).
Bake will write to file (typical way to save the output) by manual excecution.
Stream Bake will also write to file, but takes a file path as an input. Every time you change the script IFC components (or their upstream inputs) the file will be written if this is enabled. Stream is more for use in the context of capturing the IFC dataset for a different use other than saving to disk. This can be used on services such as shape diver.
Feedback like this is useful, as I can improve the component description where it is inadequate (the context help when you hover over the component).
Thank you that helps. In a context I often get how it’s supposed to work together but sometimes I simply can’t figure out what the context actually is. E.g. what are “Delegate Functions”?
Also the description is not super meaningful in such cases
At the moment I am just curious what’s possible and it seems like I constantly discover new things as there are already a lot of components. It is really nice work you have done here but due to the way everything evolved over time (especially the documentation and samples) it is a bit hard for me to follow each components puropose. So yeah, if you don’t mind I will try to continue giving such feedback
