Grasshopper 2-Alpha available for testing

I have an improvement for Grasshopper 2!
I would like an option to turn it on or off the slider beacuse in some moments some sliders don’t change nothing in the definition and disturb.

My #1 wishlist item for GH2 is the option to change between item matching for trees (which GH1 does) and branch matching (meaning items in {9} are matched with items in {9} from another tree). This would help reduce data tree manipulations depending on the data structure.

1 Like

Hi Intuos,

If I understand you correctly, then I’ve hacked together a Grasshopper1 component to sort of do this. I’m currently using it in my own GH1 scripts, because I’ve wanted something similar.

It’s not full-blown, and does have some rough edges, but maybe it could be useful for you. Briefly, here’s what it does (without going into detail):

Suppose we have a tree, SourceTree, of trimmed surfaces.
Next we generate a second tree, GuideTree, which holds the edges of those trimmed surfaces.

Then, say, for every branch of GuideTree, we have an edge, and we want to find the surface it corresponds to it in the SourceTree.

So what we want is to make the SourceTree (of surfaces) to have the corresponding shape as the GuideTree (of edges). We end up with a new tree with the same shape as GuideTree (edges), but the branches hold surfaces instead.

Sorry if that was too messy of an explanation.

The following component is what I’m working on. It only does one-way correspondence (from SourceTree to GuideTree) and not the reverse. I suppose in math, you could say it’s a mapping from one-to-many. (But it’s not many-to-many.)

I don’t know if it’s “ready for prime time” because I haven’t tested all of the edge-cases (suppose SourceTree accidentally has some branches deleted, then what? Suppose the “correspondence” is not unique, then what?). And it probably could be much faster. But maybe worth a look.


MyCorrespTree Example.gh (62.9 KB)

Feel free to do whatever with the code. It’s mostly Grasshopper1 and Python.

If you find bugs and/or have suggestions, then let me know.

P.S. Techical Note: Under the hood, the script takes each path of GuideTree, and tries to find a path in SourceTree that is a prefix (or shares the longest prefix) of the path in GuideTree. So an example could have a source-path {3;5} correspond to a guide-path of {3;5;2;0}. In this case {3;5} would be the path in SourceTree that shares the longest prefix of the guide-path {3;5;2;0}.

In other words, try to match branches between trees, based on which branches share the longest prefix. It’s a bit messier than that, but that’s the overall idea.

P.P.S. It’s a bit abstract and technical, but it would be awesome if Grasshopper1 or Grasshopper2 had some kind of similar component as this. And it would be much faster.

P.P.P.S. If I’m “solving the wrong problem” then let me know. Is there a better way to do this type of correspondence, or maybe I shouldn’t need to find this correspondence in the first place?

Thanks for the response. What I am actually after is a little bit different though.
Say I have two trees like this:


Grasshopper would match the items in the list branch by branch, some like the red lines correspond in branch paths, but in dissimilar trees, you also end up with the blue matches that do not correspond.
So in the case I filter out some data, I have to do this for both trees, which adds a lot of overhead. I have to split trees and merge them back together. Instead if I could opt for a data matching like below, I wouldn’t need the overhead.

I was also thinking that it may be neat if component inputs could be rearranged manually. Curve closest point is one example in which I often end up with crossing wires:


If I keep aligning the wires in and out of components for readability, sometimes, having the inputs reversed would keep the script more legible (especially with full display full names enabled).

2 Likes

Hi Intuos,

We should move this to a separate thread if you are interested. But if all you want to do is to match-paths between two trees, then that is very do-able. We (you, or me, or McNeel) can make a Grasshopper component to do that.

Here’s the example, that you mentioned:

Here is a demo of how you can do that in Grasshopper1 with the help of the Component I wrote.

Here is the code for the demo (with components you can open up).
MyExample.gh (68.3 KB)

Pros:
We can totally do what you want with custom components.

Cons:
If you and I create the component, it might run slowly. But maybe we can get McNeel to create a fast version, once we fully specify what it is we want, and why it would be useful.

Please note: The demo is not fully general. However, it would be trivial to make it fully general. You can do that pretty easily, I think. And if you want, I can do that for you, but let’s move it to a separate thread in that case.

My overall point, is that matching-paths between trees, is something we can make a tool for. It’s mostly just matching between integer arrays/lists, which we can do with a combination of Grasshopper and Python (or C#).

I’ve wanted a similar tool too, so I made one. It is not the fastest, but it makes my Grasshopper scripts much more readable and easier to manage.

Another way we can do all this, is to allow Sets of Paths in Grasshopper. Right now, we can’t do this. However, maybe McNeel would add this to Grasshopper?

If we had Sets of Paths, then we could do the following. To match, we can simply intersect the set of paths from TreeA with the set of paths from TreeB.

{Matching Paths} = Set_Intersect({Paths of TreeA},{Paths of TreeB})

That would miss some of the prefix matching that I want, but it would do the path-matching that you want.

Once you have the set of matching paths, you can get the trees by using the “Tree Branch” component with it set to “Maintain” paths. Just apply that to both trees, and now you have two trees with branch-to-branch correspondence.

Hope that made sense.

1 Like

Hi Intuos,

Ooops! I think there is a much simpler way to do what you want. Have a look at this. You just have to ignore the error causing the component to be red (ie: can’t find paths).

Code for both examples here:
MyExample.gh (74.9 KB)

Probably this would be the best way to do it?
Just make a Cluster for this:


Example3.gh (14.2 KB)

I was thinking the same thing. I only use components with full names so they are readable to me, I can imagine that for people who use components with inputs/outputs described by only one letter in GH1, this would be a worse solution, but fortunately GH2 uses more than one letter as an abbreviation. The question is: To what extent will the readability of the components be degraded, and is this an acceptable price to pay in exchange for the undoubtedly improved readability of some GH definitions. In any case, the reorganization of the inputs would be optional by its nature, and I personally would be happy to untangle some of the definitions.
Once you properly connect components data flow readability > component readability.

For some, maybe even for most components, we will very rarely make a mistake in connecting to the appropriate inputs, or we will detect it very quickly. For example, if we connect Points to Curve inputs and vice versa, we will find out about it immediately.

I can also write that I prefer the ease of viewing the flow - because it helps more when things get really complicated, than the ease of connecting components always to the same place.

1 Like