Example problem:
I’m designing a skyscraper and have a simple list of numbers (e.g. finish floor heights) that I want to save to speckle from grasshopper.
With v2 connectors
Plug number list + URL string into “send” node, and click send
Plug URL string into “receive” node and click receive
With v3 connectors
“publish” and “load” component only send/receive speckle collections
“collection” component does not accept lists of numbers. I need to codify them into geometry (e.g. z-heights)
“create collection” component requires a “sub-collection” even if there is only one
“publish” component does not accept a URL string, it requires “speckle model” first (why the extra step?).
So sending/receiving a simple list of number used to be a 1 step process and now is a 6 step process and takes up lots of space in the canvas.
Hi @Alex_Fernandez_Grand , you’re correct in that it will take more components in v3 than in v2 for some GH ↔ GH workflows - this is because we’ve made compromises in order to produce models from GH that work well with any other application, and for other workflows (eg, for dashboarding in PowerBI or our Intelligence platform).
In v3, all authoring apps produce models with this general structure:
In the example you gave in v2, your list of numbers were dynamically attached to a generic base object, and while v2 GH specifically can parse these easily on receive, no other application would be able to consume this data. We’ve taken a more opinionated approach in v3, which makes other GH workflows much more efficient, at the cost of a bit more friction for GH ↔ GH.
It’s an extra 2 nodes on publish and receive, extra 4 total.
I’m happy to follow up with a v3 GH demo to you / your team and explain in more depth the decisions we took, the extra perks from v3 that were not possible in v2, and to see if we can help you migrate your legacy scripts!
In the meantime, I’ve published a set of v3 docs for grasshopper here: Models - Speckle Docs