godot-box3d

godot-box3d é uma GDExtension que integra o Box3D, o motor de física 3D de Erin Catto, ao Godot 4 como um substituto direto do PhysicsServer3D embutido. Os nós de física padrão do Godot continuam funcionando: você altera uma configuração do projeto em vez das suas cenas. O projeto é descrito como inicial e experimental, e o próprio Box3D é um motor jovem. Motivação: o autor está desenvolvendo SurfsUp, uma recriação do "SkillSurf" do motor Source no Godot. Mapas de surf exigem muito da física com longas rampas trimesh côncavas, curvas em alta velocidade e surf de cabeça sob a geometria. A física embutida do Godot e o godot-jolt supostamente têm dificuldades com partes disso. O Box3D originou-se do Rubikon-lite da Valve, o motor de física do Source 2, então um solver da linhagem Rubikon pareceu valer a pena testar. A ponte entre o PhysicsServer3D do Godot e o Box3D segue a arquitetura do godot-jolt. Comparado com box3d-godot, outra integração do Box3D para o Godot: box3d-godot expõe o Box3D como 14 nós personalizados que rodam junto à física do Godot, enquanto este projeto substitui a física do Godot. Isso significa que nós padrão e addons existentes continuam funcionando, mas recursos exclusivos do Box3D, como explosões, torque giroscópico, profiling do solver e stepping assíncrono, não são acessíveis pela interface PhysicsServer3D. box3d-godot oferece mais tipos de juntas (8 vs 3), uma restrição de roda real e mais plataformas (Android, web), enquanto este projeto suporta heightfields e VehicleBody3D via raycast. O README afirma que este projeto está atualmente atrás do box3d-godot em tipos de juntas, ConeTwist e 6DOF, índices por forma nos resultados de consulta, profiling e plataformas. Nenhum dos dois é descrito como pronto para produção. O que funciona: corpos rígidos, estáticos e cinemáticos; formas incluindo caixa, esfera, cápsula, cilindro, polígono convexo, polígono côncavo (trimesh), heightmap e limite de mundo; áreas com eventos de sobreposição, sobrescritas de gravidade/amortecimento, ordenação por prioridade e gravidade pontual; consultas diretas ao espaço (ray casts, interseção de ponto e forma, shape casts, collide_shape, rest_info); body_test_motion para que CharacterBody3D e move_and_slide() funcionem; monitoramento de contato com pontos de contato reais, normais e impulsos; exceções de colisão por par; juntas pin, hinge e slider; um solver multithread com núcleos físicos detectados automaticamente e uma sobrescrita worker_count, determinístico entre contagens de workers; e um projeto de teste com um hub de demonstração, benchmark determinístico e 19 testes de regressão headless. Trabalho restante inclui separation ray shapes, juntas ConeTwist, Generic6DOFJoint3D (o Box3D não tem restrição de lock/limit/motor por eixo, então não existe mapeamento fiel), SoftBody3D, índices por forma nos resultados de consulta e contato, profiling do solver, binários universais para macOS e notarização, mais plataformas e arquiteturas, e benchmarking e ajuste de desempenho. Diferenças de comportamento estão documentadas: Area3D não detecta corpos trimesh ou heightmap, já que formas côncavas do Box3D não podem atuar como visitantes de sensor por design; collide_shape() reporta pontos de contato sem profundidade de penetração porque o Box3D expõe GJK; consultas de forma precisam de uma forma de consulta convexa; e fricção e restituição se combinam de forma diferente (sqrt(a*b) para fricção, max(a,b) para restituição, versus min(a,b) e soma limitada do Godot), então materiais podem precisar de reajuste. O README inclui uma cena de benchmark que derruba caixas sobre uma rede fixa a partir de uma semente fixa até existirem 4096 corpos, executada no Linux com Godot 4.7.2.rc. Os resultados relatados colocam o Box3D Physics à frente do Jolt Physics, Godot Physics e Rapier3D em corpos a 16,66 ms, passo mediano, passo p95, passo de pico e memória nessa carga específica de caixas densas. O README adverte explicitamente que todos os quatro backends ultrapassam o orçamento bem antes de 4096 corpos, que isso mede a degradação sob sobrecarga, e que uma pilha densa de caixas não diz nada sobre raycasts, controladores de personagem ou juntas, então deve ser tomado como ponto de partida e não como ranking. Requisitos: Godot 4.3 ou mais recente (o projeto de teste tem como alvo 4.7). A instalação é via o zip do addon em Releases, copiando addons/godot-box3d/ para o projeto, depois definindo Project Settings → Physics → 3D → Physics Engine como Box3D Physics e reiniciando. O solver usa um worker por núcleo físico por padrão, sobrescrevível via physics/box3d/worker_count. O macOS é descrito como trabalho em andamento: apenas Apple Silicon, não notarizado, não testado além da compilação. Linux e Windows são as plataformas testadas. A compilação usa CMake, com um arquivo de toolchain MinGW-w64 para compilação cruzada de uma DLL do Windows a partir do Linux. Os testes rodam por um script headless que compila a extensão, registra-a, verifica se o backend carregou e executa 19 testes de regressão, saindo com código diferente de zero em caso de falha ou RID do Box3D vazado. Contribuições são bem-vindas. Licenciado sob MIT; o Box3D é MIT, e o projeto se inspira estruturalmente no godot-jolt, também MIT.