Imagem De Um Polígono

Transformações geométricas de polígonos: o que realmente acontece

A imagem de um polígono sob uma transformação é simplesmente o conjunto de pontos resultante quando se aplica uma função a cada vértice e se reconecta tudo na mesma ordem. Na prática, isso significa pegar coordenadas, multiplicar por matrizes ou aplicar funções e Pronto. O polígono se move, gira, amplia ou distorce, mas a estrutura topológica permanece. Eu já passei horas debugando código onde a imagem de um polígono aparecia corretamente no papel mas falhava na tela. O problema era mais chato do que parece: precisão de ponto flutuante em transformações afins encadeadas. Quando você aplica rotação seguida de translação em vértices com coordenadas decimais longas, o erro se acumula e arestas que deveriam coincidir passam a ter gaps de cerca de 0.003 unidades. Isso destrói renderização por preenchimento e algoritmos de interseção.

Calculando a imagem de um polígono na prática

O procedimento básico é direto. Você pega cada vértice do polígono original, representa como vetor coluna, multiplica pela matriz de transformação e obtém o novo vértice. Para uma transformação afim em 2D, a matriz é 3x3 com homogeneidade, ou 2x2 mais um vetor de translação separado. A ordem dos vértices importa: se o polígono original é listada no sentido anti-horário, a imagem também será, desde que o determinante da parte linear seja positivo. Aqui vai algo que poucos explicam: a imagem de um polígono convexo sob transformação afim continua convexo, mas um polígono não convexo pode ter sua qualidade topológica alterada de formas inesperadas. Se a transformação inclui cisalhamento forte e o polígono original tem ângulos rasos próximos de 180 graus, vértices quase colineares podem se reordenar numericamente e criar auto-interseções que não existiam antes. Isso é particularmente problemático em softwares de CAD onde você precisa manter a validade geométrica. O workaround que eu uso agora é simples e resolveu meu problema há dois anos: após calcular todos os vértices transformados, faço uma verificação de colinearidade com tolerância relativa baseada na escala do objeto, não absoluta. Se três vértices consecutivos estão dentro de 1e-9 da colinearidade na escala do bounding box, os removo antes de prosseguir com qualquer operação de renderização ou cálculo de área. Isso elimina artefatos sem alterar visualmente o resultado.

Para quem trabalha com imagem de um polígono em sistemas de desenho vetorial, vale saber que a escolha entre representação por vértices e por semi-planos (interseção de semiplanos) faz diferença prática. A forma matricial é mais rápida para transformações compostas porque você concatena matrizes primeiro e aplica uma vez só aos vértices. Mas se o polígono for complexo com dezenas de vértices e você precisar de recortes ou interseções frequentes, a representação H pode ser mais estável numericamente. Outro ponto que ninguém destaca: transformações projetivas, usadas em correção de perspectiva, exigem divisão pelo terceiro componente homogêneo. Se esse componente for próximo de zero para algum vértice, aquele ponto vai para o infinito e o polígono se divide em duas partes separadas no plano projetado. Isso não é bug, é comportamento matemático correto, mas em implementação ingênua simplesmente quebra o rendering. Eu sempre verifico o valor absoluto do denominador antes de dividir e divido o polígono ao longo da linha onde o denominador cruza zero quando necessário. O custo computacional de calcular a imagem de um polígono com N vértices sob transformação afim é O(N), pura multiplicação matricial. Com transformação projetiva, o custo sobe para O(N) também mas com operações de divisão por vértice, que são mais caras que multiplicação. Em pipelines reais, se você transforma o mesmo polígono múltiplas vezes, acumule as transformações em uma única matriz 3x3 antes de aplicar. Isso reduz de múltiplas multiplicações matrix-vértice para uma só, economizando tempo significativo quando o polígono tem milhares de vértices.