C’est nouveau : soudaine envie de partager les trucs en tête de ma playlist “trucs préférés” en ce moment. Attention, ça s’écoute fort, sinon on gâche.

London Elektricity - Just One Second (Apex)

… trouvé sur le trailer de Polyphony Digital en hommage à la 458 Italia. Je trouve le remix d’Apex un gros cran au dessus de l’original (extrait de l’album Syncopated City), et on le trouve sur une double compile assez sympathique nommée Sick Music (Hospital Records, fondé par les mêmes mecs que London Elektricity). Je suis pourtant pas un énorme fan de drum and bass, mais j’écoute avec plaisir.

Cinnamon Chasers - Luv Deluxe

Débusqué dans les liens en vrac de NoFrag, le clip est super bien fichu, et j’ai fortement accroché au morceau (même s’il m’a fallu un peu de temps pour réellement “entendre” cette piste, tout obnubilé par le clip que j’étais). Paradoxalement, j’ai écouté le reste de l’album (A Million Miles From Home) avant d’imaginer l’acheter, et je suis assez déçu : Luv Deluxe est complètement à part … Blah, ça rend ce morceau encore plus particulier.

Télépopmusik - Breathe

Gros gros classique, et ça date de 2001. Comme beaucoup de monde, j’avais entendu ce morceau des dizaines de fois, sans jamais arriver à mettre la main dessus. C’est chose faite avec l’album Genetic World, qui mélange de l’excellent, du sympa … et des trucs plus étranges. L’album suivant, Angel Milk, propose aussi quelques pistes remarquables, mais tire vers un style très Massive Attack (tendance 100th Window … écoutez Last Train To Forever, c’est aux frontières du plagiat). C’est pas spécialement désagréable, mais ça s’éloigne vachement du “dynamisme” de leur premier album (et c’est justement ce qui me plaisait). Reste que globalement leurs albums offrent une ambiance géniale, ce qui explique probablement pourquoi on voit du Télépopmusik dans tant de pubs, génériques, …

Röyksopp - Happy Up Here

C’est plutôt très connu, puisque ce morceau était le single de leur dernier album, Junior, que je trouve sincèrement assez mauvais (ça sonne très très dance des années 90 par endroits). J’ai décidément vraiment beaucoup de mal à cerner Röyksopp : je trouve ce morceau über-puissant et je suis un ultra-fan de l’album Melody A.M. (absolument rien à jeter là dedans !) mais alors tout le reste … (albums précédents, et Junior) Là pour le coup, je suis un peu navré d’avoir acheté cet album sans l’avoir écouté avant (single fanboy attitude).

Chinese Man Records - I’ve Got That Tune

Rhaaa, grosse tuerie ! L’album tout entier (je n’ai que le volume 1 de The Groove Session) est de cette veine … Trip-hop, emprunté de Jazz, Dub et une pointe de Fonqu’ ™, un délice. Le plus fort là dedans : l’un des membres de Chinese Man, “Leo le bug” a sorti un album solo, Music to wake children up, qui pousse le délire encore plus loin, avec des reprises des beastie boys, de “meunier, tu dors” et un pudding a l’arsenic finalement très digeste … et c’est gratos !

… et enfin et surtout : l’album Team Up ! de Variety Lab.

J’ai acheté ce truc au pif, en début d’année, de rage de ne pas trouver ce que cherchais (un putain d’album de Zero 7 dont je ne connais quasi-rien) et je suis resté bloqué dessus : l’album tourne en boucle depuis. Partout. Tout le temps. Ce machin me donne une pêche indescriptible, ces types ont inventé la cocaïne pour oreilles. L’album est tellement éclectique que j’en suis incapable de décrire son style, une sorte de downtempo hyperactif joué avec des bidules en fer et des gameboy, un truc comme ça, sans compter qu’il y a une bonne dose de second degré, des reprises et des guest de partout. En plus la majorité des morceaux ont trop la classe, et ça pue la fête et les vacances. Faut écouter pour comprendre. Je n’ai trouvé que cette piste sur Youtube, et c’est criminel de limiter l’album à ce morceau. M’enfin ça donne une idée.

Achetez ce truc. Sans déconner.

Mmmphh mphhhh mphh !

Le mec a dû me prendre pour un dingue quand j’ai commencé à le mitrailler.

Désolé …

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 droit : 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 N … mais nettement plus que l’autre roue intérieure ! (78 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 :)

Les Rencontres Mondiales du Logiciel Libres se tenaient à Nantes cette année, du 7 au 11 juillet. Pour ceux qui ne connaitraient pas, les RMLL, c’est l’une des grandes messes du logiciel libre. Par exemple, pour cette édition étaient prévus 300 conférences, données par 200 conférenciers (parmi lesquels ont pouvait croiser un certain Richard Stallman) sur toutes sortes de thèmes : Culture et Art Libre, Internet, Accessibilité, Systèmes et sécurité, ToIP / VoIP, Systèmes embarqués, … et le thème Jeux.

