Detección continua de colisiones (CCD): cómo elegir una política frente al tunneling

El intervalo entre muestras

Las comprobaciones de colisión discretas observan determinadas poses de la simulación. Si un objeto rápido atraviesa un obstáculo delgado entre dos observaciones, ninguno de los dos extremos tiene por qué solaparse con él. Este fallo se denomina tunneling. Antes de suponer que aumentar el número de iteraciones del solver corregirá la detección, diagnostica el intervalo de movimiento y la configuración de colisiones.

Dos familias de CCD

La detección continua de colisiones (CCD) considera las colisiones que ocurren entre pasos de tiempo, normalmente con un coste computacional adicional. [1] Los enfoques basados en barrido (sweep) buscan un tiempo de impacto a lo largo del movimiento. Los enfoques especulativos crean contactos preventivos a partir del movimiento predicho; PhysX documenta un comportamiento y unas limitaciones distintos para el movimiento angular en cada uno de estos enfoques. [2] Su cobertura no equivale a la de un shape cast arbitrario.

Ejemplo práctico

Una esfera ilustrativa de radio 0.02 m se mueve a 30 m/s con un paso de tiempo de 0.02 s. Su centro recorre 0.6 m por paso. Una pared de solo 0.05 m de grosor puede quedar por completo entre el volumen inicial y el final de la esfera. Esto establece un caso plausible de contacto no detectado, no un umbral de velocidad universal para activar la CCD.

Coloca la pared a 0.3 m por delante del centro inicial y registra la trayectoria prevista. Prueba una configuración con barrido, una configuración especulativa y pasos de simulación más pequeños, todas con condiciones iniciales idénticas. Comprueba si la esfera se detiene, rebota o pierde parte del movimiento previsto. Después añade una barra giratoria: probar únicamente esferas que se trasladan dejaría sin examinar la cobertura angular.

Flujo de trabajo de implementación

Clasifica los objetos según su consecuencia en el juego: un proyectil que causa daño, un vehículo y unos escombros inofensivos no tienen por qué compartir la misma política. Confirma en la versión real del motor las formas compatibles, los modos de cuerpo, los filtros de pares de colisión y los ajustes a nivel de escena. Decide si los impactos de proyectiles los gestiona la respuesta física de colisión o un barrido explícito de gameplay; de lo contrario, ambos podrían aplicar daño.

Mide el trabajo de colisión durante movimientos rápidos agrupados, no solo con un proyectil aislado. Registra los impactos no detectados, los contactos tempranos inesperados, el coste de la simulación y los impactos repetidos dentro de un mismo paso. Usa la misma escala de escena y las mismas dimensiones de objeto que el contenido de producción. Conserva un caso reproducible por cada cambio de configuración.

Límites y comportamiento de respaldo

Añadir subpasos reduce el recorrido por muestra, pero cuesta más trabajo y no establece garantías universales de colisión. Los métodos de barrido dependen del movimiento que modelan; los métodos especulativos pueden introducir contactos que no llegarían a ser impactos reales. También importan los presupuestos finitos de procesamiento. [2]

Define de forma explícita el comportamiento de respaldo aceptable: detenerse en el primer impacto, continuar durante un número limitado de rebotes o usar una consulta de trayectoria específica del gameplay. Prueba por separado la geometría delgada, los objetivos en movimiento, la rotación y los cambios bruscos de velocidad. La elección de la CCD forma parte del diseño del movimiento; no es simplemente un interruptor global de calidad.

Fuentes

[1] Continuous collision detection — documentación de Unity.

[2] Advanced collision detection — documentación de NVIDIA PhysX.