Multiple String Support Added to PolyLine

[f11]

Your 2022.02.1 update included an enhancement I could use, "- Add multiple string support to PolyLine". I want to make a 120-pixel multi-layer mega-star using 3 strings of WS2811 bullet pixels: 50, 50, and 20 each tied to a separate output of an ESP-32 (trying to keep update rates as high as possible by distributing across multiple outputs).

(Actually, I wanted to build my star using the "Star" canned model, but couldn't figure out how to do it with the string lengths I have.)

Anyway, your enhancement showed up, I loaded it, and behold! the Polyline model now has an attribute allowing me to define how many strings are in the polyline model, and below that attribute is another allowing me to define "Start Nodes" for each string (called "PolyNodes").

I realize this update was JUST released and you probably haven't had time to document it yet anywhere. But am I interpreting the PolyNode start nodes right?

ie I have a three-layer 120-pixel star 50-40-30 (outer to inner) made out of the three strings mentioned above. So I just create the polyline model (PolyNode1) as usual adding line segments to follow my star outline, but after pixel 50, I hit escape to end the first string, then start another polyline at pixel 51 and continue to pixel 100, then start another polyline (PolyNode3) at pixel 101 and continue to pixel  120. Then go into the "Indiv Start Nodes" section and enter PolyNode1=50, PolyNode2=50,  PolyNode=20?

Or do I just draw a single polyline model for all 120 pixels, THEN define the PolyNodes as PN1=50, PN2=50, PN3=20?

Gotta say, your timing with this enhancement is extraordinary for me, I spent most of yesterday trying to figure out how to do this without cutting up my strings to work with the canned Star model !! Thanks for any help!

[allknowing2012]

Normally in your situation we would suggest you create with 1 string, right click export as a custom model. Then import that custom model, make it 3 strings, set to individual nodes - set accordingly. Now right click on the model and replace your star model with "this model". It loses a bit of builtin star functionallity but doing at a polyline seems to be even a weirder option.

[Gilrock]

Yeah we don?t document anything. There are some users that do. Don?t end the Polyline you need to draw the whole thing as one model then the start nodes define where the string splits happen.

[f11]

allknowing2012 - yeah, I know its a weird way to make a star, but if I can build it without chopping up my strings any more than they already are, then I thought I'd explore it. I saw someone else do a multi-layer star using polylines, then he created submodels (I think, going by faulty memory here) of the layers going around the periphery from outer to inner, then another set of submodels of the star "points" (all the pixels in each of the five points). At that point he could light up or run a pattern against one or more star points, or against individual layers. Anyway, it looked like an option to the wire cutters until I realized polyline wasn't really set up for multiple strings/outputs. I'll look into your alternate approach this afternoon - this is what I love (and hate) about xLights ... there are always a dozen ways to do almost anything.

Gilrock - Ah, so the PolyNode entries aren't string lengths, but the id of first pixel/node in each string (ie. 1, 51, 101) and then the total number of pixels in the model allows xLights to work out the math.

Just out of curiosity, was there a way to use the canned Star model (that is, 3 Stars of decreasing size and node counts aligned as layers, then grouped) using strings with  atypical starting points? That's where I started down this rabbit hole.

While I think of it, how come polyline treats a single node at the top tip of a star point (the inflection point) as two nodes, and same with other "shared" nodes as I move around the star? Or am I doing it wrong?

[Gilrock]

We eventually would like to make it so all models can support multiple strings with variable start nodes.  Not. Sure about the last question could be a bug so we?d need to have your layout.  Package log files and give us the zip.

[f11]

Gilrock, never worked with the xLights log files before - to show you what I'm talking about regarding polyline, what do I need to do to ensure the right info is in the log file(s) I give you? when you say "give us the zip" do you mean upload it as an attachment to a post in this thread, or submit it to a support email/webpage?

[f11]

Here's what I'm talking about in a quick screen capture of a fresh layout of models. I created a 50 node std Star with 5 points.

I then used Polyline to trace over the Star, starting at the top tip node and going CW around until I reached node 50, 1 node to the left of the top tip.

To start tracing, I put the cursor on the top tip Star node 1, clicked and held the button and moved until the cursor was over Star node 6 down and to the right, then released the button on top of Star node 6. Without moving the cursor,  I clicked and held the button over Star node 6 and moved until the cursor was over Star node 11 to the right horizontally and released the button. Without moving the cursor, I clicked and held the button over Star node 11 then moved down and to the left to Star node 16 and released the button.  And so on CW around the perimeter of the Star, releasing the button on Star nodes in the same way.

The attached image shows the original Star model with large yellow nodes on the left, with the Polyline model overlaid with smaller white nodes generally in between the Star nodes. I copied the Polyline model and moved he copy to the right of the Star model for comparison, showing how the Polyline model has two offset nodes for each star point and the rest of the nodes don't extend to the ends of the drawn segments (ie node to node).

I get that the shared nodes at tips and inner inflection points can't be in both adjacent segments, but not sure I understand why the nodes don't get placed directly over the Star nodes when traced as above.

Since this behaviour is consistent, and since Polylines are generally used to outline roofs or doors or windows where actual placement of the Polyline nodes don't matter, I suspect what I'm seeing isn't a bug but an unforeseen aspect of "misusing" the Polyline model to trace a prop like a star where nodes are placed specifically to give shape.  That is, I believe Polyline was designed to represent, not duplicate, a string of nodes.

Anyway, here's the screen capture image.

[Gilrock]

Yeah PolyLine doesn't attempt to place nodes at the end points.  It calculates the total distance and then does an equal distribution unless you use the Individual Segments option and then tell it how many nodes to have in each segment.

[f11]

I did go with the Individual Segments thing, as Polyline's guesses about how many nodes were in each segment needed some adjustments. It didn't help much. While the double-tip nodes still look okay on my laptop renderings, its gonna generate a mess when I upload it to the actual star. Oh well, it was an idea worth exploring, and now I know something about Polyline for future use.

So I guess my next approach is the one allknowing2012 suggested originally:

[ Normally in your situation we would suggest you create with 1 string, right click export as a custom model. Then import that custom model, make it 3 strings, set to individual nodes - set accordingly. Now right click on the model and replace your star model with "this model". ]

At the risk of pissing you off with endless questions, Gilrock - any guestimate when Star might support multiple strings? Is that something near enough that I should hold off on further development of my "mega-star", or more of something on the distant horizon?

Appreciate you both for taking the time to respond to my original inquiry. When you're a noob to a piece of software, most of the obvious things aren't yet too obvious. I'll get there.

[Gilrock]

We never know when features will be added.  Any developer can get an itch to fix/change something at any time and we usually don't know what each other is working on.