Et c’est pour ce thème que j’ai été convié à animer une courte conférence sur Raydium, le vendredi soir, avec pour objectif de présenter les grandes lignes du projet. Si la journée du samedi est orientée grand public, le public “semaine” est typiquement bien geek, libriste à tendance développeur. C’est bien sûr un cliché, mais on sent clairement qu’on est face à un public technique, et il est possible d’exposer des lignes de code en plein milieu de la conf’ sans que cela n’inquiète personne. J’ai même entendu une vague de soulagement, peut-être même d’excitation (”haaaa !”) dans la salle lorsque j’ai lancé mon éditeur de code en plein milieu de la présentation. Reste que présenter un projet aussi large que Raydium à un public aussi exigeant, en 20 minutes, alors qu’on est habitué à animer des stages de 5 jours, c’est un challenge assez énorme.

N’étant pas certain de pouvoir me libérer, je n’ai eu la confirmation de ma venue qu’une petite semaine avant la conférence, ce qui fait que je ne m’étais pas particulièrement mis la pression avant. Mais là, d’un coup, montée de stress : j’allais devoir présenter (et justifier !) Raydium à mes pairs :)

J’ai alors décidé d’illustrer la conférence par une courte vidéo, pour m’éviter de présenter oralement le projet pendant 10 minutes alors qu’il s’agit essentiellement de choses “visuelles”, ce qui me permettait également de dynamiser la conférence (entendre parler quelqu’un non-stop pendant 20 minutes, ça peut devenir lassant). J’ai passé des heures à trouver/capturer les vidéos nécessaires, des heures à tenter de monter le tout, à trouver des musiques (libres) qui collaient, à rendre le tout, … Sans compter que je suis tombé sur plusieurs bugs dans le moteur (évidement, à tester toutes les démos, toutes les applis, on lève des bugs) dont une effrayante fuite mémoire dans le module PHP.

Du coup, entre la vidéo et les bugfixes, la semaine est passée à toute vitesse, et je n’ai pas eu le temps de préparer la moindre présentation (un “powerpoint”, pour les junkies de MS Office). J’ai couché dans un bête fichier texte l’ensemble de mes réflexions, les points à aborder, et quelques chiffres, puis j’ai décollé en urgence du boulot pour tenter d’arriver à l’heure à polytech.

Le conférencier précédent, que je rêvais de voir aux RMLL, Pierre-Michel Ricordel, auteur de l’excellentissime Rigs of Rods (rappellez-vous !), m’a laissé une salle pleine à craquer, et manifestement enchantée par sa présentation, comme me l’a confirmé Flex, membre de CQFD Corp. qui était en embuscade durant la conférence de Pricorde.

Allez fennec, enchaine !

La conférence s’est super bien passée, avec des auditeurs attentifs et réactifs, ce qui rendait le travail d’animation très simple … sans compter qu’avec un public comme celui des RMLL, il est super facile de glisser des tonnes de clins d’oeil qui font mouche quasiment à chaque fois, ce qui rend l’échange encore plus sympathique. La plus grosse difficulté pour le coup a été de gérer le temps, tâche tout bonnement impossible … La conf’ a d’ailleurs duré 50 minutes au lieu des 20 prévues initialement.

J’ai eu l’occasion d’aborder divers sujets, tels que notre vision des moteurs 3D (sim-pli-ci-té !), les choix techniques (pourquoi le C ? pourquoi PHP pour le scripting ? …), les applications qui utilisaient le moteur (avec vraisemblablement un certain nombre de joueurs de ManiaDrive dans l’assistance). D’ailleurs, de manière générale, j’ai été halluciné de la connaissance que les auditeurs avaient du projet ! Certains semblaient s’être renseignés avant la conférence, d’autres m’ont même parlé de détails du code source qu’ils avaient l’air de très bien connaitre … incroyable, tout bonnement.

Bref, je suis super content, les réactions pendant et après la conférence ont étés très bonnes, des applaudissements, des questions à ne plus pouvoir en quitter la pièce … bref, un énorme coup de boost à la motivation ! Je regrette que nous n’ayons pas eu l’occasion d’enregistrer la conférence, pour les souvenirs et pour certains membres du forums qui habitent loin. Mais qu’importe, on fera mieux à la prochaine ! :)

J’arrête de parler et je vous lâche la “fameuse” vidéo de présentation de Raydium. Elle montre quelques caractéristiques importantes du moteur, puis les applications “phares”, et enfin quelques expérimentations réalisées avec le moteur.

Une version “non compressée par youtube” est dispo à cette adresse.

Et un grand merci à J.F. Rollez pour l’invitation et l’organisation du thème !

Il y quelques semaines, j’avais commencé à exposer ici toute ma naïveté photographique, dans ma grande tentative d’isoler le shot de mes différentes sessions. Je trouve assez intéressante cette double difficulté, qui consiste à essayer d’accorder autant d’importance à la sélection des photos qu’à la prise de vue elle même. Mais c’est aussi un double risque d’avoir des photos qui ne plaisent qu’a moi …

