Pacejka et ODE
Après une semaine de boulot, je tiens enfin une implémentation de Pacejka que j’arrive à faire cohabiter avec ODE, le moteur physique utilisé dans Raydium. La dernière fois que j’avais posté ici à ce sujet, plusieurs questions persistaient :
– Plus on presse un pneu sur la route (charge verticale), plus il est efficace (jusqu’à son explosion, en clair). Alors pourquoi lors d’un virage très serré, ce sont toujours les pneus les plus « chargés » qui dérapent ?
– Les équations de Pacejka permettent de calculer la force maximum qu’un pneu est capable de générer/restituer en fonction d’une situation donnée. Comment gérer les écarts entre ce que la situation demande et ce que pneu permet à ce moment là ? De manière générale, comment faire interagir ODE et Pacejka ?
– Comment gérer les instabilités des équations magiques à très basse vitesse ?
J’ai maintenant des réponses claires et des solutions intéressantes à ces problématiques. Je ferais probablement très prochainement un article « très orienté code » pour expliquer tout cela, car je n’ai trouvé aucune documentation, aucun exemple d’intégration de Pacejka avec ODE sur le net.
Pour l’heure, voilà ce que ça donne en images :
Chaque point représente un contact entre le pneu et la route. La voiture est en train de prendre un virage à gauche à grande vitesse, qui va se finir dans le mur puisque nous sommes très manifestement dans un cas de sous-virage sévère. Info importante : la voiture est une propulsion (ouais, des Fiesta à propulsion moteur central, y en a pas eu des tonnes 🙂
Voilà comment lire les informations de debug :
– SR = Slip Ratio, en %. Il s’agit d’un rapport entre la vitesse de la route et la vitesse du pneu, dans le sens longitudinal (vers l’avant du pneu en question, donc). Quand le pneu ne dérape pas (à l’accélération ou au freinage, puisque nous sommes dans le sens longitudinal encore une fois), le rapport est à 0%, et à 100% si le pneu va deux fois plus vite que la route (sérieux dérapage) ou si la route va deux fois fois plus que le pneu (freinage de barbare).
– SA = Slip Angle, en degrés. Angle entre le sens longitudinal du pneu et son « déplacement ». En pleine ligne droite, parfaitement stable, la valeur doit être de 0°. Dès que vous tournez un petit peu vos roues, vous mettez un petit peu de SA, votre pneu se tord et se cisaille, imperceptiblement, ce qui génère la force qui vous fait changer de direction.
Vous trouverez quelques explications supplémentaires dans le précédent article (voir lien plus haut) sur ces deux valeurs qui servent de paramètres d’entrée aux formules magiques de Pacejka, tout comme l’information suivante :
– load = charge verticale du pneu. Pacejka demande une info en kN, elle est ici exprimée dans une unité propre au jeu (l’échelle n’est pas d’une unité = un mètre, pour le dire autrement).
Les infos suivantes sont les sorties des équations de Pacejka :
– fx et fy correspondent aux forces, en Newton, que le pneu est capable de générer en fonction des paramètres au dessus. Assez logiquement, fx s’applique dans le sens longitudinal et fy dans le sens latéral du pneu.
– mu1 et mu2 sont simplement des remises à l’échelle de fx et fy, utilisés pour alimenter les contacts ODE.
Du coup, il est possible de « lire » l’image, de l’interpréter. Si on commence par la charge, on imagine très facilement dans quelle situation est la voiture … les pneus extérieurs (droite, donc, dans ce virage) sont très chargés (à la différence des deux autres, on a donc une vision très claire de la violence du virage.
Du coté du Slip Ratio, tout semble aller bien : les pneus extérieurs ne glissent quasiment pas, l’avant gauche est à moins de 10% … mais le problème est à l’arrière gauche : 90%, ça ressemble à un burn. Et si l’on se souvient que la voiture est une propulsion, c’est probablement que le conducteur est en train d’accélérer. L’autre possibilité serait un freinage, mais seul le frein moteur agit sur les roues arrières de cette voiture, et il n’a pas la force d’engendrer 90% de SR. Un indice confirme cette théorie : si cette roue arrive à patiner alors que l’autre roue arrière semble OK (SR=2%), c’est parce qu’elle n’est que très peu chargée, avec 550 (pseudo) Newton … mais nettement plus que l’autre roue intérieure ! (78 pseudo N) La masse de la voiture semble donc être plutôt à l’arrière, signe d’une accélération.
Enfin, l’interprétation du Slip Angle révèle l’ampleur du problème pour le conducteur à ce moment là : tout va bien à l’arrière, mais à l’avant, on est pas loin des 30° ! C’est plus que l’angle de braquage des roues, ce qui signifie tout simplement que la voiture est en train de faire un tout droit.
Pour ma défense, la voiture est équipée de pneus 135/80/13 … ce sont ceux d’une Fiat Panda de 1982 🙂
J’ai donc passé des heures à tester toutes sortes de situations comme celle çi, pour implémenter et valider le modèle de Pacejka. C’est très instructif, et c’est assez génial de voir fonctionner ces formules. Il reste encore de nombreuses choses à faire autour de ce sujet pour ManiaCrash, en particulier du coté de l’équilibre de la voiture et de tout ce qui concerne la suspension. La barre anti-roulis, notamment, semble être le prochain passage obligé.
Reproduction du son moteur
Histoire de varier les plaisirs, je me suis penché depuis hier sur la problématique de la reproduction du bruit moteur. Pour ManiaCrash, je souhaite m’appliquer au niveau de l’audio, avec un son réaliste pour le moteur, en intérieur et en extérieur, des bruits de roulement, des crissements, du vent, etc. Dans une simulation auto, une grande partie du feeling se fait par la partie audio. Il m’est déjà arrivé dans certains très bon mods rFactor, de lâcher un petit « woaw » craintif en écrasant l’accélérateur d’une voiture à l’arrêt, tellement le son « rendait » bien. Même chose pour la sensation de vitesse : quand on va vite, ça doit trembler de partout et faire plein de bruit. C’est à mon avis l’un des gros échecs de la série Gran Turismo, par exemple, ou la partie audio est finalement très limitée.
Dans ManiaDrive, pour le moteur, j’utilisais un seul son, qui était pitché selon la vitesse de rotation du moteur. Évidement, le son devenait très vite complètement déformé, et je devais limiter le pitch à une plage assez restreinte, et pas du tout réaliste.
Du coup, j’expérimente avec l’utilisation de plusieurs sons pour un seul moteur. C’est la méthode utilisée par beaucoup de jeux et de simus, typiquement avec un son par tranche de 1000 tours par minute. Je cherche une méthode pour mixer le tout et obtenir un résultat aussi réaliste que possible. Pour chaque son, il me faut déterminer un gain et un pitch, et j’utilise à l’heure actuelle une solution qui me semble logique. Si on est à 1200 RPM, que j’ai un son pour 1000 RPM et un autre pour 2000 RPM, le premier est joué avec un gain de 0.8, le second 0.2, et des pitchs de 1.20 et 0.60, respectivement.
Eh bien ça marche pas du tout : http://ftp.cqfd-corp.org/mc_engine1.mp3
Voilà les graphs des valeurs utilisées pendant une accélération. Pour le gain :
… et pour le pitch :
Voilà ou j’en suis pour l’instant. Si vous avez une idée, n’hésitez pas 🙂
Laisser un commentaire
Vous devez vous connecter pour publier un commentaire.