En juegos de carreras en 3D muy simples, ¿cómo se manejan las colisiones?

Me preguntaba cómo se hacen las colisiones en algunos juegos simples de carreras de autos en 3D (especialmente en juegos como Outrun 2 / Motoracer).

En los juegos de carreras de autos clásicos con un entorno complejo (mundo abierto), supongo que esto se hace con una caja básica (para el automóvil) para colisionar en un avión (para pista, edificios y otras cosas). Todo se optimizaría utilizando algunos cuadros delimitadores (esta es la forma en que se realiza la colisión en muchos juegos).

En un juego como Outrun 2 / Motoracer, el juego es tan simple que los desarrolladores tal vez no lo necesiten y todo podría haberse simplificado mucho. Para aquellos que nunca lo juegan, esto es lo que es tan específico:

• El automóvil / bicicleta siempre está pegado en la carretera.
• El camino es siempre del mismo tamaño y tiene una forma muy simple.
• Las únicas posibilidades son seguir ese camino, no es posible salir del camino o chocar con otra cosa (excepto otros automóviles / bicicletas, pero no nos importa).
• Cuando chocas con la carretera, se realiza una colisión arcade muy básica (el automóvil simplemente se aleja de ella)

Así es como creo que se pudo haber hecho la colisión:

Toda la pista podría considerarse como una curva bezier 3d gigante. A partir de esa curva, se podrían generar los polígonos de la carretera (utilizando vectores frontales, izquierdos y superiores generados a partir de la curva). Otros elementos (como casas, árboles, ...) también se pueden colocar y alinear utilizando este método.

Luego, para manejar las colisiones (y dibujar el auto):

1) Encuentre la posición más cercana en la curva 3d desde la posición 3d actual del automóvil. En otras palabras, transforme la posición del automóvil 3d en una posición de curva bezier. Cada posición 3d en la carretera podría considerarse como un desplazamiento a lo largo de la curva 3d ( t) + desplazamiento lateral ( d). Verifique la imagen a continuación si no está clara (este es un ejemplo 2d, pero esto se aplica fácilmente a 3d).

cuando t = 0 auto está al comienzo de la sección de la pista, cuando t = 1 auto está al final. cuando d = -1 o 1 automóvil está en el borde de la vía, cuando d = 0 el automóvil está en el medio de la carretera

2) alinee el automóvil con la carretera usando ty d(muy simple: para cualquiera ty dvalores puedo obtener una posición 3d + vectores arriba / adelante / izquierda). el auto ahora está pegado en la carretera

3) verifique el desplazamiento lateral ddel automóvil. si el valor es demasiado grande (d > 1)o el (d < -1)auto bajo está fuera de pista. simplemente sujételo para colocar el auto en el lugar correcto.

Esto también hace que el sacrificio en 3D sea muy simple, solo dibuja la pista desde la tposición actual del automóvil hasta t + some_big_enough_value_to_avoid_visible_clipping.

O tal vez estoy completamente equivocado: hubiera sido mucho más rápido y sencillo verificar la colisión del automóvil (un cuadro delimitador) y un conjunto muy simplificado de polígonos que representan la pista (sin los edificios y demás). El mundo 3D (y el modelo de colisión resultante) simplemente se habría generado antes, utilizando alguna herramienta de terceros (no más curva 3D al ejecutar el juego, solo un montón de polígonos).

He trabajado en algunos juegos comerciales similares a los que usted describe.

En cada uno de esos juegos, en realidad teníamos polígonos que creaban un "muro" invisible a lo largo de los lados de la pista, e hicimos pruebas de colisión tradicionales contra esos muros. Esto significaba que podríamos tener algunos riesgos colisionables adicionales al costado del camino, dentro de los muros invisibles, y también permitirnos variar el ancho del camino más rápido de lo normal con un enfoque de spline.