Voilà donc ma sélection pour ces deux derniers mois qui, et c’est un hasard, ne fait apparaître quasiment que des photos en rapport avec la mer, l’eau, la plage, …

1.

2.

3.

4.

5.

6.

7.

8.

9.

10.

11.

12.

Les premières photos de cette sélection viennent de St Malo, les suivantes de beaucoup plus loin, Kuredu. A peine revenu, je crève déjà d’envie d’y retourner à nouveau. Ces destinations sont très dangereuses pour le moral, je ne m’y attendais pas …

Je continue mes recherches sur le développement de la suite de ManiaDrive, et mon attention s’est vite fixée sur la modélisation des pneumatiques, qui représente une importante partie de la physique des véhicules pour ce style de jeux.

L’objectif de cet article est de défricher autant que possible ce domaine, très mal couvert au niveau francophone, et ou les explications sont souvent peu pédagogiques et complètement noyées dans des justifications mathématiques incompréhensible pour le commun des mortels. Il s’agit de la synthèse de quelques semaines de recherches sur ce sujet.

Présent : ManiaDrive

Pour l’instant, ManiaDrive utilise exclusivement ODE pour gérer les contacts roues-sol, à l’aide de coefficients FDS (Force Dependent Slip). L’idée de base est très simple : les contacts FDS glissent plus ou moins en fonction de la force appliquée de manière tangentielle à la surface de contact (la route, pour nous). Ça passe mieux en images, agad’ :

Ça, c’est une voiture (nulle) qui tourne. Ce faisant, elle génère une force vers l’extérieur du virage (la fameuse force centrifuge mais que en fait non pas du tout), en bleu sur l’image. Les pneus “retiennent” la voiture, empêchant cette force de devenir un mouvement, au niveau des surfaces de contact avec la route (contact patch). Pour des raisons de performances, il est possible de simplifier ces surfaces à l’aide de points (un par roue, point de départ des flèches vertes sur l’image).

Un contact FDS va donc glisser proportionnellement à la force bleue, et dans la direction de cette force, tout simplement. Notez que la force appliquée le long de la normal du contact (la “longueur” des flèches vertes) n’est pas du tout prise en compte dans ce calcul.

Plus je tourne fort, plus ça glisse. Si ça glisse, ça tourne moins, donc ça glisse moins (mais si, réfléchissez bien). En d’autres termes, la voiture de ManiaDrive commence à slider quand on tourne un peu fort, jusqu’à atteindre une sorte de seuil, entre virage et dérapage. La même chose s’applique simultanément à la motricité du pneu (sa capacité à “poser la puissance du moteur” sur la route sans déraper) qui se détériore jusqu’à un seuil “naturel” d’équilibre (~85 km/h pour la Clio de ManiaDrive)

Pour arriver à ce résultat, il a été nécessaire de trouver un équilibre assez complexe entre la masse de la voiture (qui engendre la force centrifuge) et le coefficient FDS des pneus. Plus ce coef est élevé, plus ça glisse. A contrario, un coefficient très proche de zéro va engendrer un pneu très adhérant, limite “gluant”.

En pratique, ManiaDrive utilise un coef fixe, empirique, qui est assez faible pour offrir une conduite efficace (du style “pneu slick”) mais suffisamment élevé pour la voiture glisse un minimum dans un virage brusque … à défaut de quoi elle se retournerait ! (ce qui ne manque pas d’arriver quand on pousse la voiture un peu loin dans ses limites. Ex : je braque à fond dans une ligne droite à 160 km/h)

Ça offre une conduite plutôt stable, arcade mais pas trop (il faut “sentir” le comportement des pneus pour maitriser la voiture) et plutôt linéaire. C’est grosso modo le “feeling” que je souhaitais pour le jeu.

Mais pour ManiaCrash, je souhaite aller beaucoup plus loin dans la simulation des pneumatiques.

Modèles de simulation semi-empiriques

C’est là qu’entre en jeu Hans. Hans, c’est un mec cool qui a décidé un jour de chercher une solution pour déterminer toutes les caractéristiques précises d’un pneu de manière mathématique. Alors bien sûr, j’imagine que la seule chose qui vous passe par la tête pour l’instant, c’est de savoir à quel point vous ne souhaiteriez pas tomber sur ce type à table lors d’un repas de famille, mais il n’empêche que la méthode classique pour déterminer ces informations consiste à torturer très longuement des pneus sur des bancs d’essai dédiés, à l’aide de multiples pneus du même modèle, et ça coute super cher. Tout cela est nécessaire dans divers domaines, de la course auto à la conception de systèmes ABS, par exemple.

Et donc le Professeur Hans Bastiaan Pacejka a étudié minutieusement absolument tout ce qui concerne la physique des pneus (déformations, surfaces de contact, cisaillements internes, vibrations, comportement de la gomme, …) pour tenter de modéliser le tout, mathématiquement parlant.

