Attention: Here be dragons
This is the latest
(unstable) version of this documentation, which may document features
not available in or compatible with released stable versions of Godot.
Checking the stable version of the documentation...
Solucionando problemas de física
Ao trabalhar com um motor de física, você pode encontrar resultados inesperados.
Embora muitos desses problemas possam ser resolvidos por meio de configuração, alguns deles são o resultado de bugs do motor. Para problemas conhecidos relacionados ao motor de física, consulte as questões em aberto relacionadas à física no GitHub. Olhar as questões encerradas também pode ajudar a responder a perguntas relacionadas ao comportamento do motor de física.
Objetos estão atravessando uns aos outros em altas velocidades
Isso é conhecido como tunneling (tunelamento). Ativar o Continuous CD (Detecção de Colisão Contínua) nas propriedades do RigidBody às vezes pode resolver esse problema. Se isso não ajudar, existem outras soluções que você pode tentar:
Torne suas formas de colisão estáticas mais espessas. Por exemplo, se você tiver um chão fino do qual o jogador não pode descer de forma alguma, você pode tornar o colisor mais espesso do que a representação visual do chão.
Modifique a forma de colisão do seu objeto que se move rapidamente dependendo de sua velocidade de movimento. Quanto mais rápido o objeto se move, maior deve ser a forma de colisão estendida para fora do objeto para garantir que ele possa colidir com paredes finas de maneira mais confiável.
Aumente o valor de Physics Ticks per Second nas Configurações de Projeto avançadas. Embora isso traga outros benefícios (como uma simulação mais estável e atraso de entrada reduzido), isso aumenta a utilização da CPU e pode não ser viável para plataformas móveis/web. Múltiplos do valor padrão de
60(como120,180ou240) devem ser preferidos para uma aparência suave na maioria das telas.
Objetos empilhados estão instáveis e balançando
Apesar de parecer um problema simples, a simulação estável de RigidBody com objetos empilhados é difícil de implementar em um motor de física. Isso é causado pela integração de forças que vão umas contra as outras. Quanto mais objetos empilhados estiverem presentes, mais fortes serão as forças contrárias. Isso eventualmente faz com que a simulação balance, tornando os objetos incapazes de repousar uns sobre os outros sem se mover.
Increasing the physics simulation rate can help alleviate this issue. To do so,
increase Physics Ticks per Second
in the advanced Project Settings. Note that doing this
increases CPU utilization and may not be viable for mobile/web platforms.
Multipliers of the default value of 60 (such as 120, 180 or 240)
should be preferred for a smooth appearance on most displays.
Em 3D, mudar o motor de física do padrão GodotPhysics para o Jolt também pode melhorar a estabilidade. Veja Usando Jolt Physics para mais informações.
Corpos físicos ou formas de colisão redimensionados não colidem corretamente
O Godot atualmente não suporta o escalonamento de corpos físicos ou formas de colisão. Como solução alternativa, altere as extensões da forma de colisão em vez de alterar sua escala. Se você quiser que a escala da representação visual também mude, altere a escala da representação visual subjacente (Sprite2D, MeshInstance3D, …) e altere as extensões da forma de colisão separadamente. Certifique-se de que a forma de colisão não seja um nó filho da representação visual neste caso.
Como os recursos são compartilhados por padrão, você terá que tornar o recurso da forma de colisão único se não quiser que a alteração seja aplicada a todos os nós que usam o mesmo recurso de forma de colisão na cena. Isso pode ser feito de duas maneiras:
No editor, clicando em no menu suspenso do recurso CollisionShape no inspetor e, em seguida, alterando seu tamanho.
Em um script, chamando
duplicate()no recurso da forma de colisão antes de alterar seu tamanho.
Objetos finos ficam balançando quando estão apoiados no chão
Isso pode ser devido a uma de duas causas:
A forma de colisão do chão é muito fina.
A forma de colisão do RigidBody é muito fina.
No primeiro caso, isso pode ser aliviado tornando a forma de colisão do chão mais espessa. Por exemplo, se você tiver um chão fino do qual o jogador não pode descer de forma alguma, você pode tornar o colisor mais espesso do que a representação visual do chão.
No segundo caso, isso geralmente só pode ser resolvido aumentando a taxa de simulação de física (já que tornar a forma mais espessa causaria uma desconexão entre a representação visual do RigidBody e sua colisão).
Em ambos os casos, aumentar a taxa de simulação de física também pode ajudar a aliviar esse problema. Para fazer isso, aumente o valor de Physics Ticks per Second nas Configurações de Projeto avançadas. Note que isso aumenta a utilização da CPU e pode não ser viável para plataformas móveis/web. Múltiplos do valor padrão de 60 (como 120, 180 ou 240) devem ser preferidos para uma aparência suave na maioria das telas.
Formas de colisão de cilindro são instáveis
Mudar o mecanismo de física do GodotPhysics padrão para Jolt deve tornar as formas de colisão de cilindro mais confiáveis. Veja Usando Jolt Physics para mais informações.
Durante a transição do Bullet para o GodotPhysics no Godot 4, as formas de colisão de cilindro tiveram que ser reimplementadas do zero. No entanto, as formas de colisão de cilindro são uma das formas mais difíceis de suportar, razão pela qual muitos outros motores de física não oferecem nenhum suporte para elas. Existem vários bugs conhecidos com formas de colisão de cilindro atualmente.
Se você estiver mantendo o GodotPhysics, recomendamos usar formas de colisão de caixa ou cápsula para personagens por enquanto. Caixas geralmente oferecem a melhor confiabilidade, mas têm a desvantagem de fazer o personagem ocupar mais espaço na diagonal. Formas de colisão de cápsula não têm essa desvantagem, mas sua forma pode tornar a plataforma de precisão mais difícil.
A simulação de VehicleBody está instável, especialmente em altas velocidades
Quando um corpo físico se move a uma velocidade alta, ele viaja uma grande distância entre cada etapa de física. Por exemplo, ao usar a convenção de 1 unidade = 1 metro em 3D, um veículo se movendo a 360 km/h viajará 100 unidades por segundo. Com a taxa de simulação de física padrão de 60 Hz, o veículo se move cerca de ~1.67 unidades a cada tique de física. Isso significa que objetos pequenos podem ser totalmente ignorados pelo veículo (devido ao tunelamento), mas também que a simulação tem poucos dados para trabalhar em geral a uma velocidade tão alta.
Veículos que se movem rapidamente podem se beneficiar muito de uma taxa de simulação de física aumentada. Para fazer isso, aumente o valor de Physics Ticks per Second nas Configurações de Projeto avançadas. Note que isso aumenta a utilização da CPU e pode não ser viável para plataformas móveis/web. Múltiplos do valor padrão de 60 (como 120, 180 ou 240) devem ser preferidos para uma aparência suave na maioria das telas.
Resultados de colisão em solavancos quando um objeto se move através de blocos (tiles)
Este é um problema conhecido no motor de física causado pelo objeto colidindo nas bordas de uma forma, mesmo que essa borda esteja coberta por outra forma. Isso pode ocorrer tanto em 2D quanto em 3D.
A melhor maneira de contornar esse problema é criar um colisor 'composto'. Isso significa que, em vez de blocos individuais terem sua colisão, você cria uma única forma de colisão representando a colisão para um grupo de blocos. Normalmente, você deve dividir colisores compostos por ilha (o que significa que cada grupo de blocos tocantes obtém seu próprio colisor).
Usar um colisor composto também pode melhorar o desempenho da simulação de física em certos casos. No entanto, como a forma de colisão composta é muito mais complexa, isso pode não resultar em um ganho líquido de desempenho em todos os casos.
Dica
No Godot 4.5 e versões posteriores, a criação de um colisor composto é feita automaticamente ao usar um nó TileMapLayer. O tamanho do bloco (16 blocos em cada eixo por padrão) pode ser definido usando a propriedade Physics Quadrant Size no inspetor do TileMapLayer. Valores maiores oferecem colisões mais confiáveis, às custas de atualizações mais lentas quando o TileMap é alterado.
Quedas na taxa de quadros quando um objeto toca outro objeto
Isso provavelmente se deve ao fato de um dos objetos usar uma forma de colisão muito complexa. Formas de colisão convexas devem usar um número de formas o menor possível por razões de desempenho. Ao confiar na geração automática do Godot, é possível que você tenha acabado com dezenas, se não centenas, de formas criadas para um único recurso de colisão de forma convexa.
Em alguns casos, substituir um colisor convexo por algumas formas de colisão primitivas (caixa, esfera ou cápsula) pode oferecer um melhor desempenho.
Esse problema também pode ocorrer com StaticBodies que usam colisões trimesh (côncavas) muito detalhadas. Nesse caso, use uma representação simplificada da geometria do nível como um colisor. Isso não apenas melhorará significativamente o desempenho da simulação de física, mas também poderá melhorar a estabilidade, permitindo remover pequenas estruturas e fendas de serem consideradas pela colisão.
Em 3D, mudar o motor de física do padrão GodotPhysics para o Jolt também pode melhorar o desempenho. Veja Usando Jolt Physics para mais informações.
A taxa de quadros cai repentinamente para um valor muito baixo após uma certa quantidade de simulação de física
Isso ocorre porque o mecanismo de física não consegue acompanhar a taxa de simulação esperada. Nesse caso, a taxa de quadros começará a cair, mas o mecanismo só tem permissão para simular um certo número de etapas de física por quadro renderizado. Isso gera uma bola de neve em uma situação onde a taxa de quadros continua caindo até atingir uma taxa muito baixa (geralmente 1-2 FPS) e é chamado de espiral de morte da física (physics spiral of death).
Para evitar isso, você deve verificar situações em seu projeto que possam causar um número excessivo de simulações de física ao mesmo tempo (o com formas de colisão excessivamente complexas). Se essas situações não puderem ser evitadas, você pode aumentar a configuração de projeto Max Physics Steps per Frame e/ou reduzir o valor de Physics Ticks per Second para aliviar isso.
A simulação de física não é confiável quando longe da origem do mundo
Isso é causado por erros de precisão de ponto flutuante, que se tornam mais pronunciados à medida que a simulação de física ocorre mais longe da origem do mundo. Esse problema também afeta a renderização, o que resulta em um movimento trêmulo da câmera quando longe da origem do mundo. Veja Coordenadas de mundo grande para mais informações.