Hi Johny,
Thanks for the interesting post. I must admit, I never actually tested Node in Code before, and with respect to the Geometry Gym plugin, it’s a bit of a double edged sword.
A typical Grasshopper component treats it’s inputs as immutable. Ie an input might be a mesh, but the component duplicates a copy of the mesh, leaves the original untouched. It then alters the copy and emits the copy as an output. If the component expires, the duplicate automatically.
With the IFC (or ggRVT components that generate IFC objects in the background), it’s not so simple. A material is declared, and it’s then a down stream input to other types or instances. It’s not treated as immutable so if it is modified the original is changed.
But also there are a number of relationships established in the background of the component. Ie a beam is “contained” in a host building (or building storey). When the beam expires, the relationships also need to be adjusted. I am reconsidering whether the components should be top down (ie Site - Building - Storey - Elements) or wired in a more traditional sense (ie Elements - Storey - Building - Site) when the plugin gets developed for gh 2.0.
I doubt (let me know if I’m wrong) that node in code calls an expiry on the component when it recalculates? If it does, then all good. But if not, then if you generate 10 beams, and then expire and generate another 10, then the model will still think there is 20. Basically you need to close and open the script to reset everything.
Do you have a simple test script you can share so I can test this?
There is a nice abstraction in the gh rvt nodes (only partially evident in the public constructors etc), so if node in code can work, it would be a nice feature.
If the above isn’t clear, let me know. We can arrange an online meeting to discuss.
Cheers,
Jon