A l’image de ce que les aérodynamiciens ont réussi à faire dans leur domaine, l’idée géniale de Pacejka a été d’utiliser des coefficients non dimensionnels, c’est à dire des grandeurs qui n’ont pas de sens réel mais qui sont des combinaisons/rapports de ces unités réelles (mètre, newton, seconde, …). Il a ainsi développé des formules semi-empiriques, donc sans réelle justification mathématique, mais qui reproduisent la réalité avec succès. Ça lui a demandé plus de 20 ans, tout de même, hein. Soit assez pour couvrir 642 pages d’équations.

Voilà le genre de degré de précision que peut atteindre une telle formule :

Les symboles représentent les mesures réelles effectuées sur un banc de test pour un pneu 195/70R14 et le trait continu représente le résultat de la formule “latérale” (4.E19) de Hans Pacejka. Hallucinant, non ? D’ailleurs, on donne à ses travaux le nom de “magic formula” …

Donc en résumé, pour simuler le comportement d’un pneu de manière particulièrement précise, il faut les formules magiques adéquates, des paramètres d’entrée (force verticale, taux de virage, …) un peu bricolés, et les paramètres non dimensionnels spécifiques au pneu (B’, C’, D’ et E’ ici).

Ces paramètres n’ont pas d’unité particulière (sauf exception), et sont souvent déterminés de manière empirique, à l’aide d’un banc de test. Mais une fois ces paramètres (entre 11 et 15 pour les formules les plus complètes de Pacejka) connus pour un pneu, il est possible de calculer à peu près n’importe quoi sur ce pneu (motricité, adhérence, … et ce en fonction du poids de la voiture, du carrossage, …). Notez que ces valeurs sont très difficile à obtenir, jalousement gardées par les constructeurs de pneus et les entreprises qui ont eu les moyen d’acheter des séances de tests (constructeurs, écuries auto, équipementiers … et même des boites de jeu vidéo, ce qui est finalement assez logique).

Trois équations m’intéressent tout particulièrement dans cet océan de formules :

• force longitudinale, qui travaille en gros dans l’axe de la voiture (”vers l’avant”). On cherche à répondre à la question “On est en plein burn ou pas ?“.
• force latérale, qui s’occupe de faire tourner la voiture et de “contrer l’inertie”.  Problématique : “On est en train de slider ou pas ?“.
• couple d’alignement, pour tout ce qui touche à la “force de centrage” des roues … et donc qui permet d’alimenter le retour de force du volant.

Pour résoudre ces équations, il faut être capable de déterminer principalement deux choses : le slip ratio et le slip angle. J’ai eu du mal à comprendre ces grandeurs, en partie à cause de leur trompeuse ressemblance. Le slip ratio est le plus simple, et est utilisé uniquement pour la première formule, longitudinale. On lit souvent qu’il s’agit du ratio entre la vitesse de rotation actuelle de la roue et sa vitesse de roulement libre, mais je trouve que l’idée de vitesse relative au point de contact avec la route est plus simple :

Roue en rouge, route en vert, point de contact en jaune.

Si les longueurs des deux flèches bleues sont identiques, le slip ratio est de 0. L’autre possibilité, lors d’une accélération, est que la flèche de la roue soit plus longue que celle de la route, ce qui signifie alors que la roue tourne plus que nécessaire et dérape : le ratio augmente. L’inverse peut évidement arriver lors d’un freinage.

En ce qui concerne le slip angle, les choses sont un peu plus compliquées : il s’agit de l’angle entre l’axe de la roue et la direction du mouvement. Attention, il ne s’agit pas de l’angle de braquage des roues, mais bien du léger “pincement” de la surface du pneu en contact avec la route.

Voilà très concrètement à quoi ressemblent des courbes générées depuis ces 3 formules magiques :

Image tirée de l’éditeur de courbes de Pacejka du jeu Racer.

On voit ici la puissance générée par le pneu (axe vertical) en fonction du slip ratio/angle (axe horizontal). Ces courbes s’avèrent particulièrement intéressantes ! Il est possible de commenter plusieurs aspects :

