Hello,
Anybody know how to dynamically change the profile selection of this component without having to manually click on the component and select it yourself? I have a list of tuples right now which pair a steel member size with an unique element name. My goal is to use this list to set the ggRvtCatalogueProfileDef component to the steel member size that pairs with my unique element name automatically without having to set it yourself.
Any ideas?
Hi Johnny,
Thanks for posting. You don’t have to use the catalog profile, there is a generic profile component that can take the string name of the profile. See if the attached script helps.
220318 revit profile.gh (5.8 KB)
Cheers,
Jon
Hello Jon,
Yes that worked! Thank you for that. In my pursuit of automatically generating ggRvtFramingType’s, I came across this next issue.
I defined a Revit material type above but for whatever reason when trying to use the ggRvtFramingType component in my GHPython script I am getting this error message. I cannot seem to pinpoint the error in my code.
It seems to all work out just fine when using the components outside of Python.
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
ps, the other complexity in the gg plugins is that many components have overloaded inputs.
We use a bunch of wrappers (ie GH_GeometricGoo ) in grasshopper to handle preview etc.
I tried recreating your python script, and it seems this is in part the cause of the runtime error you’re seeing.
As I understand it, for GH 2.0 wrappers won’t be used, so this would then make things a lot simpler.
I’ll have to look at the component and see if I can refactor a version without an overload. This is where legacy can get difficult (ie keeping legacy behaviour or user expectations).
Also, I tested and it seems Node in Code does expire the component as I need, so my concerns above can be ignored.
I’ll come back to you soon about making the framing type work.
There is a bunch of other things I’d like to do to make this cleaner (ie put components on better namespaces etc) but I wonder if I just wait for gh 2.0 for that.
Cheers,
Jon
Hi Johnny,
I took a look at this. If you can update the plugin from package manager, framing type will work.
There is some overhaul needed to make this work for all components, so if you can let me know what you plan to use, I can prioritize this (or I will improve the plugin on demand).
Thanks for the insight, it is a pretty powerful way to use the plugin and it will certainly inform changes when working on improvements/components going forward.
220322 python node in code.gh (4.5 KB)
Cheers,
Jon
Hey Jon,
Thank you very much for the help and detailed explanation! After updating the plug-in, I did in fact get it to work. With that being said, I am going to proceed with my original idea of automating this process.
To be quite honest, I have to admit I got a bit lost while reading your explanation. So if you are still open to it, I would be more than happy to schedule an online meeting with you to discuss it. I always like to know how the software works and behaves behind the scenes as it is a great interest of mine. Let me know if your still interested!
Thank you,
Johnny
Sure, sounds good. Send me an email with candidate times, probably best will be your late afternoon and my morning.
