Up a tree without a paddle... :-)

Hi all,

GH 101 here, working on a little simulation of a slicing process (showing what happens in an RP machine). The basic definition is working fine (it's _very_ simple) but I don't know how to (correctly) end up joining the surfaces that make up each slice (top and bottom planar srfs, extruded sides). Problem is, in my definition, the extrusions end up at tree level {0,0,n} whereas the top and bottom surfaces are at {0,0,0,n}...

I've tried various combinations of merges, as well as some of the other possibilities of tree manipulation, but I haven't found the right one that allows me to bring the top and bottom surfaces down to the same branch level as the sides so I can join them branch by branch.

I can just flatten the whole thing and let Join figure out which surfaces to join. In this case the results are unambiguous, but I can imagine that there will be cases where one will have a tree like this and not want to flatten it down to join, because the wrong things might get joined at that point... Is there any way that the tree structure can be kept and just the correct branches get joined?

As always, thanks for any and all enlightenment... --Mitch

Attachments:

TPyramid-Hole.3dm, 146 KB
RPSlice1.ghx, 192 KB

Replies to This Discussion

Permalink Reply by to] on February 22, 2010 at 8:01am

hi mitch
you can use the pathmapper or a additional graft component
but i prefer the pathmapper ( source {A;B;C} target {0;A;B;C;}

Permalink Reply by Mitch Heynick on February 22, 2010 at 9:04am

Ah, great - I looked at that tool, didn't remember what it was for or how to use it...
Actually in my case it's source {A;B;C} target {A;B;C;0}, but that's exactly what I needed!
Thanks much, --Mitch

Permalink Reply by taz on February 22, 2010 at 3:38pm

Hey Mitch,

Everyone else is correct, but here's some more general information regarding overlapping zero addresses (overlap meaning the zero levels are shared by all branches).

If you want to remove leading zeros use [Simplify Tree]:
{0;0;C;D} -> {C;D}

If you want to remove trailing zeros use [Path Mapper]:
{A;B;0;0} -> {A;B}

Permalink Reply by David Rutten on February 23, 2010 at 2:52am

Ahem,

all the symbols on the left hand side will end up as variables, so using "0" is a bad idea. This would be better:

{A;B;C;D} -> {C;D}

and

{A;B;C;D} -> {A;B}

Note that there is a constant "e" in the expression language which will get overwritten with a path index integer whenever you use "E" on the left hand side. However, if you don't need the natural-logarithm-constant on the right hand side of the mapper (and let's face it, changes are pretty slim) there's no problem though.

--
David Rutten
david@mcneel.com
Poprad, Slovakia

Permalink Reply by Mitch Heynick on February 23, 2010 at 11:44am

OK, thanks David...

Now, I know how to get down from my tree, but the other question is how did I get up there in the first place? Specifically, while the sides (extrusions of the slice curves) are at level {0;0;n}, why do the bottoms (planar surfs made from the exact same slice curves) end up getting an extra branch level {0;0;n;0} ? That part is still kinda unclear... --Mitch

Permalink Reply by taz on February 23, 2010 at 12:20pm

Sigh...

I'll just stop writing and speak only with screengrabs.

I was trying to describe the before and after path names, not the actual source and target syntax for the path mapper.

I wish I could edit posts. It's also kind of strange that deleting a post doesn't delete any the subsequent replies.

Welcome back by the way...

Permalink Reply by Sameer Kumar on February 22, 2010 at 8:46am