• La zone d’efficacité du pneu à l’accélération ou au freinage (courbe noire) est extrêmement limitée. On a un pic lorsque le slip ratio est de l’ordre de quelques %, et la courbe retombe très vite ensuite.
• Cette même courbe montre à l’inverse que passé une dizaine de %, l’efficacité est certes mauvaise, mais constante. Un gros burn n’est pas spécialement moins efficace qu’un petit.
• Les courbes commencent toutes à zéro ! Pas de slip ratio/angle, pas d’adhérence. C’est assez tordu, mais finalement assez logique. En pratique, il y a toujours toujours un petit peu de “dérapage”, ce qui permet au pneu d’avoir un petit peu d’adhérence … ce qui permet par exemple à un véhicule à l’arrêt de ne pas, tel un aéroglisseur, dévaler la pente sur laquelle il est garé ! Et si je pousse à la main ce véhicule à l’arrêt, le pneu se met à glisser … mais génère du coup de l’adhérence. Tout cela se passe à une micro échelle et est imperceptible, sauf lorsque les efforts impliqués sont énormes. Ça explique également en partie le phénomène d’aquaplaning, ou l’eau forme une fine pellicule qui bouge en même temps que le pneu … plus de slip ratio/angle et donc plus d’adhérence.
• La courbe qui donne la force d’alignement (en vert) peut être directement assimilée à la résistance que l’on va envoyer au volant du joueur. On voit que la courbe retombe à zéro (aucune sensation) dès que le pneu perd son efficacité, ce qui correspond bien au “coup de mou” très sensible que l’on ressent au volant lorsqu’une voiture (traction) part en sous-virage, par exemple. On constate même que la courbe passe au dessus de zéro lorsqu’on abuse vraiment, ce qui signifie que le volant se met à forcer dans le sens du virage lors d’un fort dérapage ! Je ne l’ai personnellement jamais constaté, mais il semble que cet effet existe bien en réalité.

Notez que cette courbe est valable pour une charge verticale donnée, fixe. Il faut compléter le calcul à l’aide de cette information (représentée par des flèches vertes dans la première image). Cette image montre le résultat : plus la charge est importante, plus le pneu est efficace.

(charge en kN sur l’axe de profondeur)

Futur et réflexions : ManiaCrash

J’en suis à un point ou je pense avoir décodé les grandes lignes de ces modèles pneumatiques, et où je dois les implémenter. La difficulté supplémentaire ici est que je souhaite utiliser ODE au maximum. Les quelques projets libres qui font appel à Pecejka dont j’ai lu le code source (TORCS et Racer) ont une approche très différente, n’utilisant un moteur physique que pour la détection de collision, et gérant tout le reste par leurs propres moyens. Contrairement à ces projets, orientés vers la course, ManiaCrash met fortement en avant la notion de cascade, ce qui m’oblige à disposer d’un moteur physique complet. A moi de me débrouiller pour intégrer un modèle pneumatique dans tout ça.

Dans le détail, ça signifie que je dois pouvoir prendre de l’information auprès d’ODE, essentiellement pour calculer le slip angle et le slip ratio. Cela s’avère relativement compliqué, tout particulièrement pour le slip angle à cause des divers repères qui interviennent. Le second point, c’est qu’une fois la formule appliquée, la sortie est une force, et il faut retransmettre ce résultat à ODE lors de la création du contact, et absolument rien n’est prévu pour ça dans ce moteur physique. J’ai actuellement deux pistes : tricher à mort en utilisant toujours des coefficients FDS, variables, à la place des fameuses forces, en suivant la forme des courbes de Pacejka, ce qui n’a aucun sens du point de vue mathématique (mais vraiment hein), mais qui me permet d’imiter très grossièrement les formules magiques en conservant intact le reste de la physique (exemple tout con : ça prend en compte les sols “non-plats”). L’autre piste, c’est d’utiliser les drapeaux dContactMotion d’ODE, qui servent d’habitude à simuler des surfaces mobiles (tapis roulants, typiquement). Ainsi, on pose la voiture sur une sorte de plateforme mobile virtuelle, cette dernière se déplaçant selon les forces calculées. On implémente ainsi complètement le modèle pneumatique de Pacejka, mais les effets de bords sont très nombreux, et le tout demande (beaucoup) plus de code supplémentaire que la première option. Sachant que ManiaCrash ne cherche pas du tout à être une simulation, mais que je souhaite simplement offrir un modèle pneumatique intéressant à jouer, le choix est difficile.

Au rang des complications et incompréhensions :

• Les formules de Pacejka sont là pour calculer une force. elle représente une sorte de maximum (la capacité du pneu), et non la force à appliquer à appliquer pour telle ou telle situation. Comment déterminer cette dernière ? Que faire si elle dépasse celle calculée par les formules magiques ? Je n’ai pas encore réfléchi à tout ça …
• Les forces calculées indépendamment par les deux formules “de motricité” (longitudinale et latérale) peuvent, une fois additionnées, dépasser ce que le pneu est capable de produire. Il faut donc utiliser de nouvelles formules pour combiner ces deux forces, ce qui pose d’autres problèmes (on privilégie une des deux forces ? on fait une moyenne ? …)
• J’ai du mal à comprendre l’effet de charge verticale : “plus on charge, plus le pneu est efficace“, c’est ce qu’on peut déduire de la formule magique. Mais lors d’un virage très serré, on engendre une charge énorme sur les pneus extérieurs, alors pourquoi la voiture partirait en dérapage dans ce genre de conditions ? L’effet des slip ratio/angle dans une telle situation est-il puissant au point d’occulter l’effet de la charge ?
• La vitesse ne semble jamais prise en compte dans les formules ! La puissance générée par un pneu ne varie pas selon la vitesse de ce dernier ?! Il manque un truc pour accepter que ce soit normal …
• Les équations sont très instables à basse vitesse. J’imagine que les arrondis du FPU sont responsables … Mais en attendant, la plupart des implémentations de Pacejka sur lesquelles je suis tombé désactivent les formules sous un certain seuil de vitesse, ou injectent des valeurs empiriques dans les formules pour les stabiliser. A quoi ça sert d’avoir un modèle extrêmement réaliste si c’est pour faire des choses pareilles avec …
• La nature du sol ou les effets de la météo ne sont mentionnés nul part ! C’est bien une attitude de mathématicien que de bosser pendant 20 ans à la rédaction de telles théories et d’oublier que (des fois, certes) il pleut. Les notions de pression et de température ne sont pas très bien couvertes non plus, en tout cas par les principales formules.

