Dans les jeux de course 3D très simples, comment les collisions sont-elles gérées?

Je me demandais comment se produisent les collisions dans certains jeux de course de voitures 3D simples (en particulier dans des jeux comme Outrun 2 / Motoracer).

Dans les jeux de course de voitures classiques avec un environnement complexe (monde ouvert), je suppose que cela se fait avec une boîte de base (pour la voiture) pour une collision d'avion (pour la piste, les bâtiments, etc.). Le tout serait optimisé en utilisant des boîtes englobantes (c'est ainsi que la collision se fait dans de nombreux jeux).

Dans un jeu comme Outrun 2 / Motoracer, le gameplay est si simple que les développeurs n'en ont peut-être pas besoin et tout aurait pu être simplifié beaucoup. Pour ceux qui n'y jouent jamais, voici ce qui est si spécifique:

• La voiture / vélo est toujours collée sur la route.
• La route est toujours de la même taille et a une forme très simple.
• La seule possibilité est de suivre cette route, il n'est pas possible de quitter la route ou d'entrer en collision avec autre chose (sauf les autres voitures / motos mais on s'en fout).
• Lorsque vous entrez en collision avec la route, une collision d'arcade très basique est effectuée (la voiture est simplement repoussée)

Voici comment je pense que la collision aurait pu se produire:

La piste entière pourrait être considérée comme une courbe de Bézier géante en 3D. À partir de cette courbe, les polygones de route pourraient être générés (en utilisant des vecteurs avant, gauche et haut générés à partir de la courbe). D'autres éléments (comme les maisons, les arbres, ...) pourraient également être placés et alignés en utilisant cette méthode.

Ensuite, pour gérer les collisions (et dessiner la voiture):

1) Trouvez la position la plus proche sur la courbe 3D à partir de la position 3D actuelle de la voiture. En d'autres termes, transformez la position de la voiture 3D en position de courbe de Bézier. Chaque position 3D sur la route peut être considérée comme un déplacement le long d'une courbe 3D ( t) + déplacement latéral ( d). Vérifiez l'image ci-dessous si elle n'est pas claire (il s'agit d'un exemple 2D mais cela s'applique facilement à la 3D).

lorsque t = 0 voiture est au début de la section de piste, lorsque t = 1 voiture est à la fin. lorsque d = -1 ou 1 voiture est au bord de la voie, lorsque d = 0 voiture est au milieu de la route

2) aligner la voiture sur la route en utilisant tet d(très simple: pour toutes les valeurs tet dje peux obtenir une position 3D + vecteurs haut / avant / gauche). la voiture est maintenant collée sur la route

3) vérifier le déplacement latéral dde la voiture. si la valeur est trop grande (d > 1)ou trop basse, la (d < -1)voiture est hors de piste. il suffit de l'attacher pour mettre la voiture au bon endroit.

Cela rend également l'abattage 3D très simple, il suffit de dessiner la piste de la tposition actuelle de la voiture à t + some_big_enough_value_to_avoid_visible_clipping.

