Normal Line From Midpoint Of Shortest Side Of Polygon

Hello. I am a studio furniture maker and new to Grasshopper. I have been trying to create a definition that will draw a perpendicular line from the midpoint of the shortest side of a 2D polygon intersecting itself. The resultant line would then be grouped to that polygon. The definition would then allow me to set input an angle and rotate the polygon with that line determining that angle (the intersection of the perpendicular line and the shortest side being the center of rotation). I have attached a jpeg with 3 irregular pentagons with their corresponding lines on the left. On the right, for example, the polygons have been rotated 90 degrees. If anyone has done something similar and would care to share it with me, that would be great! Thanks.

Attachments:

POLYGON ROTATE.jpg, 35 KB

Replies to This Discussion

Permalink Reply by Aaron Levine on January 14, 2013 at 4:14pm

Chris, Jpeg of final veneer look. Grain direction and detail absent.

Attachments:

Leopard Geometry.pdf, 1.1 MB

Permalink Reply by Chris Tietjen on January 14, 2013 at 6:31pm

Here's the complete solution. Use the PerpetratorRev1 file to align and number your tiles. (Forget about the sellast-explode method mentioned.) After you run the PerpetratorRev1 file use the Rhinoscript file below. You will first be asked to select your curve set. Next you will be asked to select your number set. Both of these selections can be made with the basic selection box, just make sure that you select the same number of numbers as you've selected tiles (closed curves). The script will complete and each number will be grouped to its closed curve. Next use the Edit menu to select Text and then Explode the selection to get your machinable curves. Let me know if you run into any problems.

Attachments:

GroupingForTiles.rvb, 1 KB

Permalink Reply by Aaron Levine on January 14, 2013 at 5:24pm

Chris, I am sending you the whole pattern file in Rhino. If you just work with the .oo1 offset layer (blue) and try and select too many polygons, there is an error in the centroid process about closed polygons. I checked the polygons by extruding solids and looking for holes but everything looked fine. If I take the numbering aspect out, it seems to work. Also, the slider inputs into the grid need to be larger for more tiles or only part of the rotated tile output is developed. Aaron

Attachments:

Whole Pattern.3dm.zip, 2 MB

Permalink Reply by Chris Tietjen on January 14, 2013 at 7:28pm

Testing your entire pattern for grouping everything seems to work for me. The only glitch I noticed is where two tiles overlap by a considerable amount. You have to make sure you set the spacing in the grid large enough to keep that from happening. Also it looks like there are six curves that aren't actually closed. These easily stand out if you use 'SelClosedCrv' Command. Probably the workflow should then go bake the closed curves into rhino and then run 'SelClosedCrv' then 'Invert' and then run 'CloseCrv'. Run 'SelClosedCrv' again to be certain you've got them all and then bake in the numbers. Then you should be able to run the Rhinoscript to get the complete grouping. I can do a better job getting the grid to match the number of tiles exactly. I'll work on that. Also the script runs slowly because for some reason unknown to me the Rhino.EnableRedraw method does not seem to be working. I'll save your pattern file in V4 and see if the script runs correctly there. Without the redraw staying enabled the script should complete very quickly and not at all like it is with redraw enabled though even crippled it's still faster than doing it manually.

Attachments:

PerpetratorRev2.gh, 52 KB

Permalink Reply by Aaron Levine on January 14, 2013 at 10:24pm

Chris, I repaired the six polygons (Offset 001 layer) by re-snapping their control point ends and rejoining so the original drawing is clean. Don't understand it but it is good. The rhinoscript runs slowly but plenty fast so everything is working for one set of polygons. If I try to select the next inside set (Outer Polygon), GH does not order or list them them the same so they do not line up inside the first set and so on to the next most inside set of polygons (Inner Polygons) after running through PerpetratorRev2. Have you tried that with any success? Here is the cleaned drawing.

Permalink Reply by Aaron Levine on January 14, 2013 at 10:30pm

Repaired Drawing

Attachments:

Whole Pattern Repaired.zip, 2 MB

Permalink Reply by Chris Tietjen on January 14, 2013 at 11:20pm

Aaron, I find that the culprit is Rhino 5. When I ran PerpetratorRev2 in V4 there were no problems with open curves. I also tried a different approach with the Rhinoscript to eliminate the visible selection but there was no increase in speed so I'm going to assume that it's the actual parsing of the data that is taking so much time rather than the redraw aspect.

I see how the plot thickens when the inner curves are brought into play. It might be that we have to make surfaces from the outer polygons and then project the inner curves onto the surfaces. Then the surfaces can be rotated with the inner curves maintaining proper relationship to each other and the boundary curve.

Permalink Reply by Chris Tietjen on January 15, 2013 at 12:25am

How's this for a small sample of the pattern?

Attachments:

PerpetratorRev3.gh, 18 KB

Permalink Reply by Aaron Levine on January 15, 2013 at 8:43am

Dear Chris, That looks promising! Did you do that in Rhino 4 or Rhino 5? I could only load PerpetratorRev3.gh into Rhino 5. Did you try it on the full pattern? When I tried it on the tiles, the 'BOUNDRY' or outermost blue layer works but the subsequent inner polygons went everywhere. Only when I select subsequent polygons in the EXACT ORDER one at a time does it all work out at all but that is impractical. In Rhino 4, when trying to load the GH definition, I got this error: "Object reference not set to an instance of an object" Are the GH versions of 0.9.0014 different for Rhino 4 and 5? Do I need to uninstall and install each time I move between Rhino 4 and 5? Sorry about my ignorance in this matter. Here is a screen shot. Aaron

Attachments:

Whole Pattern Rhino 5 PerpRev3.pdf, 362 KB

Permalink Reply by Chris Tietjen on January 15, 2013 at 9:03am

Aaron, Rev4 below works off of the centroid rather than an external reference point. This seems to work as we've been hoping. I've only tested it in V4 but it should in theory be completely compatible with V5. That error you got isn't related to GH or Rhino versions just that some referenced geometry wasn't there for it to recognize. No you don't need to uninstall Rhino versions. The can run side by side. I'm going to recommend that you test the Rev4 file on less than the whole pattern at first as it takes a robust computer to handle all of the calculations. My computer is barely up to the task but the definition did appear to produce the desired result. I haven't tried running the Rhinoscript to group the items. I'm away from the computer for the rest of the day. Good luck with it. Let me know how it goes.

Attachments:

PerpetratorRev4.gh, 19 KB

Permalink Reply by Chris Tietjen on January 15, 2013 at 10:57pm

Screencast Link

Screencast above shows the workflow. Use the files below. It was necessary to modify each a little bit to get to the end. Let me know how it goes.

Attachments:

PerpetratorRev5.gh, 35 KB
GroupingForTilesRev1.rvb, 1 KB

Permalink Reply by Aaron Levine on January 16, 2013 at 1:19pm

Chris, Thank you for putting the Screencast together, it was both thoughtful and helpful. PerpetratorRev5 is working great! The only problems I have is if I try to do the whole pattern, Rhino has problems. I just divide my pattern into two bite-sized chunks and it works fine. The last little tweak, and I hope this one is not difficult and thereby causing you to send the goombas over to take care of me, is the the inner curves (the innermost and the next one out) are grouped together in your definition and I have to bake them as one. If they could be treated as two different groups, I could bake the innermost and the next one out separately. I can go in Rhino and select the inners from the next by hand if this is a big problem. Let me know. Thanks, Deeper-in-debt Aaron.