Polyline component

Replies to This Discussion

Permalink Reply by taz on February 28, 2010 at 11:58am

Hey Mitch,

1) The list order of the points determines how the polyline is drawn. The example below is (of course) not dynamic which means you would need to develop a routine to sort your point lists if they aren't already generated in a ordered fashion. Using [Merge] is a visual way to keep track of the attachment order.

2) What you're saying is a straight forward way to do it. If you'd like you could recreate your points with an expression or a scripted component but I don' know that it would save you any trouble.

Permalink Reply by M Lan on September 13, 2017 at 3:40pm

Thanks for the clarification.

I'm trying to do something similar, but instead of inputting individual points I'd like to input sets of points into the Polyline and have corresponding points in the sets joined.

Specifically, I have a set of points as an output of a HexGrid (say, 4 points for a 2 x 2 grid), which I then move (4 new points) and then rotate (4 new points) and then rotate again (4 new points). I use the outputs of the move and rotate as input vertices in the PolyLine (12 points). What I would like is for the first point from the move to join to the first point of the first rotate and the first point of the second rotate, etc (4 poly lines of 3 points each); instead the 12 points are joined across each other in an order I can't define.

I was following this tutorial (https://www.youtube.com/watch?v=8TFrz2eWyB0) and found my program working differently than the demo at ~18 min in.

Thanks for the help! I'd be happy to provide more context if the above is unclear.

Permalink Reply by Joseph Oster on September 13, 2017 at 4:17pm

Read this first! How to get help on this forum.

Don't expect anyone to watch a video or recreate your code from scratch.

Permalink Reply by M Lan on September 13, 2017 at 5:46pm

Thank you - feedback appreciated.

Permalink Reply by Damien Alomar on February 28, 2010 at 12:04pm

1) not sure exactly what you mean by "upstream" components, but I'll try to explain. the polyline component will connect all of the points in each branch of the tree in a separate polyline. So if you connect multiple lists into the component with different branch/tree structures, then you'll likely get the same result as if you connected each one individually. If you connect multiple lists and they have a similar structure, then since the points all share the same path, the polyline will connect all of them, even though they are from "separate" lists. The ORDER in which their connected will react to the order in which the lists were added though, so that's something to be aware of.

2) nope, that's about the easiest. Compared to scripting, there's a lot of "shorthand" kind of things that you're probably used to that require additional components to take care of. Since we don't have access to the data in the same way as in code, that's kinda just how it is.

Permalink Reply by taz on February 28, 2010 at 12:15pm

I beat you by a minute. At least the answers are the same (less any tree talk)...

Permalink Reply by Damien Alomar on February 28, 2010 at 1:16pm

I like the merge idea... in looking this over I was some what "annoyed" that the order can't be determined very well when connecting multiple things to a single node. That's probably why I tend to not do it very often. That brings up the whole "is this extra component worth it" debate.

Permalink Reply by taz on February 28, 2010 at 2:12pm

[Merge] works best with trees when there's boundary conditions that need to be maintained or operated on separately. With points for example:

{Start Pt} --> [ ]
{Interior Pts} --> [Merge] --> {All Pts}
{End Pt} --> [ ]

I find [Merge] is useful when putting definitions together, but if one goes back to "tighten up" a finished definition it can easily be removed. So maybe it's not an "extra" component but a "for clarity" component.

The same could be said for all the scalar comps since there isn't any combination of scalar operations that can't easily by wrapped up into an expression... But it's nice to see them sometimes for working things out.

Permalink Reply by Mitch Heynick on March 1, 2010 at 1:39am

Thanks guys! Taz, the use of the merge component to control the order in which the polyline is built is excellent, thanks. Damien, "upstream" just is my way of referring to stuff which is happening before the data stream gets to a particular component... I like the flow analogy. --Mitch

Permalink Reply by David Rutten on March 1, 2010 at 1:47am

Then you'll be (probably somewhat secretly) happy to know that I initially used the words "upstream" and "downstream" as well, but people for confused so now it's "input" and "output".

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