What’s my issue?
Seems there is some internalized data on the bake component. Is this from a sample script?
You could delete the bake component and create a new one if you can’t clear the input.
Posting a script containing this component (or an exported copy) might be helpful to me.
Yes, it’s one of the sample scripts but can’t say anymore which one. Probably it was due some file writing restrictions? As written in the other thread I am still trying to figure out how the bake stream is supposed to work.
Moreover I was facing another issue. If I select too many gg components while the solver is not disabled Rhino is crashing. Nothing too uncommon but I realized that when I tried to reopen the .gh file nothing was working anymore and I realized that the original IFC file which is (utilized with the read IFC component) was corrupted. This happened a few times so I am curious how the file access is achieved that the ifc is damaged on a file crash? Or is it me using the read component in a wrong way?
Plus: An .ifc file can’t be internalized or have I missed something?
A read interaction of the IFC file should never change it’s contents. Something else is interacting with it by the sound of it.
If you can share a script (and any referenced IFC files) that replicates a crash, I will check if I can resolve it.
There is a component to read IFC data from a text object in Grasshopper, but often an IFC file is a significant size. I’m not sure there are many circumstances where this would be a better choice than reading from file.
Ok, will try to reproduce and provide some files!
Regarding performance - I have just used some simple files but what’s the best approach if files are heavier? Read IFC/Import IFC/ use data dams … (I guess dams won’t work well as if I understood correctly for each query the file is accessed directly.
If you’re really worried about performance, then I would use Grasshopper as an approach to learn the techniques, and then code it in IronPython (or c#). Our library multithreads the parsing of the file, and then using LINQ, performance should be pretty acceptable even on larger files (If you’re talking over 500MB, then it can take some time. Really any IFC data set should never be that large, particularly when using IFC4.
Currently for the sake of researching, testing and demonstrating I think performance is fine. However your valuable input is also something I have already thought of. I know that it’s possible to access the geometry gym’s .dlls also via an (Iron)Python or C# scripting component but I have not looked into it so far.
Indeed I have gained some experience a few yeats back in writing new components for Grasshopper in C# but tbh I don’t know much about LINQ and how it would work with your library. If you know of some good getting started guides or if you have appropriate material to point me in the right direction I would highly appreciate it!