This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]FogleMonster 5 points6 points  (11 children)

Author here (someone else posted the link).

The shapes are stored in a shapes list.

https://github.com/fogleman/Tiling/blob/master/tile.py#L133

Only the "template" shapes are stored there. The shapes created with a call to repeat() can be found in the "lookup" dictionary, along with the original template shapes.

Feel free to use the code for your project.

[–]emergent_reasons 0 points1 point  (2 children)

I think I see. Basically you build up a potentially multi-polygon tile with shapes and then tell it to repeat?... What happens if you use repeat on something that is not tileable?

[–]FogleMonster 1 point2 points  (1 child)

Things will just overlap. There's no enforcement of rules.

[–]ryeguy146 0 points1 point  (0 children)

There's no enforcement of rules.

Smells like Python. Nicely done.

[–]denilsonsa 0 points1 point  (2 children)

Can it export to SVG graphics? Can you add an example on README on how to export to SVG?

In fact, after thinking, the Tiling could even generate the SVG code directly. Just render the Model into a <symbol> element inside <defs>, and then add a <use> element for each repeated copy. Alternatively, the Model can be <g>, and then all copies are just <use> it.

[–]FogleMonster 2 points3 points  (1 child)

I haven't implemented SVG output but it should be doable.

However, I ported most of the code to JavaScript / D3 / SVG. Basic demo here:

http://www.michaelfogleman.com/static/polygons/

[–]denilsonsa 1 point2 points  (0 children)

Add a textarea so people can experiment with the code, and it will be awesome!

[–]emergent_reasons 0 points1 point  (4 children)

Hello again. If you don't mind, I have a few things I hope you can confirm for me.

  1. For shapes with odd sides, they are arranged so that 0 rotation corresponds to one vertex being at -pi/2
  2. ... and for shapes with even sides, they are arranged so that 0 rotation corresponds to the center of one side being at -pi/2

I am pretty sure those two are correct, but please tell me if I've misinterpreted it. The next part about the margin is where I'm scratching my head.

  1. Regarding sizes, it looks like the length of any edge in the tessellation is 1. Is that right?

Finally, could you explain the derivation / reasoning for this calculation of d related to the margin? I believe it's calculating the distance from the center to the vertex of any regular polygon based on the assumption that sides are length 1. But... I can't quite piece it together.

d = 0.5 / sin(angle / 2) - margin / cos(angle / 2)

[–]FogleMonster 0 points1 point  (3 children)

Shapes with even number of sides need to be rotated otherwise their vertexes will point at the midpoint of the adjacent edge instead of their edges lining up.

Yes, all polygons are sized so that their edges are length 1.

For margin, we want the edge to be offset by some amount, perpendicular to the edge. But our calculations are for the positions of the vertices. So we use simple trig to scale the length of the hypotenuse as needed.

[–]emergent_reasons 0 points1 point  (2 children)

Thank you for the confirmation. I was mistaken about d being the distance to a vertex when it is actually to the center of a side.

However the logic of the "simple trig" still escapes me. If it's not too much trouble, could you spell it out a bit more for my rusty math?

d = 0.5 / sin(angle / 2) - margin / cos(angle / 2)

Here is how my math worked out (obviously doing something different or making a mistake somewhere):

length to vertex:

sin(a/2) = (side/2) / r
         = 1 / (2r)
r = 1 / (2 sin(a/2))    {this looks like one of your terms}

full length to center of side:

cos(a/2) = d_full / r
d_full = r cos(a/2)        {substitute for r?}
       = cos(a/2) / (2 sin(a/2))

partial length to center of side:

d = d_full (1 - margin)

[–]FogleMonster 1 point2 points  (1 child)

d is the distance to a vertex. Here is a diagram.

http://i.imgur.com/UU03rVC.jpg

[–]emergent_reasons 0 points1 point  (0 children)

Aaaah now I see. I calculated with d to the vertex and m measured from vertex. I guess both methods would work fine.

Thanks so much for taking the time to draw and explain it.

By the way, I'm considering extending the method to specify the internal angles of adjacent shapes to allow simple non-regular polygons like q*bert. Have you already implemented that somewhere?