Pero dicho esto, también hicimos lo que enumeras en la sección de cómo creo que funcionaría la colisión para protegerte contra túneles de colisión / fallas, y este sistema también se usó mucho para competir con la lógica de IA. También lo usamos para determinar qué automóviles estaban a la cabeza, para que pudiéramos mostrar un indicador de "1 ° / 2 ° / 3 ° / etc." en el HUD. A veces, estos datos también se usaron para reaparecer un automóvil después de un accidente importante.

Una cosa que te perdiste en cómo creo que funcionaría la colisión es que cuando trabajas con estrías como esta, normalmente le darás costillas a las estrías. Las costillas son bits de datos que expresan qué tan lejos se extiende la pista hacia los lados en cada dirección desde la spline. Entonces, para una estría de 100 metros de largo, es posible que tenga 50 costillas, lo que le da al ancho de la pista cada dos metros a lo largo de su longitud. Esto permite que su pista cambie anchos a lo largo de su extensión. En los juegos en los que he trabajado, estas costillas también han distinguido entre "superficie de la pista" y "área manejable". Por lo tanto, tendría un conjunto de anchos de carretera que indica qué tan lejos del medio de la ranura tiene un buen asfalto, y luego otro ancho que indica qué tan lejos va la arena / hierba / lo que sea que esté fuera de eso. Eso nos permitió tener jugadores capaces de conducir una distancia razonable fuera de la pista, pero aún así la IA sabe dónde estaba la superficie real de la carretera.

Muchos juegos en los que he trabajado también han almacenado otros datos en las costillas; un juego horneó información de iluminación de pista en las costillas, para calcular fácilmente si un área estaba en sombra o no (que luego se usó para renderizar automóviles, decidir si dibujar o no un destello de lente y otros efectos). Otro proporcionó información sobre qué ubicaciones de cámara cinematográfica podían ver esa parte de la ranura, por lo que no tuvimos que hacer cálculos de línea de visión durante las repeticiones. Otro más incluía información sobre cuántos carriles había en la ranura, en qué dirección iban y el desplazamiento horizontal donde se ubicaba cada carril. Esto nos permitió incluir autos de tránsito que podrían conducir correctamente dentro de los carriles de la carretera. Las costillas son fantásticas para almacenar cualquier tipo de información variable que pueda necesitar sobre la superficie de su carretera.

Las costillas generalmente se almacenan en una matriz asociada con la spline. Por razones de velocidad, una implementación normal tendrá costillas espaciadas uniformemente, por lo que una vez que sepa la distancia de un objeto a lo largo de la spline, puede calcular el índice de costilla más cercano en la matriz dividiendo la distancia a lo largo de la spline por la distancia entre las costillas. De lo contrario, está atrapado haciendo búsquedas binarias a través de su matriz de costillas para encontrar los datos correctos de ancho de carretera.

Su descripción de eliminación ofrece una buena descripción básica de cómo se puede usar el enfoque de spline, pero en realidad es un poco más complicado de lo que sugiere: si usa splines para eliminar de esta manera, las curvas largas no suelen dibujar el lado opuesto del giro, ya que cuando se mide por la distancia a lo largo de la pista, el lado opuesto del giro puede estar muy lejos, incluso si está a solo unos metros de distancia cuando se mide cuando el cuervo vuela. Además, las distancias a las que se puede ver la geometría del mundo suelen ser diferentes a las de la malla de la pista, por lo que tampoco encajan en este sistema. Mi experiencia es que, en la mayoría de los casos, es mejor no confiar en la lógica de seguimiento de pistas para determinar si se debe dibujar un modelo; es mucho más confiable y causa menos fallas en el uso de pruebas estándar de cámara frustum para eso.

En mi OpenGL racer, originalmente comencé usando dos círculos para definir los bordes de la pista, pero parecía demasiado complicado. Solo uso glReadPixel para leer el color del píxel. Si el auto del jugador está sobre un píxel verde (color hierba), entonces el movimiento está más limitado. Hay muy poco efecto en el rendimiento.