Draw Hexaflake Fractal

A fractal generated by recursively subdividing hexagons. Each hexagon is replaced by 7 smaller hexagons: 1 at the centre, 6 at the vertex directions (each at 1/3 the parent’s size). It has perfect 6-fold rotational symmetry and Hausdorff dimension log(7)/log(3) ≈ 1.7712. It’s the hexagonal analogue of the Sierpiński triangle’s 3-fold pattern. Also called “hexaflake” or “Sierpiński hexagon” in some literature.

Self-similarity formula: dim = log(N)/log(S) where N copies are placed at scale 1/S of the original. Hexaflake: N = 7 (centre + 6 surrounding), S = 3 (each sub-hexagon is 1/3 the parent’s diameter – because the distance from parent centre to sub-hexagon centre is 2/3 of parent radius, and sub-hexagon radius is 1/3 of parent’s). So dim = log(7)/log(3) ≈ 1.7712. Notably HIGHER than the Sierpiński triangle (log(3)/log(2) ≈ 1.585) because more sub-copies are kept per iter.

The subdivision rule itself has 6-fold symmetry: the 6 surrounding hexagons are placed at 60°, 120°, 180°, 240°, 300°, 360° from the centre (=0° start). Rotate the whole pattern by 60° and the 6 surrounding hexagons map to themselves (relabelled). The centre hexagon also has 6-fold symmetry intrinsically. So the rule preserves the symmetry at every recursion level, and the limit pattern has 6-fold rotational symmetry.

Natural snowflakes have 6-fold symmetry because they’re formed from hexagonal ice crystals (water molecules form a hexagonal lattice in solid form). The hexaflake captures the MATHEMATICAL idealisation of this symmetry. Real snowflakes are NOT exact hexaflakes – they’re more like dendrites (branching crystals) with growth driven by temperature/humidity gradients. But they share the underlying 6-fold geometry. Wilson Bentley’s famous 1885 snowflake photographs show this 6-fold rule applied with infinite natural variation.

Each subdivision level gets a different colour. The centre hexagon (deepest level, drawn first) gets one colour; the 6 surrounding hexagons (one level shallower) get the other; their sub-hexagons alternate again. Reveals the recursive structure visually: you can trace which hexagons came from which iteration. Beautiful at iter 3-4 where the layering is visible without being overwhelming.

Filled: every hexagon is drawn as a solid polygon with semi-transparency (fill-opacity slider). At iter 4+ the overlaps stack into rich gradients. Outline: only the hexagon edges are stroked – emphasises the geometric structure. Both: combines fill + outline for a “sketched” look. Outline alone is great for iter 5 to see the tens-of-thousands of edges; Filled alone is great for iter 3 to see the colour structure; Both is the default for the prettiest result.

Hexagon count at iter N = 7^N. Iter 5 = 16,807. Iter 6 = 117,649. Iter 7 = 823,543. Each hexagon is a separate Canvas fillRect+stroke operation. At ~120k operations, render time jumps to seconds; at 800k, the path data alone is tens of MB and browsers freeze. Iter 5 is the comfortable ceiling. Iter 5 already loads in ~500 ms on desktop, ~1.5 s on mobile (hence the “Drawing…” loading state).

The canvas has TWO resolutions: CSS-displayed size (600×600 here) and backing-store size (the pixel buffer). On Retina (DPR 2), the CSS-displayed 600 px corresponds to 1200 physical pixels. Without DPR-aware scaling, the canvas buffer stays at 600×600 and the browser upsamples to 1200 px (blurry). Now: backing store is set to 1200×1200 with a setTransform(2,…) so drawing operations are scaled accordingly.

Yes – 100% client-side. Hexagon generation and Canvas drawing happen in your browser. No parameters or images leave your device. Verify via your browser’s Network tab – only the initial HTML/CSS/JS load occurs.