Bref, il reste encore beaucoup de choses à creuser et à comprendre. Mais assez de lecture pour l’instant, place à l’expérimentation !

/!\ Big Warning : Je n’ai aucune compétence particulière en mathématique, ni en physique, tout ceci n’est que mon interprétation après lecture d’une toute petite partie d’une littérature qui m’est complétement inconnue à la base, et pour laquelle je n’ai clairement pas le niveau. Dans le meilleur des cas, tout ceci est plein d’approximations honteuses, tant dans la formulation que dans le vocabulaire, au pire il s’agit d’un gros tas d’erreurs. A vous de voir.

J’aime bien prendre des photos. Ça date de mon premier appareil photo, que m’avait offert mon père quand j’avais une douzaine d’années ou un truc comme ça. Je n’ai aucun souvenir de la marque et encore moins du modèle, mais c’était un petit autofocus, avec un gros déclencheur rouge, une molette pour avancer la pellicule entre chaque prise, et un petit levier sous l’appareil pour la rembobiner quand elle était terminée. C’était tout petit, très simple a utiliser, ça rendait des photos sympa, mais vu que ça coutait cher de faire développer les clichés, on m’apprenait qu’il fallait shooter avec une extrême parcimonie. Alors je prenais essentiellement des photos “importantes”, formelles : tout le monde sur un petit muret, un beau paysage derrière, cheeese-crack (oui, il faisait plus “crack” que clic-clac).

J’aimais bien ça, puis on m’a dit à plusieurs reprises que mes photos étaient réussies (à la différence de ma demi-sœur qui cadrait n’importe comment et guillotinait tout le monde, si mes souvenirs sont bons :) et du coup, dans ma naissante quête de reconnaissance, ça à dû me marquer un peu. Puis des fois, je bravais l’interdit, et je tentais une photo “pour le fun”, avec un sujet bizarre ou un cadrage … inventif. Le pied.

Puis rien.

Plus tard (nettement), je me suis acheté l’un des premiers APN grand public, un Olympus C1. J’avais lâché un rein : zoom numérique x2, 1.3 Mpixel (en fait, passé le 800×600 ça devenait flou), 8 Mo de mémoire interne … Et ça mettait 15 plombes pour prendre une photo, c’était hyper galère de cadrer un truc en mouvement, surtout que l’écran s’éteignait lorsqu’on pressait le déclencheur. Mais à l’époque, ça déchirait tout : du numérique les mecs, on pouvait même effacer les photos ratées directement sur l’appareil ! Dans la catégorie “saut générationnel”, à part la 3Dfx, difficile de faire mieux. Des millions de photos délirantes, dans toutes les situations, … des souvenirs pleins mes disques, avec des potes partout dessus.

Puis rien.

Et là, en décembre dernier, grande tarte dans ma petite figure délicate : ma concubine m’offre un truc ultime, un SLR comme dit PositiveFunk, et un balaise, avec deux gros bidules qui se sont révélés être des “objos”. J’avais encore jamais touché un truc pareil de ma vie. La notice fait quelques centaines de pages et est remplie de termes qui m’étaient absolument inconnus. J’ai potassé. Le genre de potassage (m’en fout, je l’invente) dont je sais faire preuve plus ou moins inconsciemment quand un truc manifestement beaucoup trop compliqué pour moi m’intéresse malgré tout. Ça m’a fait pareil pour l’informatique quand j’avais une quinzaine d’années.

Résultat, maintenant, j’en arrive à dire que j’ai acheté un Hoya PL 67 pour mon 70-300 1/4.5 VR. Par contre, contrairement à l’informatique (en toute modestie, hein, on est entre nous), il semblerait que nonobstant mes nouvelles compétences, je reste profondément mauvais. Mon analyse obviouso-personnelle est qu’une approche purement technique ne serait peut être pas la meilleure pour un domaine, disons artistique, comme la photo.

Me voilà donc en train d’essayer de faire de l’art. Donc je poste mes merdes sur WF, logique, y’a du niveau. On pourrait parler d’apprentissage par l’échec en quelque sorte.

