O que é AABB e por que todo desenvolvedor de jogos precisa saber disso
AABB significa Axis-Aligned Bounding Box, e é basicamente uma caixa retangular que envolve um objeto no espaço do jogo, alinhada aos eixos X, Y e Z. Nada sofisticado, nada giria. É a forma mais barata e rápida de fazer detecção de colisão na maioria dos motores. Se você já programou alguma coisa em Unity, Godot ou até mesmo C++ puro com SDL, provavelmente esbarrou nisso sem perceber no começo. Muita gente acha que AABB é sinônimo de colisão perfeita. Não é. É uma aproximação. O benefício é o custo quase zero de computação. A desvantagem é que objetos com formas irregulares ficam com folgas enormes dentro dessas caixas. Um personagem correndo pode parecer estar colidindo com uma parede quando na verdade só encostou no canto da bounding box. Isso gera aquele comportamento estranho de "pegar" em superficies que visualmente não há contato.
aabb comunidade
No Brasil, existe uma comunidade bastante ativa em fóruns,Discords e grupos de Telegram que discute implementação de AABB, otimização de broad-phase, e como sair das armadilhas clássicas. O nome "aabb comunidade" aparece frequentemente como etiqueta nesses espaços. A galera costuma trocar dúvidas sobre quando usar separação de eixos (SAP), sobre broad/narrow phase, e como evitar que o cálculo de colisão vire gargalo em projetos com muitos objetos na tela.
Como implementar AABB do jeito certo
A estrutura básica é simples. Cada objeto tem um min e um max em cada eixo. Para checar colisão entre dois objetos, você verifica interseção em cada eixo separadamente. Se houver overlap em todos os eixos, houve colisão. Em pseudocódigo:
CheckOverlap(a, b):
return a.min.x <= b.max.x && a.max.x >= b.min.x
&& a.min.y <= b.max.y && a.max.y >= b.min.y
&& a.min.z <= b.max.z && a.max.z >= b.min.z Isso leva cerca de 6 comparações por par de objetos. Em 2D, são apenas 2 eixos, então 4 comparações. A performance é decente para até umas poucas centenas de objetos. Passa disso e o custo quadratico começa doer.
👉 Clique no botão abaixo para saber mais sobre o assunto!
O problema que ninguém conta nos tutoriais
Aqui vai uma coisa que eu aprendi na prática e que raramente aparece em tutorial básico: a AABB sozinha não resolve problema de narrow-phase. Ela é excelente para broad-phase, mas se você quer saber exatamente onde os objetos se tocam, qual vetor de separação aplicar, e quanto penetraram, aí precisa de TOI (Time of Impact) ou GJK em alguns casos. Eu passei duas semanas num projeto indie encaixotando colisão com AABB pura e o resultado era personagens trepidando quando desciam escadas. O problema não era a AABB em si — era que eu estava usando ela como única camada de colisão, sem nenhum refinamento posterior. A solução foi adicionar uma segunda fase com SAT (Separating Axis Theorem) para os casos onde a AABB indicava overlap mas precisávamos do vetor de resolução exato. O tempo de resposta caiu de algo instável para frame-consistente.
Quando AABB não funciona (e você vai descobrir tarde demais)
AABB falha feio em três cenários que eu vi acontecer repetidamente: Tunneling: objetos rápidos atravessam paredes porque a colisão só é verificada por frame. Uma bala veloz pode pular completamente a caixa no próximo tick. A solução é continuous collision detection (CCD), que verifica trajetória em vez de posição estática. Não é triviau de implementar, mas existem bibliotecas como PhysicsFS ou extensões no Box2D que já fazem isso.
Objetos muito inclinados ou rotacionados: AABB é axis-aligned por definição. Se seu objeto gira, a bounding box precisa ser recalculada a cada frame, e quanto mais rotacionado, mais folga aparece. O fix comum é usar OBB (Oriented Bounding Box) nesses casos, mas o custo de interseção sobe consideravelmente. Cenas com milhares de objetos: comparar cada par manualmente é O(n²). Aqui entra o conceito de broad-phase spatial partitioning — octrees, grid spatial, ou o já mencionado sweep-and-prune. Eu uso SAP na maioria dos meus projetos e reduzo de milhares de checks para talvez algumas dezenas por frame.
Dica prática que economiza horas
Se você está começando e quer algo que funcione sem dor de cabeça, implemente SAP (sweep and prune) como broad-phase e AABB como narrow-phase. O SAP ordena os objetos por um eixo e elimina pares impossíveis antes de calcular interseção. No meu último projeto, isso reduziu o número de checks de colisão de cerca de 2.000 por frame para algo em torno de 80-120, dependendo da densidade dos objetos. A diferença na CPU é brutal, especialmente em hardware móvel. Para quem quer estudar mais, procure por "aabb comunidade" em fóruns brasileiros de desenvolvimento de jogos. Tem bastante material prático, incluindo implementações em C#, GDScript e C++ que as pessoas compartilham. O nível de discussão varia — tem desde quem está vendo o conceito pela primeira vez até desenvolvedores discutindo otimizações avançadas de broad-phase. Vale a pena acompanhar.
Alternativas que valem considerar
Se AABB não estiver atendendo, algumas opções reais são: circles/spheres para velocidade máxima com shapes arredondados, OBB quando rotação é constante e previsível, convex hull para formas complexas sem a complexidade de mesh collision, e quadtree/bvhtree para organizar grandes cenários. Nenhuma é universalmente melhor. A escolha depende do que seu jogo realmente precisa. O mais importante é não tentar resolver tudo com uma única técnica. AABB é uma peça do quebra-cabeça, não o quebra-cabeça inteiro. Comece com ela, entenda onde ela falha no seu caso específico, e só então invista nas camadas extras de detecção. A maioria dos problemas de performance em jogos indie vem de alguém que tentou usar colisão de malha triangular em tudo, e aí a CPU entra em colapso com 30 objetos na tela.
