algorithmic modeling for Rhino
From each of these highlighted lines acting as the initial polygonal segment, I would like to generate an equilateral triangle. I thought this would be fairly simple by rotating each line 60 and then -60 degrees, and then joining the two rotated lines with the original line. The part that is not working the way I thought it would is the join component. When I plug in the three lists into the join component, they do not join the lines in order that they appear in the lists. Frankly, I don't know what is going on, or how to help myself. Is there a way to help the join command join lines in a specific order? Should I just split the list up into individual lines and join them together in an iterative fashion? Is there another way entirely to create an equilateral triangle with each of these lines being one segment of a triangle?
grafting the list containing all the lines into a tree with each branch having one line sounds like a good start.
then rotating each line 60 and -60 degrees, with rotation center start and end of each line could be a solution.
then joining the curves will be easier because of the data structure.
Get this def attached (it's not a cluster, he he):
1. if you provide your Line data (As a DataTree ) to the userLineTree input > that thing "senses" your data and ... your triangles are made - no random points et all (have fun with the up and/or makeBreps options).
2. if you don't, the thing works as stand alone and does ... er ... things, based on some random this random that logic.
BTW: You don't need to "rotate lines" : if you are an engineer and even if you don't have any idea about code, you'll get the gist of the logic used (elementary trigonometry and some vector stuff):
Following that queue about math and trigonometrics, you could just move the mid point up (or any other direction) by 0,86602540378443864676372317075294 (or whatever precision suits you) times the line length. Then add the line ends to create a triangle.
Of course it helps if you keep each line in a separate branch.
Yeah, that's a great idea - thanks for helping me figure it out in grasshopper language!
Added some options more (flip, angle etc)
Conceptually everything makes sense, so I'm sure before long I'll be able to apply and fully understand the lessons learned here. I've been hesitant to use data trees, but your explanation is pretty approachable. Thanks for showing the way!
If you intend to stay on the parametric/algorithmic/whatever bandwagon I would strongly suggest to switch entirely to code as regards "similar" matters (multiplied by 1M for complex real-life cases). Dealing with DataTrees with code is 12345 times easier (and 23456 times faster to develop AND update/upgrade the solution especially on a team basis). Without in depth understatement of what a DataTree is (it's just an "organized" collection of Lists - it's NOT a List of List of List ...) is highly frustrating to do business with GH (it's kinda waterstart in windsurfing: without it why bother doing the sport?).
Others may disagree mind with this code only approach of mine (but that's not my problem, at all).
PS: For fun: mastermind something that you think it's impossible to do with these points of yours (like sorting them on a closest pair basis, do some traveling salesman routing, re-sort them with some paranoid logic and then re-order them back ... or whatever) and post the case here (the description of the case to be exact).
best (learn C#), Peter
This looks pretty slick. Awesome! Thanks!
Alex, one question:
The "list item" components in the screen shot have a second nob on the right side marked "+1". Is that component different from the regular "list item" component? I can't figure out how to get the second nob.