Reste que ce qui m’intéresse beaucoup dans cette affaire, c’est d’extraire un truc, une photo, d’un endroit ou d’une session de shoot : c’est l’alternance de ces photos, sorties de leurs contextes que je trouve sympa. J’en arrive à un point ou quand je shoot, j’ai déjà le doigt sur le bouton de suppression de l’appareil, et je vire 90% des prises sur le vif, et encore la moitié quand j’ai 10 secondes pour faire le point sur l’écran de l’appareil. C’est surement pas normal d’effacer autant (ou de prendre autant de mauvaises photos :), mais je cherche pas à me faire des albums souvenir, juste à avoir l’image qui me plait, pour telle ou telle situation. Juste une.

Voilà une nouvelle sympathique pour l’équipe : st, un membre émérite de l’équipe de développement déjà responsable du portage MacOS X de Raydium, travaille depuis quelques semaines un nouveau portage sur iPhone !

J’ai validé son patch il y a quelques minutes, ce qui fait que Raydium est maintenant à deux doigts de disposer d’une quatrième cible officielle (Linux, win32, MacOS X et donc iPhone), le temps de laisser st bosser sur la finalisation du SDK. Le portage est encore incomplet puisqu’il manque toute la partie sonore (OpenAL) et l’API responsable de la lecture des vidéos, que quelques applis crashent encore, sans compter que l’iPhone reste une plateforme très limitée en terme de capacité de rendu 3D et nécessite donc de disposer de modèles 3D et de textures spécifiques, mais il est déjà possible d’imaginer des choses absolument géniales grâce à ce portage.

Voilà la vidéo de st a posté ce week-end pour montrer l’avancée de son travail sur le sujet. Impressionant quand on sait que, Il y a encore quelques jours, rien ne tournait :

ManiaDrive approche les 500 000 téléchargements directs (sans compter les packages présents dans les distributions Linux, donc). Je serais curieux de tenter un portage du jeu sur iPhone, juste pour voir :)

Vision d’artiste, en attendant …

Il y a déjà plus d’un an, je commençais à expérimenter autour d’une nouvelle physique pour les véhicules de ManiaCrash, la probable suite de ManiaDrive. En effet, pour un jeu de caisses, l’essentiel de l’expérience utilisateur (voire du gameplay lui-même) passe par la physique des véhicules, ce qui en fait évidement l’un des éléments les plus travaillés pour cette catégorie de jeux : TrackMania, rFactor, Burnout, … autant de réponses complètement différentes autour d’une problématique pourtant identique : faire cohabiter 4 roues, un volant et la volonté du joueur.

Il existe essentiellement deux grandes orientations distinctes pour simuler le comportement d’un véhicule dans un jeu : se créer ses propres règles arbitraires ou suivre celles imposée par la physique.

La première option est évidement tout à fait adaptée aux conduites orientées arcade. On imagine mal, par exemple, Wipeout faire autrement que de s’inventer une physique complètement farfelue capable de gérer les virages en épingle à 800 km/h que propose le jeu. De la même manière, si vous avez déjà touché à un monument comme Daytona USA, je pense que vous voyez précisément ce que peut être une “physique custom”.

Concrètement, avec ce genre de solutions, on va par exemple remplacer les ensembles suspensions-pneus par un simple lancé de rayon sous la voiture pour déterminer sa position par rapport à la route et la déplacer sur l’axe de la hauteur en conséquence (les roues sont souvent dessinées dans un second temps à partir de ces informations), gérer le déplacement de la voiture sur un plan 2D, sans avoir besoin d’autre chose que de simples fonctions trigonométriques, etc.

A l’opposé, il est possible de se baser sur les règles “réelles” de la physique pour reproduire une comportement nettement plus proche de la réalité, à l’aide de la mécanique des corps rigides, de l’aérodynamique, voire de la pneumatique, de l’électronique, …

Au delà de l’énorme complexité de la simulation elle-même, le problème qui se pose très vite, c’est que créer un véhicule pour le jeu est à peu près aussi exigeant … que créer une véritable voiture ! Depuis la naissance de l’automobile, les constructeurs s’acharnent à inventer toutes sortes de choses pour améliorer le comportement des voitures : meilleur répartition des masses, suspensions Mac-Pherson, barres anti-roulis, évolutions pneumatiques, essieux directionnels, …

Dès lors, si l’on se contente de considérer une voiture dans un jeu comme une grosse boîte uniforme supportée par 4 cylindres, l’inévitable se produit dès les 100 premiers mètres : la voiture oscille violemment avant de se renverser lamentablement tel Richard Hammond dans un Suzuki Carry.

De son coté, pour la voiture, ManiaDrive utilise bien une “dynamique” basée sur un moteur physique (ODE), mais applique toutes sortes d’astuces pour offrir un comportement plutôt sain et assez simple d’accès pour le joueur. Une approche réaliste mais très assouplie, en somme.

