Polígono De 10000 Lados

Construir um polígono de 10000 lados não é difícil, mas exige paciência com floats e tolerância a ruído numérico

polígono de 10000 lados

Um polígono de 10000 lados, ou uma decagonsidemilão (na nomenclatura que poucos usam), é basicamente um círculo disfarçado para computadores que precisam de vértices discretos. A geometria é simples. O polígono regular com n lados inscrito em um círculo de raio R tem ângulo central de 2/n entre vértices consecutivos. Para n = 10000, isso dá 0,000628318 radianos, ou aproximadamente 0,036 graus. Cada lado mede 2R·sen(/10000). Com R = 1, o lado tem cerca de 0,000628 unidades. A soma dos ângulos internos segue a fórmula clássica (n-2)·180°. Para 10000 lados, fica 1.796.400°. O ângulo interno de cada vértice é (n-2)·180/n = 179,964°. Ou seja, quase perfeitamente plano. Uma aresta seguida pela próxima mal se desvia. Visualmente, até em resolução baixa, parece um círculo perfeito. Isso é útil e irritante ao mesmo tempo, porque depende do que você precisa fazer com ele. Na prática, eu desenhei um desses polígono de 10000 lados uma vez usando apenas coordenadas polares convertidas para cartesianas, com ponto central em (0,0) e raio 50. O código em si é cinco linhas. O problema veio depois, na etapa de exportação para um SVG que seria usado em CNC. O contorno tinha 10000 arestas. O software cortava isso linha por linha, e o tempo de processamento explodiu de 4 segundos para 2 minutos e 30 segundos só na fase de interpolação, sem contar o aquecimento do controlador. Não é um problema do polígono. É um problema da cadeia de ferramentas.

Como gerar os vértices corretamente

O método mais direto é iterar de i = 0 a 9999 e calcular: x_i = cx + R·cos(2·i/n)
y_i = cy + R·sen(2·i/n) Isso funciona. A precisão depende do tipo numérico. Em float de 32 bits, a partir de i 4000 você começa a perder detalhes finos na região oposta ao início, porque o cosseno acumula erro de arredondamento progressivo. Em double de 64 bits, o erro fica abaixo de 1e-15 para raio da ordem de 100, que é mais que suficiente para a maioria dos propósitos práticos.

Uma alternativa que eu uso quando preciso de consistência extrema é gerar os ângulos primeiro como uma sequência aritmética de passo = 2/n e aplicar cos/sen acumulativo via recursão de Adstock-Rogers, mas isso é overkill para 10000 pontos. A forma ingênua já entrega precisão aceitável se você usar double.

O problema que ninguém avisa

O ruído numérico é silencioso. Quando você fecha o polígono, o último vértice calculado pode não bater exatamente com o primeiro por uma diferença de ~1e-14 em double. Em renderização gráfica isso não aparece. Em simulação física ou em malhas que serão remeshadas, sim. Eu já vi o mesh fechar com uma fenda de tamanho invisível a olho nu, mas que quebrava um solver de elementos finitos inteiro porque a condição de fronteira não era contínua. A correção é trivial: sobrescreva explicitamente vertex[9999] = vertex[0]. Custo zero, problema resolvido. Outro detalhe que passa despercebido: a distribuição dos vértices em pontos cardeais e secundários não é uniforme em termos angulares exatos para n = 10000. Se seu aplicação exige que um vértice caia exatamente em 0°, 90°, 180° e 270°, verifique se 2·i/n bate nesses valores. Para 10000 lados, i = 2500 dá exatamente /2 em teoria, mas em float pode haver um desvio da ordem de 1e-16. Em sistemas que comparam igualdadade de coordenadas, isso gera falhas difíceis de diagnosticar.

Quando usar e quando não usar

Use um polígono de 10000 lados quando você precisa de uma aproximação circular com controle explícito de vértices e não quer depender de curvas Bézier ou arcs nativos do formato de exportação. Isso é comum em geração procedural de geometria para jogos, em simulações de onda em domínios circulares discretizados, e em rotinas de collision detection que operam sobre malhas poligonais. Um SDF baseado em polígono regular com 10000 lados tem erro máximo de aproximadamente R·(1 - cos(/10000)) R·1,96·10^-7, ou seja, submicrométrico parao de unidade 1. Isso é mais que suficiente para a maioria dos casos. Não use quando o downstream não aguenta 10000 faces. Exportar para STL, OBJ ou SVG com 10 mil arestas é pesado. Um STL bem compactado ocupa cerca de 300 a 500 KB textuais, e a maioria dos slicers leva de 8 a 15 segundos para processar só a leitura, sem falar no tempo de fatiamento. Se o objetivo é impressão 3D, um círculo paramétrico nativo do slicer é imbatível. Ele usa arcos exatos, não aproximações poligonais. Também não use se você precisa de simetria perfeita em transformações que envolvem rotações sucessivas. A quantização angular de 2/10000 introduz pequenos desvios que se acumulam em múltiplas rotações. Eu aprendi isso na dura quando um anel de engrenagens virtuais com 10000 dentes apresentava jogo acumulado após 12 rotações completas no simulador. O conserto foi switchar para representação complexa direta, multiplicando por e^(i·2/10000) a cada passo, em vez de recalculiar seno e cosseno a partir de ângulos absolutos.

Um fallback que eu recomendo

Se o seu pipeline não suporta muitos vértices, reduza para um polígono de 360 lados. Cada grau tem um vértice. O erro máximo cai para R·(1 - cos(/360)) R·1,22·10^-5, ainda aceitável para visualização e Para a maioria das simulações de baixo custo. Se precisar de mais precisão, 720 lados cobrem meio grau. Eu costumo começar com 10000 para gerar o dataset, depois reduzir automaticamente com simplificação de Douglas-Peucker quando vou exportar para formatos que exigem menos vértices. O resultado mantém a forma visualmente idêntica e corta o tempo de processamento em cerca de 70%.