Roygee - 15 November 2012 02:13 AM
Thanks - now that we know it refers to degrees, it makes sense
Yes, it SHOULD make sense…but I’ve made some oddball discoveries while playing around which seems to belie it after all. I’m starting to think that hexagon has an evil spirit intent on making me out to be a liar… 
Possibly the reason that 1/4 and 1/2 doesn’t work on a square is because the square is not precisely square?
No, it turns out that it’s connecting the “wrong” faces. This’ll take an explanation…
Imagine a square as the cross section. In your mind label the edges clockwise as A,B,C and D.
After sweeping, the end square is rotated according to the twist setting. At 360 degrees, the original square and the terminal square are both aligned A:A, B:B, C:C and D:D; exactly as if it hadn’t been rotated at all.
But at 90 degrees, the original and terminating squares are aligned A:B, B:C, C:D and D:A. At 180 degrees, they’re aligned A:C, B:D, C:A and D:B.
Now here’s the problem: After the sweep, hexagon bridges the original square’s edges to the terminating square’s edges by connecting A-A, B-B, C-C and D-D in EVERY CASE. So the ONLY case where that comes out “evenly” is with complete 360 degree rotations; everything else has the faces stretched and twisted between the “namesake” edges instead of connecting to the edge nearest to it.
And now about those “degrees”... 
I was playing around with high rotations and discovered that instead of using 1440, I got a really nice result using 1390! By dividing that number by 4, I got 347.5.
Odd number, but I played further and found that either 347 or 348 achieved as nice or better result than 360 did!
Likewise, 694/696 worked better than 720, 1941/1944 better than 1080 and of course, 1388 or 1392 works better than 1440.
And it’s still not over…
I reasoned that “shaving” the numbers worked because of the gap between starting squares and the terminal squares. If they were touching (as they should), then 360/720/1080/1440 would work perfectly. But in my examples, I used circles with 32 points in them, so the starting squares and the terminal squares were actually a tad over 11 degrees apart. By “shaving” the twist, I was effectively UNrotating the terminal square to a position where the edges would be bridged properly.
Following this reasoning, I made a circle using 256 points and tried the same trick. And as I suspected, the numbers I used for the 32 pt circles didn’t work for the 256 pt circles because now the separation was only about 1.4 degrees. For the 256 pt circle I only had to shave them a tiny bit to achieve perfection: 1434 replaced 1440.
And here is where I learned that the twist factor would accept decimals! Dividing 1434 by 4 gave me 358.5, which I entered into the twist instead of 360, and the 256 pt circle came out perfectly again! Likewise 717 and 1075.5 gave me perfection over 720 and 1080.
So the problem is the algorithm used to calculate a closed loop array. The math SHOULD be calculated as though the starting square and the terminating square occupied the same position. But they don’t. The terminating square is instead assumed to be located at a position APART from the origin depending on how dense the closed line is, and this space is then bridged which is a bit sloppy, IMO.
This actually creates a problem where a closed loop array MUST be tweaked depending on both the number of points in the closed loop, as well as the shape of the cross section.
But if you understand the problem as I laid it out (and I know it’s complicated and makes for tedious reading), at least you can figure out how to tweak it.
Here are the 256 pt circles with 358.5 | 717 | 1075.5 | 1434 degree twists
Click thumbnail to see full-size image