L’astuce principale, liée à l’équilibrage général du véhicule (de mon point de vue, la chose la plus difficile à obtenir et de loin !), passe par un balancier invisible, placé nettement sous la voiture :

Ce balancier n’entre évidement pas en compte lors des calculs des collisions. Malgré sa faible taille, son effet est énorme, particulièrement parce qu’il est 4 fois plus dense que le corps de la voiture. Le centre de gravité est ainsi complément rabaissé, et la voiture contre très efficacement les efforts inertiels rencontrés lors des forts virages et les gros freinages, qui sont les situations les plus exigeantes pour l’équilibre de la voiture.

L’autre astuce très importante est liée à la friction des contacts roues-sol, qui se trouve être une constante dans ManiaDrive ! Cela signifie littéralement que “l’efficacité*” des pneus est la même quelle que soit la vitesse, les forces exercées sur le pneu, … Le pneu parfait, donc.

* Attention tout de même, cela ne signifie par pour autant que l’adhérence est constance, c’est un paramètre dépendant des forces appliquées (FDS : Force Dependent Slip).

Pour en revenir à la suite de ManiaDrive 1.x, je suis en train d’établir depuis quelques semaines maintenant une liste des points qui pourraient avoir un intérêt au niveau de la modélisation de la voiture :

• températures (pneus, freins, huile, embrayage, …)
• pression de gonflage des pneus
• contacts pneus-route utilisant un modèle type Pacejka
• différentiels ordinaires (central ? à glissement limité ?)
• courbes de couple / embrayage
• abs / esp / boite auto
• forces aérodynamiques (traînée et appuis)
• barres anti-roulis
• batterie (charge, décharge)
• retour de force (moment d’alignement)
• démarreur / noyade
• résistance tête pilote
• feu ? / buée ? / météo ? / “splashs” ?
• essuie-glace
• clignotants
• casse du par-brise / des rétros

Cette liste peut sembler ambitieuse et faire appel à des points à priori très futiles, mais il ne s’agit en aucun d’une “feature list” figée, mais bien d’un ensemble de directions qui semblent intéressantes à creuser pour ce que je souhaite faire pour ManiaCrash.

Reste que pour l’instant, le résultat, c’est ça :

C’est à dire une véritable savonnette absolument impossible à conduire, capable de partir dans un drift “fast & furious staïle” pendant une simple tentative de créneau. C’est simple, le machin rond en face du conducteur ne sert pas à diriger le véhicule, mais uniquement à émettre plus ou moins de fumée. Plutôt plus, d’ailleurs.

La suite de tout ça (et l’objectif de cette série d’article), c’est d’essayer d’une faire … une véritable voiture. A suivre !

Article un petit peu à part aujourd’hui, puisqu’il s’adresse à un public probablement très restreint : les utilisateurs d’Asterisk.

Lors de l’écriture d’applications vocales, il est généralement nécessaire d’ajouter une musique de fond aux fichiers vocaux et il n’est pas toujours possible/intéressant/élégant de réaliser le mixage dans l’application elle-même. Jusque là, j’utilisais tout bêtement Audacity pour arriver à mes fins, mais la tâche était quand même particulièrement rébarbative et répétitive.

Hier a été la fois de trop, et je me suis donc penché sur le sujet pour voir si il n’existait pas des scripts existants capables d’automatiser la démarche. Un tel script permet de gagner énormément de temps, évidement, mais surtout, il m’ouvre la porte de la délégation. Les utilisateurs pourraient alors directement ajouter la musique de fond lors de l’enregistrement (”Appuyez sur 1 pour ajouter un fond sonore”) ou à postériori dans l’application web

Sauf que je n’ai rien trouvé. Je me suis donc penché un peu plus sur SoX, que j’utilisais déjà pour convertir des fichiers audio vers un format “Asterisk-compliant” (1), et il s’avère que ce logiciel est beaucoup plus sympathique et puissant qu’il n’y parait : il sait mixer, couper, normaliser, fondre, etc. et tout ça avec un syntaxe finalement assez accessible. Une fois qu’on a pigé qu’il faut multiplier les appels consécutifs plutôt que de tout rassembler en une seule commande, il est possible de réaliser a peu près n’importe quel traitement simple sur un fichier audio. L’outil semble solide (pas eu le moindre crash alors que je lui ai donné pas mal d’occasions) et plutôt rapide, pour moi c’est du tout bon !

J’ai donc rédigé un petit script shell capable d’ajouter la fameuse musique de fond à un enregistrement, et le pose ici (2) dans l’espoir que ça serve à quelqu’un d’autre, par la magie des moteurs de recherche. Il permet de choisir la durée de la musique avant et après la voix, de baisser le volume de la musique pendant la lecture de la voix et d’appliquer un fade-out au résultat. C’est basique, mais ça marche et ça fait ce que je veux.

Prière de respecter la license de ces scripts.

Liens :

• (1) http://ftp.cqfd-corp.org/asteriskify.sh
• (2) http://ftp.cqfd-corp.org/sox_add_background.sh