Ou peut-être que je me trompe complètement: il aurait été beaucoup plus rapide et plus simple de simplement vérifier la collision de la voiture (un cadre de délimitation) et un ensemble très simplifié de polygones qui représentent la piste (sans les bâtiments et autres). Le monde 3D (et le modèle de colision résultant) aurait simplement été généré auparavant, à l'aide d'un outil tiers (plus de courbe 3D lors de l'exécution du jeu, juste un tas de polygones).

J'ai travaillé sur quelques jeux commerciaux similaires à ceux que vous décrivez.

Dans chacun de ces jeux, nous avions en fait des polygones créant un "mur" invisible le long des côtés de la piste, et nous avons effectué des tests de collision traditionnels contre ces murs. Cela signifiait que nous pouvions avoir des risques de collision supplémentaires sur le côté de la route, à l'intérieur des murs invisibles, et nous permettre également de varier la largeur de la route plus rapidement que vous ne pouvez normalement avec une approche spline.

Mais cela dit, nous avons également fait ce que vous énumérez dans la section comment je pense que la collision fonctionnerait afin de se prémunir contre les tunnels / pépins de collision, et ce système a également été largement utilisé pour la logique de l'IA de course. Nous l'avons également utilisé pour déterminer quelles voitures étaient en tête, afin d'afficher un indicateur "1er / 2e / 3e / etc" sur le HUD. Parfois, ces données ont également été utilisées pour réapparaître une voiture après un accident majeur.

Un élément que vous avez manqué dans la façon dont je pense que la collision fonctionnerait est que lorsque vous travaillez avec des splines comme celle-ci, vous donnerez normalement des nervures aux splines. Les nervures sont des bits de données exprimant dans quelle mesure la piste s'étend latéralement dans chaque direction à partir de la spline. Donc, pour une spline de 100 mètres de long, vous pourriez avoir 50 nervures, donnant la largeur de la piste tous les deux mètres le long de sa longueur. Cela permet à votre piste de changer de largeur le long de son étendue. Dans les jeux sur lesquels j'ai travaillé, ces nervures ont également fait la distinction entre la "surface de la piste" et la "zone pilotable". Donc, vous auriez un ensemble de largeurs de route indiquant à quelle distance du milieu de la spline vous avez un beau tarmac, puis une autre largeur indiquant à quelle distance le sable / l'herbe / tout ce qui va en dehors de cela. Cela nous a permis d'avoir des joueurs capables de parcourir une distance raisonnable hors de la piste, mais tout de même que l'IA sache où se trouvait la vraie surface de la route.

De nombreux jeux sur lesquels j'ai travaillé ont également stocké d'autres données dans les côtes; un jeu a cuit des informations d'éclairage de piste dans les nervures, pour calculer facilement si une zone était dans l'ombre (qui a ensuite été utilisée pour le rendu de la voiture, pour décider de dessiner ou non une lumière parasite et d'autres effets). Un autre a fourni des informations sur les emplacements des caméras cinématographiques qui pouvaient voir cette partie de la spline, nous n'avons donc pas eu à faire de calculs de ligne de visée pendant les relectures. Un autre encore comprenait des informations sur le nombre de voies sur la cannelure, la direction dans laquelle elles se dirigeaient et le déplacement horizontal où chaque voie était située. Cela nous a permis d'inclure des voitures de circulation pouvant rouler correctement dans les voies de circulation. Les nervures sont fantastiques pour stocker toutes sortes de données variables dont vous pourriez avoir besoin sur la surface de votre route.

Les nervures sont généralement stockées dans un tableau associé à la spline. Pour des raisons de vitesse, une implémentation normale aura des nervures régulièrement espacées, donc une fois que vous connaissez la distance d'un objet le long de la spline, vous pouvez calculer l'indice de nervure le plus proche dans le tableau en divisant la distance le long de la spline par la distance entre les nervures. Sinon, vous êtes coincé à faire des recherches binaires dans votre tableau de côtes pour trouver les données de largeur de route correctes.

Votre description de l'abattage donne une bonne description de base de la façon dont l'approche spline peut être utilisée, mais c'est en fait un peu plus compliqué que vous ne le suggérez - si vous utilisez des splines pour l'abattage de cette manière, les longs virages en épingle à cheveux ne dessinent pas souvent le côté opposé du virage, car mesuré par la distance le long de la piste, le côté opposé du virage peut être très éloigné, même s'il n'est qu'à quelques mètres de distance à vol d'oiseau. De plus, les distances auxquelles la géométrie du monde peut être vue sont généralement différentes de celles auxquelles le maillage de la piste peut être vu, de sorte que celles-ci ne rentrent pas vraiment dans ce système. D'après mon expérience, dans la plupart des cas, il vaut mieux ne pas s'appuyer sur une logique de suivi de piste pour déterminer si un modèle doit être dessiné; il est beaucoup plus fiable et provoque moins de problèmes pour utiliser le test de tronc de caméra standard pour cela.

Dans mon coureur OpenGL, j'ai commencé par utiliser deux cercles pour définir les bordures de la piste, mais cela me semblait trop compliqué. J'utilise juste glReadPixel pour lire la couleur des pixels. Si la voiture du joueur dépasse un pixel vert (couleur herbe), le mouvement est encore plus limité. Il y a très peu d'effet sur les performances.