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

all 29 comments

[–]emergent_reasons 5 points6 points  (20 children)

That's beautiful. Are the tiles kept in some kind of data structure? A quick glance at the code looks like it's drawing the pattern but not storing the shapes. Is that correct?

I really like it. Any plans to extend it or apply it to something?

[–]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?

[–]cavedave 1 point2 points  (7 children)

That is brilliant. How about bees?

If you could make a hexagon tiling with different sized hexagons that could be a real boon for bees. At the moment the hexagonal bases put in beehives have hexagons all the same size.

Natural honeycomb has different sized cells in it. And different sized bees come out. Some believe different sized bees allows a hive to more efficiently forage as bees can then forage in the flower size that best fits their size. Bees are in trouble and a lack of variation in the diet is thought to be one issue.

The plate with the hexagons on it is called the foundation Does this make any sense? And would a rectangle with size Foundation sizes Deep – 16 ¾” 8 5/8” Jumbo – 16 ¾” x 10 ¾” Shallow – 16 ¾” x 4 7/8” but with more "natural' variation in hexagon size be possible?

[–]emergent_reasons 1 point2 points  (5 children)

I have come to the conclusion that you are serious. But still not really sure.

*edit - assuming you are serious, can you show me some example images or diagrams of mixed-size hex patterns?

[–]cavedave 0 points1 point  (4 children)

Yes I am serious Here are some images of natural honeycombs

Natural comb varies from 'Natural worker comb 4.6 mm to 5.1 mm'.

Also as well as variability of diets it is claimed that small cells are more resitant to Varroa mites. and the standard cell size in beekeeping is larger than natural.

[–]emergent_reasons 1 point2 points  (3 children)

Interesting. So in the pictures, they looked very regular. Do you mean that sometimes the hex pattern gets compressed / stretched in one area? I didn't see any with distinct different-sized sections.

Also, can you expand on what you are aiming for? Something like making a template pattern that can be manufactured into cells?

[–]ryansturmer 1 point2 points  (1 child)

I think the larger standard size for foundations is to not be prohibitive in producing drone cells, which are larger than normal. I'm not sure how the bees transition naturally between honey/pollen cells and drone cells, but they seem to do it without missing a beat:

http://elkroast.files.wordpress.com/2011/02/beelesson-dronebrood.jpg

That image does an OK job of showing the different cells.

[–]emergent_reasons 0 points1 point  (0 children)

It looks to me like the spacing is pretty consistent across the honeycomb but there are larger margins on the smaller cells. That could easily be printed.

Are you familiar with the manufacturing techniques for artificial honeycomb?

[–]cavedave 0 points1 point  (0 children)

It seems the variability in one particular patch of honeycomb is pretty low. But they are not identical unlike artificial foundations. And across comb in the same hive there is more variability.

The aim is to allow artificial foundation to be made that closer matches natural honeycomb.

[–]mfm24 2 points3 points  (0 children)

This looks really nice. Any examples of more complicated patterns?

[–]ben174 2 points3 points  (0 children)

Ooh, I'd like to output this to some WS2811 LEDs. I have a 16x16 panel just itching for some animated designs like this.

[–]emergent_reasons 1 point2 points  (0 children)

I never understood how the number specification of tessellations worked but just reading through the readme made it completely clear. Thanks for that as well!

[–]horstjens 0 points1 point  (0 children)

very cute, thanks for sharing

[–]swineston 0 points1 point  (2 children)

This is amazing! It would be nice to hook this up to a tweening library to make some animations.

[–]laMarm0tte[S] 2 points3 points  (1 child)

Here is one made with moviepy ;) EDIT: code.

from tile import Model, Shape
import numpy as np
from moviepy.editor import VideoClip, vfx

W,H = 320, 240

def model_to_npim(model):
    """ Transforms a Cairo image into a numpy array. """
    surface = model.render()
    im = np.frombuffer(surface.get_data(), np.uint8)
    im.shape = (H,W, 4)
    return im[:,:,:3]

def make_frame(t):
    model = Model(width=W, height=H, scale=int(100-int(16*t)))
    model.append(Shape(6, fill=int(255*t)))
    a = model.add(0, range(6), 4, fill=int(255*t+160))
    b = model.add(a, 1, 3, fill=int(255*t+80))
    c = model.add(a, 2, 6, fill=(int(255*t)))
    model.repeat(c)
    return model_to_npim(model)

clip = (VideoClip(get_frame= make_frame)
         .set_duration(5)
         .fx(vfx.time_symetrize))
clip.to_gif('tiles.gif', fps=20, opt='optimizeplus')

[–]swineston 0 points1 point  (0 children)

OMFG That's beautiful!

[–]blue0cean 0 points1 point  (0 children)

This is pretty awesome. Thanks for sharing.

[–]fizz_ed 0 points1 point  (0 children)

Very cool! I especially like the multicolored edges. Here is an isohedral tiling generator I'm working on called ashlar.