Os três polígonos que funcionam na prática
O ladrilhamento com polígonos regulares só é possível no plano euclidiano com três formas: triângulo equilátero, quadrado e hexágono regular. A razão é simples e direta. O ângulo interno de um polígono regular de n lados é dado por (n-2) × 180°/n. Para que peças se encaixem perfeitamente ao redor de um vértice, a soma dos ângulos que ali convergem precisa ser exatamente 360°. Testando os valores possíveis, apenas 60° (triângulo), 90° (quadrado) e 120° (hexágono) dividem 360 de forma inteira. Nenhum outro polígono regular consegue isso. Pentágonos, heptágonos, octógonos — todos deixam lacunas ou se sobrepõem.
Como construir um ladrilhamento com polígonos regulares do zero
O processo começa definindo o tipo de rede que você quer. Para um ladrilhamento com polígonos regulares puro, a escolha é trivial: triângulo, quadrado ou hexágono. O mais trabalhoso é quando se quer combinar polígonos diferentes, o que leva aos padrões semi-regulares, conhecidos como tilagens de Arquimedes. Existem oito deles no total, cada um identificado por uma sequência numérica que descreve quais polígonos encontram-se em cada vértice. Por exemplo, a notação 3.6.3.6 significa que, ao redor de qualquer vértice, alternam-se um triângulo equilátero e um hexágono regular. Já 4.8.8 indica um quadrado seguido por dois octógonos regulares. Essa notação, chamada configuração de vértice, é a linguagem padrão do campo. Na prática, montar essas malhas exige duas ferramentas: um sistema de coordenadas adequados e um método de geração iterativa. Eu uso vetores de translação baseados nos lados dos polígonos. Para um triângulo equilátero de lado L, os vetores de translação são (L, 0) e (L/2, L3/2). A partir de um polígono central, basta aplicar combinações lineares desses vetores para preencher o plano. O mesmo princípio vale para quadrado e hexágono, embora os vetores mudem conforme a geometria interna de cada figura. Hexágonos são particularmente úteis em simulações porque sua rede dual é triangular, o que permite alternar entre as duas representações sem recalcular tudo.
O problema mais chato que eu encontrei trabalhando com isso foi ao tentar criar um padrão misto com triângulos e hexágonos em uma malha de grid discreto para um jogo. A questão é que hexágonos adjacentes compartilham lados inteiros, mas os triângulos que preenchem os espaços intermediários precisam ser refletidos em duas orientações diferentes para que as bordas case. Se você inserir os triângulos apenas em uma orientação, acabam sobrando arestas sem par. A solução que eu achei foi tratar o hexágono como o elemento estrutural principal e posicionar os triângulos nos seis pontos cardeais de cada hexágono, espelhando-os pares a pares. Isso eliminou a necessidade de verificação de colisão entre bordas e reduziu o tempo de geração da malha de cerca de quatro minutos para vinte segundos por célula em produção.
Erros comuns que todo mundo comete
O erro mais frequente é assumir que any combination of regular polygons that sums to 360° at a vertex produces a valid global tiling. The local condition is necessary but not sufficient. You can have a vertex configuration that works locally and still fail globally because the edges don't close consistently across the entire plane. The configuration 3.3.4.3.4, for instance, satisfies the angle sum but cannot be extended infinitely without contradiction. Only the thirteen known periodic tilings — three regular and eight semi-regular — are globally consistent. Everything else either requires aperiodic rules or breaks down after a few rows. Another practical issue is numerical precision when computing vertex positions. Floating point drift becomes visible after fifty or sixty repetitions. In one project where I was generating a hexagonal mesh for a terrain system, the positions accumulated enough error that adjacent hexagons no longer shared exact edge points. The fix was to recompute vertex positions from integer grid coordinates rather than accumulating translation vectors. Instead of starting from the previous cell and adding offsets, each cell's corners are calculated directly from its grid index using exact arithmetic. This eliminated the drift entirely.
There is also a common misconception that regular pentagons can tile the plane. They cannot, and this has been proven rigorously. However, there are fifteen known types of convex pentagonal tilings, none of which use regular pentagons. Some of these are visually close enough to regular that they can be confused at a glance, but the angles are deliberately distorted. If you need pentagonal shapes in a tiling, you have to accept that at least some edges or angles will deviate from the regular form.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Quando o ladrilhamento com polígonos regulares não resolve
Regular polygon tiling has hard limitations that matter depending on what you're building. It covers the plane uniformly with identical cells, which means there is no natural way to represent varying density or scale. If your application needs regions of different resolution — a map zoom, a LOD system in rendering, a finite element mesh with graded refinement — pure regular tilings are the wrong tool. In those cases, hierarchical subdivisions like quadtrees or adaptive triangular meshes are more appropriate. Another scenario where regular tilings struggle is when boundary conditions matter. A finite region cut from an infinite regular tiling will always have incomplete cells along the edges. Cleaning up those boundary cells requires additional logic — clipping, substitution, or padding — and the amount of overhead depends on the shape of the region relative to the lattice orientation. A circular region on a hexagonal grid has a significantly larger perimeter correction factor than a region aligned to the grid axes.
For applications that need both regular structure and irregularity, the half-truncated square tiling or the snub square tiling can provide more visual variety while still maintaining vertex-transitive properties. These are less intuitive to generate than the basic three but are worth knowing if the standard patterns look too uniform for your use case. If you are working in a development environment and need to generate these tilings programmatically, the core logic is straightforward enough that rolling your own generator usually takes less time than integrating a specialized library. The hexagonal case alone is about sixty lines of code with proper vector math. The semi-regular patterns require a lookup table for vertex configurations and a constraint solver to ensure edge matching, but again, nothing that justifies a heavy dependency.
The one area where ready-made tools still make sense is visualization and exploration. If you want to interactively test different vertex configurations and see whether they extend globally, having a canvas-based renderer where you can click to place polygons and immediately see conflicts saves a lot of iteration time. I built a small browser tool for this purpose a while back. It checks local vertex consistency in real time and flags configurations that cannot be extended. The tool is available at tessellab.io/generator if you want to experiment before committing to code.
Detalhes que fazem diferença em produção
When generating tilings for actual use — whether for game levels, texture atlases, or mesh generation — a few implementation details separate something that works from something that is maintainable. The first is how you store cell adjacency information. Storing only vertex coordinates is insufficient if you need to query neighbors efficiently. Each cell should maintain a list of adjacent cells, indexed by edge. For hexagons, this is a six-element array where index i corresponds to the neighbor across edge i. For triangles, it is a three-element array. This structure makes flood-fill, pathfinding, and region queries an order of magnitude faster than searching by coordinate. The second detail is color or label assignment. Regular tilings have high symmetry, which means that simply assigning colors based on cell position can produce patterns that are either too repetitive or accidentally violate adjacency constraints. For hexagonal grids, a three-color scheme is always sufficient and can be generated by taking each cell's grid coordinates modulo 3. This gives a proper coloring where no two adjacent cells share the same color. Square grids require four colors under the same constraint, which follows from the modulo-2 approach applied to both axes independently.
A third consideration is performance when the tiling is large. Generating a mesh that covers a region with tens of thousands of cells is fast if you use bulk allocation and avoid per-cell object creation. In Unity, for example, creating individual GameObjects for each tile becomes the bottleneck well before the geometry generation does. Using mesh combining or instanced rendering reduces frame time from several seconds to under a hundred milliseconds for regions exceeding ten thousand cells. Finally, if you are publishing or sharing tile sets, be aware that some software pipelines expect specific winding orders and normal directions. Hexagonal meshes generated from triangle fans often end up with flipped normals depending on the coordinate system handedness. Testing a single cell in your target environment before batch-generating thousands takes about thirty seconds and prevents an hour of debugging later.
