OK,
Let’s quit joking.
I get why some components will graft the output, but the simplify option is there to prevent that when the grafting is not desired.
Then it should also work when the input tree has a single path, period.
I don’t care about the futile philosophical reasons ; I just see that it makes a complete mess of my definitions, and requires silly workarounds all over the place !
It’s not a philosophical objection at this point, it’s a cannot-break-existing-file-behaviour objection. Grasshopper 2 has a better simplify algorithm, but the best I can do in GH1 is give you a component which simplifies the way you want.
Yes pleaaaase !
Gimme gimme gimme a component after midnight 
Won’t someone help me chase the grafting away ?
One question, if a tree contains a single path, what should happen in the following cases:
Basically, the rule in GH2 I came up with is “remove all zeroes, but if you end up with an empty path, add one zero back in”. Is that satisfactory?
This works for me, as it just cancels the graft when I don’t want it AND also works for a single path :
I would go for something siple like that, and let the user do his own custom path mapping in freaky cases like the ones you mention.
I’d prefer to keep the behaviour the same as it would be in GH2 then.
Ugh… My magic bullet doesn’t work because the graft component adds a root instead of a branch.
Pulling my hair out at this point…
You’ll have to wait until the next Rhino6 release. Usually Tuesdays if you are on the Service Release Candidate schedule.
OK, great ! For the name, I vote for “Sensical Simplify”… oh, wait…
In the mean time, I figured that I can use this for components like Graft :
Genius
Oh, I finally know why it is called this name.In our Chinese, David is really 皮(PI=playful).
