What is the difference between “Trim tree” and “Shift Paths” ?
I can’t seem to find a tree that would be transformed differently by one vs the other…
By the way, thanks to whoever brought us the “Shift Paths safely” component !
What is the difference between “Trim tree” and “Shift Paths” ?
I can’t seem to find a tree that would be transformed differently by one vs the other…
By the way, thanks to whoever brought us the “Shift Paths safely” component !
Hey, at this time : 52 views.
I guess that’s 52 fellows who thought there would be an answer to this question here, because they also are befuddled by this “Trim” and “Shift” business, but are affraid to ask.
Yes, they seems to be very similar…
Anyway:
Positive shift do the opposite, like “trimming a tree from the ground up to a certain height, and then planting all the remaining branches where the tree was”.
Trim tree can’t use negative integers…
… what is that?
“Shift Path” by a negative value is like “Trim Tree” with a positive value.
No wonder people get confused by these tree management tools.
It’s like the “Tree Branch” which is like the dumb cousin of “Split tree”, except you need to put curly brackets in one case and not the other.
It can also be compared with “Replace Path” who is the idiot brother of “Path mapper”, as I argue here.
I’d much rather have less tools, but which can be used either with masks, either with hard values, but with a consistent syntax (and positive / negative value logic for that matter).
Something similar was recently discussed here: Are Ruled and edge surfaces necessary? … about midpoint, that example is good.
I think many components were added over time.
Currently Grasshopper 2 is under development and a lot of things will be different.
I’m quite sure all this matters were already noted and will be take into account during development.
If for some reason in your definition, your tree has unsufficient branching level for the Shift Path component, it doesn’t screw-up everything downstream by outputting nothing like ShiftPath does :
It’s similar to the “Suirify” component that doesn’t screw-up the tree structure in some instances where the “Simplify” option does :
By the way, thanks to whoever brought us the “Shift Paths safely” component !
Where do we find this Shift Paths safely component?
Where do we find this Shift Paths safely component?
Found it ! Treesloth | Food4Rhino
It’s part of the Treesloth components.
is there any workaround?
sth with dynamic “depth” of shifting the path?
I am not in thw knowing of a tool like this
Anyway, thanks for the link osuire!
This is INSANELY annoying! This is a flaw that should be fixed, and I don’t care who’s code the fix might break. It’s a mistake to work as it does. I just created a “Smart PShift” cluster to handle this. pShift works for me, though perhaps could be done better? It is demonstrated in the following code, internal to another cluster crvXYZ that sorts curves by X, Y or Z of their midpoints. [PShift_smart_2020Apr28a2] [PShift_smart_2020Apr28a] PShift_smart_2020Apr28a.gh (42.2 KB)
if you never “simplify” or “suirify” you’ll never run into this problem with shift paths. in my opinion simplify is always a mistake: you’re throwing away useful information and introducing variability into your path structure (runtime changes can change the “depth” of the path structure if you simplify or use the path mapper). Those extra "0"s are important — they mean something! if they bother you, get rid of them with a relative operation like a shift paths upstream.
See my rant about this in the final section of this video: The deal with Data Trees - YouTube
just in case anyone needs this.
Its super messy, maybe there is some improofment to be done?
I needed this a lot of times since i can not know if some parts i want to offset have sub-parts.
if you never “simplify” or “suirify” you’ll never run into this problem
Yeah, but for one, you end up with lunatic paths full of zeros, and also, If you don’t do ANY kind of rationalizing on these freaks, you end up with a bad data structure when you merge them later on with other trees that haven’t been uselessly bloated.
Those extra "0"s are important — they mean something!
Most of the time, they don’t. That’s the problem.
Moreover, when there are meaningless branching levels, it makes the “meaning” as you say more difficult to track and interpret.
I mostly know and want to control the level of branching everywhere in my definition, and the “natural” behavior of Grasshopper keeps making this difficult for me, thus my request for a “Suirify” component.
I wish there was some kind of global toggle to prevent components from adding leading or trailing zeros to tree structures when not invited to.
Wouldn’t that satisfy everyone ?
Wouldn’t that satisfy everyone ?
No. The zeroes are added when the order of the output is greater than the order of the inputs. This is a necessary feature. Every branch level/“zero” represents a place in the provenance of the tree where a component could produce multiple results for each input, even if it didn’t. Eliminating any level is only safe if you know for sure that a component will never conceivably produce multiple outputs for each input (or you don’t care about preserving the distinction) - which may well occur, but can’t be ascertained automatically.
This is a necessary feature. Every branch level/“zero” represents a place in the provenance of the tree where a component could produce multiple results for each input, even if it didn’t.
I perfectly understand your point, Andrew. This discussion is about which is the worst of two evils :
-Systematic branching no matter what the present structure might be and therefore having to constantly tame down the branching frenzy.
-Thinking you know what your inputs will be, not branching, and having trouble later if your inputs are not what they are supposed to.
I prefer the second evil, because I’m a stickler for simplicity and readability, and I claim I KNOW what’s supposed to be in my lists, but I can imagine that for people like you who are capable of higher abstraction and want their definitions to be super-flexible, the first one is the lesser.
So just as there is a global option to display text or icons in components (I’m all for icons) , I wish there was a toggle for this auto-branching behavior.
if you never “simplify” or “suirify” you’ll never run into this problem with shift paths. in my opinion simplify is always a mistake: you’re throwing away useful information and introducing variability into your path structure (runtime changes can change the “depth” of the path structure if you simplify or use the path mapper). Those extra "0"s are important — they mean something! if they bother you, get rid of them with a relative operation like a shift paths upstream.
Amen!
I’m a stickler for simplicity and readability, and I claim I KNOW what’s supposed to be in my lists, but I can imagine that for people like you who are capable of higher abstraction and want their definitions to be super-flexible, the first one is the lesser.
This^
I too manage here and then to use very complex trees, but most of the time 1 or 2 level are plenty, for me.
I have “even” points elaborated in a way ending {0;n} and “odd” point elaborated in another way ending {0;n;0;0} … to merge even and odd again, simplify and bam, i’m finished.
Situations like this are like 99% of my works, and then they never ever fail.
Adding this comment just to relieve some hate towards simplify function: it’s a nice friend.
{0;n;0;0} … to merge even and odd again, simplify and bam, i’m finished.
Situations like this are like 99% of my works, and then they never ever fail.Adding this comment just to relieve some hate towards simplify function: it’s a nice friend.
Simplify is a false friend, because if you have a single branch like {0;0}, it will not simplify it to {0}.
This is why I asked for “Suirify” which is just that : a simplify that will not screw up your expected tree structure in the event a tree has one branch.