¿Cómo evitan los motores el "bloqueo de fase" (múltiples objetos en la misma ubicación) en un motor de física?


8

Permítanme explicar primero el bloqueo de fase: cuando dos objetos de masa distinta de cero ocupan el mismo espacio pero tienen energía cero (sin velocidad).

¿Chocan para siempre con vectores de resolución de velocidad cero o simplemente permanecen unidos hasta que una fuerza externa interactúa?

En mi motor preparado en casa, me di cuenta de que si cargaba un personaje en un árbol y lo movía, señalarían una colisión y volverían a su lugar original. Supongo que podría solucionar esto implementando impulsos en caso de una colisión en lugar de simplemente regresar al último lugar en el que estaba (mi implementación apesta).

Pero si bien hago que mi motor sea más robusto, solo tengo curiosidad por saber cómo la mayoría de los otros motores de física manejan este caso. ¿Los objetos que comienzan en el mismo lugar sin velocidad de movimiento simplemente se disparan entre sí en una dirección aleatoria? ¿O se sientan allí hasta que sucede algo? ¿Qué opción es generalmente el mejor enfoque?


3
No puedo hablar con una implementación real (de ahí un comentario en lugar de una respuesta), pero en mi experiencia, los motores de física típicamente empujarán lentamente los dos objetos el uno del otro. Por ejemplo, si se generan dos cajas superpuestas entre sí, se alejarían lentamente una de la otra hasta que se separen por completo. Exactamente cómo se implementaría esto está en consideración.
kevintodisco

Sí, me doy cuenta de que esta es una pregunta extraña, ya que no se trata tanto de cómo implementarla, sino más bien de cómo se maneja normalmente. ¡Gracias por tu contribución!
C0M37

Respuestas:


4

Supongo que este tipo de no termina siendo una respuesta ...

Creo que a veces depende de la implementación y el enfoque básico utilizado para la detección y resolución de colisiones (supongo que es como el 80% de un motor de física de cuerpo rígido). Es divertido porque acabo de resolver este problema el otro día en mi propio motor de física y arrojé un objeto al espacio NaN.

Tenía un objeto generado exactamente en el mismo lugar que otro objeto y ambos tenían la misma forma. En este caso particular, el generador de contactos hizo valores muy malos. Lo arreglé eligiendo valores arbitrarios para el contacto (empujar el objeto más pequeño / más ligero hacia arriba, básicamente). Sin embargo, este fue un caso bastante cortado y seco.

Si una silla apareciera dentro de una mesa, entonces dependería de qué contactos se generaron si se separaron o se atascaron. En mi caso, no estoy usando un sistema basado en restricciones (al menos todavía), por lo que es probable que el objeto se rompa como si oscilara y se durmiera. En un sistema de penetración + impulso como el que uso, es bastante fácil ver todo lo feo y cómo resultará. No tengo idea de cómo un sistema basado en restricciones resuelve este problema o si incluso lo detecta ... la restricción me parece inalcanzable sin alguna intervención y no tengo idea de si hay una forma estándar para ese tipo de motores.

Otros seguramente tendrán cosas más inteligentes que decir, pero esto fue demasiado largo para un comentario.


Agradezco tu respuesta. Tenía ganas de hacer esta pregunta como una especie de balsa salvavidas para que otros la encuentren si alguna vez se ven atrapados en la misma situación.
C0M37

Lol @PSpeed ​​por aquí también ^^
SHiRKiT

0

Esto se maneja de dos maneras:

  1. Corrija la superposición entre objetos colisionables
  2. generar una fuerza "normal" que separará los objetos, en caso de que colisionen.

Sin embargo, esto solo funciona si está diferenciando velocidad / tiempo. No funcionará en un juego basado en fichas, y dará como resultado artefactos visibles, como un objeto, ya sea haciendo un túnel a través de un objeto o siendo expulsado visiblemente del otro objeto.

En el caso de los juegos basados ​​en mosaicos, puede adoptar un enfoque predictivo, verificando dónde estará el objeto si se mueve. Si el movimiento causara bloqueo de fase, entonces no permita el movimiento.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.