Hi, I’m trying to make a script where Grasshopper will populate an ArchiCAD Zone with ArchiCAD Objects based on data in a spreadsheet. Unfortunately there are hundreds of potential objects that could be required, so I’ll need to access all of these within the script.
As the ArchiCAD plugin doesn’t let me pick Objects dynamically, I’m struggling to find a way to deal with large numbers of options efficiently - I can’t see a way round scripts that look a bit like the attached. Does anyone have any great ideas of how this could be made more manageable and streamlined?
TBH this was worked up by a colleague, so I didn’t even want to try to unpick it! But I’m facing the same challenge so wanted to check before I got started.
I guess the screengrab is a distraction to the main question, which is how to deal with large numbers of options, where each option has to be an individual node in Grasshopper. Are there any recognised techniques (or even script layout tips!) for this kind of thing?
A Random component that generates integers (0 to 300 domain) to be used as seeds for other Random components, each with a domain appropriate for part of the task. So a single ‘Seed’ slider (0 to 300) on the first Random component generates seeds for the other Random components.
Can you provide a minimal example mocking the interface to ArchiCad and Excel? I still don’t understand the problem, especially why picking specific branches or items should not work in this case.
No pattern, as the data will be different for every project. I’m thinking the best approach will be to combine all the referenced options into a single list as soon as possible, then use searching to find stuff in it - should make the script much more manageable.
The problem is the shear scale of the options. Picking specific examples will work fine - I just need to manage preset nodes of potentially over a thousand different options, and I don’t want to have to spend my life connecting nodes!
You still haven’t posted any example data so I’m out of this thread.
One thing I’ll add in parting - it’s often a mistake to connect a bunch of wires to a single input instead of using Merge to make their sequence explicit.
Why would that be better than having lists of “Library Parts”, “Angles”, “Layers”, etc.?
Thanks anyway. Annoyingly the ArchiCAD plugin doesn’t allow you to select the object dynamically, which basically means I need to access a preset of each potential option, of which there are over a thousand.
So no example data as I haven’t set it up yet - trying to figure out the best approach before I spend hours connecting wires all over the place.
Essentially a large part of the challenge is driven by the (current) limits of the plugin, as there’s no other decent way to work with multiple object types.
what I think is worth saying explain -and I guess what also other users have tried to do in this thread- is that to the eyes of whoever does not use that specific plugin, it looks like you are dealing with a data structure of some sort (I say this because of the Explode Tree + Entwine in your first screenshot)
but there is no reference at what sort of data is being contained in that tree, how it’s organized, if it has any additional property that could be read and handled… and in general all those kind of info that you can’t extract from just a screenshot
if your question just is in regards to that plugin, and are looking for other people who use it and can advice you on that, then fine for me and hope you get your answers
but if you want to try to deal with that data tree, then even just posting a single branch could make people look at it and offer other maybe unexplored possibilities that might transcend the use of specific components from that plugin
as for everything I have written, mine is just a wild guess based on screenshots but -in general- posting an even small and seemingly unsignificant portion of data never harms
in the worst case you are still at the very same point, in the best case you actually get some sort of solutions or new ideas
This may not be helpful,. but with that number of options, we might move to optioneering. Create an efficient way to produce all options. Say using a CSV or text file and feeding that into the definition.
Then use Design Explorer to quickly explore the solution space and important factors after they are all produced in batch: Design Explorer | Thornton Tomasetti
If the plugin does not allow to select more than 1 object, then you could try to reference the .gha as a .dll in a script and try to see if there is a method to be called by code. You might also inform the developer and ask to enhance the component to support selecting multiple objects at once. With intermediate skills you could decompile it and try to implement the feature for yourself. It is also a good approach to parameterize a definition by code if you have a lot of parameters, or as mentioned using a file for that. But without coding you might be forced to create this manually. At least you can also script the placement of components as alternative, if the other approaches are too difficult to code!
suppose all the options are in a list
you can create another list with the (unique) names of the options (this might as well be numbers)
and use a search function to select the option by its name (or if you’re using indices, just use a list item)
furthermore, you can create a script to generate a list of option names to select (or list of indices that you can pass to the list item component)
but -in general- posting an even small and seemingly unsignificant portion of data never harms 