Just when I think I understand grasshopper trees, I run into something like this …
I thought the attached diagram would produce output that is exactly the same as its input, but, as you can see, it doesn’t. How can I fix it so that it does? (What I really want to do is to insert some transformation between the Points output of “Control Points” and the Points input of “Nurbs Curve PWK”, but for now I’m stuck on the basics.)
It would have been useful to have your test geometry…
The above makes sense. Control Points is going to break down the list of line-like curves into sets of points, weights and knots. To know which points, weights and knots belong to which lines, the component will have to add an extra depth of branch hierarchy {…;n+1}. This extra depth of branch hierarchy is not magically removed by the Nurbs Curve PWK component. You will have to do this manually with a Trim Tree component. The numbers of item in the input and output lists match, do they not?
That works perfectly, thank you. And yes, the lengths of the lists match.
Incidentally, would you know of something I can read/watch that explains grasshopper trees properly, so that I can answer questions like this myself?
Often cited is Andrew Heumann’s The Deal with Data Trees (although I feel it paints an incomplete picture) Here, much the same, except in text form: Rhino - The Why and How of Data Trees
Many thanks! That clears things up a lot.
I understand why Control Points has to add the extra path element. But, at least for my purposes, I wish that Nurbs Curve PWK would remove it. Still, no big deal: I achieve the same effect by hooking its output up to Trim Tree, per your advice.
Here’s what I now find weird: when I right-click on the Curve output of Nurbs Curve PWK, it offers shorthands for various kinds of post-processing, but TrimTree is not one of them, yet it seems that it’s the one that would most often be wanted.
It may be that for your purposes you wish it were that way, but as a generalization it doesn’t make sense. Grasshopper components never trim data trees, only graft them… except for the two components explicitly made for that purpose: Trim Tree and Shift Paths. Shift Paths is the granddaddy of Trim Tree. It does what Trim Tree does, but can also “trim” branch hierarchy from the front of the branch label. It does this with positive depth values, so using negative ones, makes it behave like Trim Tree.
Well, you’d also have to be able to set trim depth. How do you imagine that being implemented? Or just a Trim for output with a depth of one, and for other depths you’d need to use the actual Trim Tree component? Yeah. That makes sense.
Apparently this topic and this suggestion (having a TRIM ONE incorporated alongside the other standard options like Flatten, Graft, etc.) has been brought up at least a couple of times over the years, but for some reason it has never been implemented
