Como os mecanismos evitam o "Phase Lock" (vários objetos no mesmo local) em um Physics Engine?


8

Deixe-me explicar primeiro o bloqueio de fase: quando dois objetos de massa diferente de zero ocupam o mesmo espaço, mas possuem energia zero (sem velocidade).

Eles batem para sempre com vetores de resolução de velocidade zero ou apenas ficam presos juntos até que uma força externa interaja?

No meu motor feito em casa, percebi que se eu carregasse um personagem em uma árvore e os movesse, eles sinalizariam uma colisão e voltariam ao seu local original. Suponho que eu poderia consertar isso implementando impulsos no caso de uma colisão, em vez de voltar ao último ponto em que estava (minha implementação meio que é uma porcaria).

Mas, embora eu torne meu mecanismo mais robusto, estou curioso para saber como a maioria dos outros mecanismos de física lida com esse caso. Os objetos que começam no mesmo local, sem velocidade de movimento, disparam um do outro em uma direção aleatória? Ou eles ficam lá até que algo aconteça? Qual opção geralmente é a melhor abordagem?


3
Não posso falar com uma implementação real (portanto, um comentário em vez de uma resposta), mas, na minha experiência, os mecanismos de física normalmente afastam lentamente os dois objetos um do outro. Por exemplo, se duas caixas surgissem sobrepostas, elas se afastariam lentamente até se separarem completamente. Exatamente como isso seria implementado está em consideração.
Kevintodisco

Sim, eu percebo que essa é uma pergunta um tanto estranha, já que ela está perguntando não muito sobre como implementá-la, mas mais ainda sobre como ela é normalmente tratada. Obrigado pela sua contribuição!
C0M37

Respostas:


4

Eu acho que esse tipo de coisa acaba sendo uma não resposta ...

Acho que, às vezes, depende da implementação e da abordagem básica usada para detecção e resolução de colisões (que é como 80% de um mecanismo de física de corpo rígido, eu acho). É engraçado porque acabei de encontrar esse problema outro dia no meu próprio mecanismo de física e joguei um objeto no espaço NaN.

Eu tinha um objeto desova exatamente no mesmo local que outro objeto e ambos tinham a mesma forma. Nesse caso em particular, o gerador de contatos produziu valores muito ruins. Corrigi-o escolhendo valores arbitrários para o contato (empurre objetos menores / mais leves, basicamente). Este foi um belo corte e seco, no entanto.

Se uma cadeira aparecer dentro de uma mesa, isso dependerá de quais contatos serão gerados, se eles se separarem ou ficarem presos. No meu caso, não estou usando um sistema baseado em restrições (pelo menos ainda não), para que o objeto tenha a mesma probabilidade de se desfazer do que oscilar e adormecer. Em um sistema de penetração + impulso como o que eu uso, é muito fácil ver todo o feio e como ele resultará. Não tenho idéia de como um sistema baseado em restrições resolve esse problema ou se ele o detecta ... a restrição parece inacessível para mim sem alguma intervenção e não tenho idéia se existe uma maneira padrão para esses tipos de motores.

Outros certamente terão coisas mais inteligentes a dizer, mas isso foi muito longo para um comentário.


Agradeço sua resposta. Senti vontade de fazer essa pergunta como uma espécie de bote salva-vidas para os outros encontrarem, caso eles sejam pegos na mesma situação.
C0M37

Lol @PSpeed ​​por aqui também ^^
SHiRKiT

0

Isso é tratado de duas maneiras:

  1. Corrija a sobreposição entre objetos colidíveis
  2. gerar uma força "normal" que afastará os objetos, caso colidam.

Isso só funciona, no entanto, se você estiver diferenciando velocidade / tempo. Ele não funcionará em um jogo baseado em blocos e resultará em artefatos visíveis, como um objeto, que faz um túnel através de um objeto ou é visivelmente empurrado para fora do outro objeto.

No caso de jogos baseados em blocos, você pode adotar uma abordagem preditiva, verificando onde o objeto estará se ele se mover. Se o movimento causar bloqueio de fase, desaproveite o movimento.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.