Pinwheel fractual grasshopper

Is there an easy way to great this fractualisation in grasshopper using a standard tiling of a set triangle possibly to follow attractor points?

http://en.wikipedia.org/wiki/Pinwheel_tiling

Replies to This Discussion

Permalink Reply by Ryan Kings on March 15, 2015 at 5:52pm

Peter,

The new update is really great with the ability to move points about. Much appreciated!

I have attached a screenshot. I assume the fixed triangle ratio is lost because of the point positions which affect subdivisions?

So when I actually apply this to my larger file there could potentially be thousands of tiles.Hopefully my computer can handle it when it's rendering time!

The stop modes are relative to the input points right? Not another set of points potentially?

Thanks again,

Ryan

Permalink Reply by peter fotiadis on March 16, 2015 at 12:40am

Ryan,

Well ... the thing is that when you have subdivisions (in general: surface datatrees) in mind ... your 1:2:90degress rule couldn't have any meaning (for more than obvious reasons) thus IF you provide your own Rhino points (instead of the p1,p2,p3) this mode (RyanMode) is automatically deactivated.

I hear you: but then ... what is the meaning of that dual input mode?(which appears identical?).

Well in V5 you can operate with any collection of tri-Points (derived from surface subdivisions et all) meaning that the p1,p2,p3 way is required in order to have some clue about what the result MAY be. Called a "preview" mode if you like.

Stop is related with the distance between the projected point (from p3 to line p1p2) and p1 ( or the min p1/p2 - see options). Point p3 is defined (via a function) as the point with the biggest angle (in order to give the projection some meaning).

Permalink Reply by peter fotiadis on March 16, 2015 at 1:37am

And here's something a bit more complex for you:

1. On the left is a triad of C# things doing a delauney triangulation on some random points + convex hull points + putting some human figures in the "base". Then a system.object data tree is created containing a variety of data.

2. One branch {?;1} in particular is the right thing for our case:

3. So if you connect this to the V4 > it creates fractals based on the triad that you control via the slider (what sub branch, that is). No p1,p2,p3 any more.

4. But the thing is that since the whole "roof" is parametric and random you have no clue about the proper stop condition value (tile size) ... making the whole case as the perfect example related with Karma matters.

5. Additionally if you have connected all these scripts together and you go to the left C# and start changing values (modifying the "roof" topology) > can V4 keep up? And if not ... imagine feeding it with all the blue "roof" triangles

he he

Attachments: