Le blog à fennec (le blog de Xfennec)

rFactor 2 beta - Alors ?

Mercredi 18 janvier 2012 à 11:57

La suite très attendue de rFactor pointe le bout de son nez sous la forme d’une beta relativement complète (mais payante [oui, c'est un scandale]) sortie il y a maintenant une semaine.

J’ai eu l’occasion de tester rapidement le jeu ce week-end pendant quelques heures et de résumer mes impressions en vidéo.

Le but n’est clairement pas de réaliser un test exhaustif, mais plutôt de s’intéresser à un point qui m’intéresse beaucoup dans un simulateur auto : le ressenti.

YouTube Preview Image

(si vous avez la chance de disposer d’assez de débit vers Youtube [que vous n'êtes pas chez Free en résumé]) préférez le plein écran en 720p)

Raydium et la 3D sur iPhone

Mercredi 24 novembre 2010 à 0:25

Au mois de mars de l’année dernière, un des membres émérites de l’équipe, st, le responsable du port MacOSX du projet, s’était lancé dans un projet particulièrement risqué : le portage de Raydium sur iPhone.

Même si le moteur a toujours eu comme objectif de fournir une bonne portabilité, cette plateforme reste particulièrement limitée et est basée sur des chips graphiques (PowerVR MBX et SGX) très différents de ce que l’on trouve sur les plateformes habituelles, ou l’on se contente du combo AMD/Nvidia. D’ailleurs, le simple fait d’utiliser la version “embarquée” d’OpenGL, OpenGL ES, pose déjà un certain nombre de problèmes assez profonds, étant donné certains choix effectuées dans Raydium.

Malgré ces contraintes, la révision 829 (et quelques patchs supplémentaires) est arrivée et nous a montré qu’il était possible de faire tourner quelques applications Raydium sur un iPhone. Le travail fourni par st est impressionnant, puisque le moteur touche à beaucoup de sujets différents : l’affichage, bien sûr, mais également toute la partie sonore, les entrées utilisateurs (forcément très différentes sur iPhone),  la physique, etc.

Cependant, cette étape ne représentait que le début du projet, en cherchant à porter plus ou moins par force brute le moteur. Aucune optimisation ou adaptation n’avait été effectuée pour l’instant.

Très récemment, j’ai eu à travailler sur des projets qui impliquaient des chips supportant OpenGL ES (MBX/SGX, Mali 55/100/200, ATi Imageon, …) pour une utilisation dans des STB (”box”), du genre Freebox, Neufbox, BBox, +Le Cube, etc. (pour ne pas citer explicitement les clients concernés dans cette liste). La 3D arrive dans ces équipements, la demande est très forte ces derniers mois.

Etant donné que nous n’avons pas actuellement accès à des prototypes de ces STB, j’ai eu à trouver une plateforme qui s’en rapprochait le plus possible du point de vue graphique pour pouvoir faire nos tests dans des conditions les plus réalistes possibles. Les candidats étaient des choses comme des téléphones Android, iPhone/iPad/iPod touch, BlackBerry Storm 2/Curve 8530, Nokia N900 et même la console Pandora.

C’est sur l’iPhone que le choix a été arrêté, pour différentes raisons inintéressantes ici. Cela a d’ailleurs été l’occasion pour moi de bosser réellement sur un Mac (un Macbook, en l’occurrence), et, en tant que développeur en tout cas, ce fut une expérience particulièrement traumatisante : autant le matériel que l’OS m’ont semblé absolument anti-ergonomiques … J’aurais peut-être l’occasion de faire un article qui me permettra d’exposer ma longue liste de critiques à l’encontre de cette machine, histoire qu’on m’explique comment on est supposé bosser convenablement avec tout ça. Enfin bref, j’ai très vite été obligé de me faire aider de SSH pour mettre fin à mon calvaire, et utiliser le Mac comme un vulgaire compilateur (à 1000 euros [mais avec une super autonomie]).

Pour revenir au sujet initial, après quelques contorsions pour se faire à l’Objective C, à Cocoa et autres étrangetés (pas forcément désagréables), j’étais à même de pondre des applis 3D pas complètement dégueus sur iPhone. Il eu été dommage de ne pas mettre à profit ce matériel et ces nouvelles compétences pour jeter un oeil au portage de Raydium effectué l’année dernière et tenter de le pousser un peu plus en avant.

J’ai donc eu l’occasion de bosser sur le support du “Retina Screen” de l’iPhone 4G (du 960×640 avec plein de DPI, en gros), les mipmaps, les problèmes causés par le mode “paysage” de l’iPhone, une lecture plus fluide des infos des capteurs d’orientation, une simplification de la physique (trop lourde par défaut pour le CPU du téléphone), les ombres, le multitexturing, une émulation (nulle pour l’instant) du joystick, la couche réseau, et surtout, un nouveau renderer qui exploite les particularités d’OpenGL ES et des GPU PowerVR.

Et le résultat ces quelques (dizaines de ?) heures de boulot n’est pas désagréable ! Alors que nous n’avons pas encore attaqué l’optimisation du renderer (et il y a beaucoup à gagner sur les changements de contexte, par exemple), on arrive à voir certaines applications Raydium tourner à 60 FPS, à pleine résolution, avec des lightmaps, du trilinéaire, de la physique et du réseau. Et le tout sans qu’on ai besoin de modifier ni le code, ni les assets des applications.

J’ai essayé de monter une petite vidéo qui montre l’état actuel des choses : (version HD dispo) YouTube Preview Image

Même si c’est impossible à distinguer sur cette vidéo, du fait des limitations de l’enregistrement, voir KingHill2 tourner à 60 FPS, sans le moindre accro, sur le Retina Screen (qui est franchement impressionnant, on en arrive à un point on l’antialiasing devient inutile), c’est très gratifiant.

Et le plus beau, c’est qu’il a encore pas mal de choses plutôt simples à faire qui vont très probablement donner encore un gros coup de boost, et que les autres portages de Raydium risquent bien d’en profiter aussi. \o/

PS : J’ai aussi commencé à m’amuser avec des expérimentations pour essayer de rendre des ombres plus sympa, un peu dans le style “occlusion ambiante”. C’est pas encore ça, et ça rame dur. Mais c’est rigolo à faire.

[Photo] Un an de tout et n’importe quoi …

Mercredi 15 septembre 2010 à 15:23

Cela fait maintenant plus d’un an que je n’ai pas posté de sélection photo, alors je rattrape tout ça d’un seul coup.

L’idée consiste a ne garder à chaque fois qu’une photo, qui doit à la fois me plaire, bien sûr, mais aussi résumer toute la situation ainsi que l’ambiance du moment. C’est très casse gueule, étant donné que c’est extrêmement subjectif et que certaines de ces photos ne parlent probablement qu’a moi ou aux personnes qui étaient là à ce moment. Et tout ça est très naïf, et surtout très amateur …

Il n’empêche, j’adore voir cette alternance de photos et le contraste entre chacune d’entre elles, alors je pose ça ici. Certaines ont déjà été vues ici, pour des illustrations d’articles ou même pour des participations au (feu) Pixo de Caroline.

1 :

2 :

3 :

4 :

5 :

6 :

7 :

8 :

9 :

10 :

11 :

12 :

13 :

14 :

15 :

16 :

17 :

18 :

19 :

20 :

[ManiaCrash] Synthétiser le son d’un moteur

Lundi 9 août 2010 à 1:43

L’introduction et la théorie

La dernière fois que j’ai posté ici, il y a maintenant pas mal de temps, c’était à propos de ManiaCrash, et j’étais englué dans des histoires de modélisations de la physique d’un moteur à explosion, en particulier au niveau de la gestion du couple, et autour d’une question clef : pourquoi les moteurs calent si peu facilement ? (rapport à ma propre simulation ou on cale tout le temps, au point de ne même pas pouvoir démarrer).

Bref, un article sous forme d’appel à l’aide, sur un sujet assez obscure et pas très sexy qui a en fait, étonnement, suscité un certain intérêt avec plus d’une trentaines de commentaires, particulièrement intéressants pour certains. L’article a également eu pour effet de me permettre de rentrer en contact avec des gens “du métier”, dont Claude, qui en une phrase m’a fait réaliser l’énorme erreur de modélisation commise dès le début de ma réflexion …

Je reviendrais en détail sur tout ça après avoir retravaillé complètement cette partie du prototype, devenue petit à petit une impasse extrêmement frustrante, pour voir si ma nouvelle conception du problème me permet d’arriver à un comportement un peu plus réaliste que mon actuel moteur-qui-cale-tout-le-temps.

Mais là n’est pas le sujet de ce post, dont le but est bien de partager avec vous les évolutions de ManiaCrash en ce qui concerne les sons des moteurs. En effet, j’avais déjà commencé à bosser sur ce terrain, considérant que l’audio tient une place très importante dans le réalisme offert par un jeu de caisses, ou tout du moins, dans les sensations de vitesse rendues.

Pour résumer très très rapidement ce que je racontais dans le précédent article à ce sujet (voir le second chapitre), là ou ManiaDrive n’utilisait qu’un seul son pour le moteur de la voiture, qui subissait donc, par exemple, de véritables tortures au niveau de sa vitesse de lecture pour rendre à peu près le son d’un moteur, j’essaye maintenant d’utiliser beaucoup plus de sons (samplés) et ainsi supporter toute la “plage” sonore d’un véritable moteur. Typiquement, 6 samples, à des vitesses de rotations clefs (ralenti, 2000 tours, 3000, …)

Le problème devient alors de savoir comment mixer ces différents sons entre eux pour donner un résultat final qui semble n’être qu’un seul son, sans transitions audibles. La dernière fois, j’avais un résultat potable au niveau du gain (le volume), mais je n’arrivais pas à trouver la bonne “formule” pour le pitch (la vitesse de lecture), mon meilleur essai étant ça : http://ftp.cqfd-corp.org/mc_engine1.mp3 , ce qui est particulièrement mauvais, vous en conviendrez …

La courbe de pitch était celle-ci : (chaque ligne représente un sample)

Très vite, après avoir repensé 2 secondes mon problème, je suis arrivé à une courbe beaucoup plus logique, qui “mappe” tout simplement la fréquence de lecture du son avec la vitesse de rotation du moteur dans le jeu. C’est tellement évident une fois qu’on le voit, que je suis passablement navré d’avoir perdu du temps avec la version précédente :/

Ça donne ce genre de courbes : (qui ressemblent un peu à des courbes de vitesse/rapports de boite, étrangement [ou pas, du coup])

Il y a un sample à 2500 RPM, le moteur enregistré ici ayant une sonorité particulière à cette vitesse.

Le gain, lui, ne change pas du tout dans l’idée générale :

… sauf qu’un nouveau problème pointe le bout de son nez : la dynamique audio d’un moteur de voiture est énorme … pour le dire avec mes mots de noob de l’audio, la différence de volume entre un moteur au ralenti et ce même moteur à sa vitesse de rotation max est gigantesque, et tout simplement impossible à rendre sur le matos du joueur lambda (ralenti inaudible, saturations, parasites dégueulasses à très bas volume sur la majorité des cartes son grand public, …) . Donc impossible de laisser les samples bruts avec les gains donnés sur le graph précédent. Je sais, j’ai essayé, et mes oreilles sifflent encore.

Il faut donc gruger sur les volumes pour “compresser” la dynamique réelle d’un moteur. Plutôt que de faire ça directement dans les samples, technique un peu crade qui risque d’abimer les samples à force de les éditer pour ajuster petit à petit l’amplification, j’ai préféré intégrer tout bêtement un facteur “gain” dans la courbe précédente. Ça permet d’ajuster cette compression facilement pour chaque voiture. Visuellement, c’est très parlant, ça donne ça : (à comparer au graph précédent, donc)

Comment vérifier que cette jolie théorie rend effectivement quelque chose ? Appliquée à mes quelques samples piqués à droite et à gauche, le rendu semble cohérent, mais est-ce “réaliste” ? (relativement limité hein, le réalisme … on parle d’un simulateur de cascades après tout)

Le pourquoi

Il s’avère que j’ai franchi récemment une dizaine, étape consacrée par ma concubine avec un cadeau inattendu : une 104. Oui, une magnifique Peugeot 104 GL (Grand Luxe, donc, si si) de 1980, avec un moteur rutilant de 1L (moins, en fait) qui tourne au plomb et à l’huile … Un modèle de collection, petite voiture abordable, ancêtre des citadines, emblème de toute une génération d’automobilistes avides d’évasion (mais pas trop loin). “Tout Peugeot en 3,58 m”.

Je dois probablement donner l’impression d’en faire trop, mais cette voiture est vraiment mythique pour moi et mon crew (…), elle est au centre de nombre de délires de cette joyeuse bande, et depuis une bonne 15aine d’années. Et là, on en a une sous la main, en vrai. Et je peux même la conduire. Légalement.

Je ne vais pas me répandre ici sur les longues heures de rire à ausculter, conduire, tester cette vénérable pièce de collection de 30 ans d’age, et aller directement à l’explication de tout ce chapitre : Nous avons décidé de tourner un reportage sur cette voiture. Pas un truc plein de nostalgie coulante et de complaintes sur la lente déchéance de l’automobile plaisir en France, oh que non, mais un truc à la Top Gear, avec des faits, de la fumée, des marteaux et de la sueur.

Pour vous prouver notre bonne volonté, voilà une photo relativement récente qui montre la bête après quelques heures de travail avec quelques membres de la fine équipe :

Beaucoup de détails ne sont pas visibles. Les bandes sont intégralement basées sur les bandes racing ”Le Mans” des Ford GT. SERIOUS BUSINESS §§!

Plus prosaïquement, nous avons réalisé quelques tests pour voir si nous avions les moyens techniques et les compétences pour réaliser un tel reportage. La réponse est bien évidement “non”, et de très loin. Qu’importe, on fera un machin “qualité youtube”, flou, avec zéro cadrage, une clef de 12, et qui fera marrer que nous. L’ambition, c’est surfait.

N’empêche, même si quelques appareils photo récents suffisent a peu près pour les prises de vue, pour le son, c’est autrement plus compliqué. Les micros ne sont pas très sensibles, il est impossible de filmer de loin quelqu’un qui parle, ou même de l’enregistrer dans la voiture pendant qu’elle roule, les sons du moteur sont mal rendus, et je ne parle même pas du souffle du vent.

Notre première idée a été d’aller voir du coté des Freeport de Sennheiser : un micro cravate, un transmetteur UHF avec une portée d’au moins 100m, le tout pour un prix encore abordable, de l’ordre 170 euros. Nous nous sommes rendu chez Michenaud, une grosse enseigne de la vente d’instruments de musique, qui est à Nantes, et qui dispose aussi d’un magasin Live / Home Studio. Grosse aubaine, donc.

Chance, on trouve la référence là bas, le produit est en stock, et nous propose même de l’essayer sur place. Résultat bluffant, l’achat est décidé dans la foulée. En tant que gros débutants, on en profite au passage pour demander l’avis des deux gars du magasin sur le meilleur moyen d’enregistrer la sortie du Freeport. De notre coté, nous avions pensé récupérer un lecteur MiniDisc sur ebay pour trois fois rien, méthode immédiatement déconseillée d’une magnifique grimace synchronisée de la part de nous deux puristes. Il semble que le meilleur moyen pour nous soit encore d’utiliser un PC avec une bonne carte son, ce qui n’est pas sans poser quelques problèmes logistiques (portables obligatoires, donc carte son USB, nécessité d’une table de mixage ou d’entrées multiples si on souhaite utiliser plusieurs micros, …).

Et là, la découverte ultime : le Zoom H2.

Il s’agit à priori d’un bête micro + enregistreur portable, rien de très impressionnant. Sauf que la bestiole dispose de 4 micros directionnels statiques ! Là encore, on nous laisse faire un test, on lance l’enregistrement, et on discute des détails du truc. Au moment de relire l’enregistrement, le casque sur les oreilles, je galère pour trouver comment commencer la lecture, l’ergonomie du H2 étant assez … particulière au début. Pas de son, pas de souffle, rien, soit je sais pas comment lire, soit le volume est à zéro. Mon pote, à ma droite, n’arrête pas de me parler, j’arrive pas à me concentrer, je lève la tête vers lui, un peu vénère, pour lui demander de fermer sa mouille … ses lèvres ne bougent pas pendant qu’il parle. Je suis en train d’écouter l’enregistrement depuis 30 secondes FFS !

On a eu l’occasion de faire la démo à plusieurs personnes depuis, l’effet est garanti … C’est vraiment un gros cran au dessus de tout ce que j’ai eu l’occasion de bricoler au niveau des enregistrements audio jusque là. Bref, achat direct et immédiat pour nous : c’est tout léger (110 g) , autonome, toujours autour de 170 euros, ça utilise des cartes SD, ça sort du WAV, du MP3, 2 ou 4 canaux séparés, livré avec une mousse pour réduire le bruit du vent … Magique.

Et le plus fort : même si on a besoin (pour le fameux reportage) d’enregistrer plusieurs personnes en même temps, à des endroits différents, et en mouvement (2 conducteurs dans 2 voitures différentes, par exemple), chacun son Zoom H2, et zou le mixage se fait en numérique dans le logiciel de montage. Plus besoin de transmetteur HF ni de table de mixage … Gros merci aux deux gars qui ont retourné la moitié du magasin pour nous, alors qu’on sort finalement avec un seul truc, sincèrement. Et pour leurs conseils.

Si vous cherchez le rapport avec tout le reste, le voilà : avec le H2, j’ai enfin la possibilité de sampler correctement une vraie voiture. Sans saturation, sans parasites. En stéréo. J’ai déjà essayé de faire ça un paquet de fois, et ça se soldait invariablement par un échec. Même une prise de son qui rendait nickel a priori s’avérait en fait complètement inexploitable dès qu’on changeait le pitch, par exemple (”oh, bhen j’entends plus que le bruit blanc tient !”)

Avec le H2 : rien.  Mais rien du tout. A un tel point que j’ai pu, sans aucune difficulté compter les RPM de mon moteur à la main dans Audacity ! (et pour ref : rpm=(1/(n_samples/44100))*60)

Et ça, c’est à près de 6000 tours/minutes avec un moteur qui hurle … Limite si on ne visualise pas la course des pistons.

J’ai donc réussi à enregistrer, en un seul essai et une seule prise toute la plage de vitesse de rotation d’un moteur. Je n’ai pas utilisé la 104, probablement incapable de subir un tel traitement pour l’instant, (haut régime à vide et à l’arrêt) et de toutes façons indisponible pour l’instant pour une sombre histoire de batterie et de câbles, et ai donc dû utiliser une voiture un peu plus apte à ce genre d’exercices.

Bon, et le résultat, hein ?

J’ai enregistré le résultat des premiers tests. Pour permettre la comparaison, j’ai placé d’un coté la vraie voiture, et le l’autre la synthèse.

A écouter très fort (même si le son a déjà été normalisé un peu, il faut franchement pousser le volume), et surtout au casque pour bien distinguer la piste gauche et la piste droite. Il s’agit des samples utilisés pour la vue intérieure de la voiture : (l’enregistrement de la vraie voiture a été fait lui aussi depuis l’habitacle)

http://ftp.cqfd-corp.org/mcrash-compare-s16-fake-real.mp3

Et bonus, je viens juste de terminer de coder ça : un autre essai, ou je switch entre la vue intérieure et extérieure de la voiture : (uniquement le “faux” moteur ici, donc)

http://ftp.cqfd-corp.org/mcrash-inout-s16.mp3

Pour ceux que ça intéresse et qui le connaitrait déjà, le moteur est un EW10J4, sur une 206 S16. Pas si mal quand on compare tout ça au premier essai donné plus haut, non ?

[help] Moteur, couple et modélisation

Mardi 13 avril 2010 à 19:29

Épisodes précédents, par ordre chronologique :

La situation actuelle et le problème

J’ai recommencé à me pencher sur la physique des voitures de la future suite de ManiaDrive, après une longue période d’inactivité sur le projet. J’ai en effet dépensé énormément d’énergie à coder la physique des pneus (qui reste le point le plus important d’une simulation de véhicule, selon moi) ce qui fait que dès la première grosse difficulté suivante (celle qui nous intéresse aujourd’hui, donc), ma motivation s’est effondrée d’un seul coup.

Sauf que là, paf, 6 mois après, ça me reprend. Et pour ne pas retomber dans les mêmes travers, j’essaye de décortiquer mon sujet autant que possible avant de me plonger trop dans le code.

Le problème de base est en définitive très simple : mes voitures calent. Quoi que je fasse, quelle que soit la puissance du moteur, elles calent lamentablement dès que j’engage la première vitesse.

L’explication est elle aussi toute simple quand on se penche sur la manière dont j’ai implémenté le moteur et la transmission pour l’instant. En effet, je dois interagir avec le moteur physique ODE (j’en ai déjà longuement parlé), et en l’occurrence mon point d’entrée vers ODE se situe au niveau des liaisons hinge2 de la suspension. Pour schématiser, pour chaque roue (motorisée, donc) je dois fournir à ODE deux informations : dParamVel et dParamFMax. La première indique à quelle vitesse je souhaite que la roue tourne (vélocité angulaire) et le second indique quelle est la force maximum (couple max, ici) que j’autorise pour essayer d’arriver à cette vitesse.

Dans la simulation, le temps est “découpé”en toutes petites étapes (timesteps) et il devient alors facile de simuler l’action d’un moteur en demandant une vitesse angulaire élevée (le pilote écrase l’accélérateur -> il souhaite aller à la vitesse max de la voiture) mais en autorisant une force max relativement faible (en fonction de la “puissance”du moteur) à chaque timestep. Ainsi, le moteur doit accélérer petit à petit la roue, mimant alors l’accélération du véhicule.

Bien sûr, on va intercaler des calculs supplémentaires pour simuler divers équipements nécessaires au bon fonctionnement du tout, et tout particulièrement :

  • Un différentiel, qui va permettre de répartir la force du moteur entres les différentes roues motrices. Un différentiel de base va autoriser les roues à tourner à des vitesses différentes (lors d’un virage à gauche, les roues de droite doivent parcourir plus de chemin que les roues de gauche, qui doivent donc tourner moins vite) alors qu’un différentiel plus évolué (à glissement limité) va aller plus loin, en bloquant plus ou moins une roue qui tournerait nettement plus vite que l’autre, signe qu’elle est train de “glisser”. Imaginez une voiture, dont les roues motrices sont à l’arrière, dans un virage très serré à gauche, à grande vitesse. Dans cette situation, il est tout à fait probable que la roue arrière gauche n’ai que très peu d’adhérence, voire même qu’elle ne touche plus le sol (typiquement avec des suspensions indépendantes). Un différentiel de base va alors envoyer toute la puissance sur la roue qui “tourne le plus facilement”, c’est à dire sur celle qui n’est pas capable de poser cette puissance au sol. Résultat : crissements de pneus, fumée, voiture qui n’avance plus et difficilement contrôlable. Un différentiel à glissement limité va bloquer en partie cette roue pour que la puissance soit bien envoyée à la bonne roue.
  • Une boite de vitesses, pour changer la démultiplication de l’effort du moteur. Pour revenir à nos variables, on va multiplier la vitesse dParamVel par la rapport de boite (typiquement inférieur à 1) et diviser dParamFMax par ce même rapport. Tout bêtement.

Jusque là, tout va bien dans notre simulation. Pour déterminer dParamVel, il suffit de prendre la vitesse de rotation du moteur (celle indiquée sur le compte-tours [par la suite, on va dire RPM]), d’appliquer le rapport de boite (et celui du pont, dans l’absolu) et hop. En revanche, pour dParamFMax les choses se compliquent un peu. En effet, sur un moteur thermique, cette valeur varie en fonction de la vitesse de rotation du moteur.

C’est là que les courbes de couple entrent en jeu. Voilà une courbe typique, ici pour un moteur 2L essence 16 soupapes de chez Peugeot :

A partir de la courbe verte (courbe de couple), il est facile de déterminer le couple du moteur (dParamFMax donc) en fonction des RPM.

Et c’est là que je commence à coincer sérieusement. Quand on regarde ces courbes, elles sont typiquement très plates. Même avec mon petit moteur de test, celui d’une Fiat Panda 45cl, un ridicule moulin de même pas 1L, on arrive à une courbe encore très acceptable :

~ 50 Nm au ralenti, ~70 au max.

Voilà pourquoi ça me gène : Je ne vais pas vous apprendre que pour lancer une voiture à l’arrêt, on monte un peu le régime moteur, et on “distribue” petit à petit la force du moteur avec l’embrayage. Pour moi, l’utilisation de l’embrayage a donc pour but d’aider le moteur qui n’a pas assez de couple à bas régime pour démarrer la voiture sans caler. Si je résume ma vision d’un embrayage pas complètement relâché : le moteur ne supporte pas toute la charge de la voiture, mais en contrepartie ne peut pas fournir tout son couple à la transmission.

Et c’est pourquoi dans un simulateur comme rFactor, on se permet en général de monter le régime à mort et de lâcher d’un coup sec l’embrayage lorsque le feu passe au vert, comme un dégueulasse, pour faire un départ en trombe et en fumée. On a été chercher le couple très haut dans les tours. J’ai aussi l’impression de voir ça lors du départ d’une course de voiture IRL.

Sauf que ça colle absolument pas avec les fameuses courbes de couple : il n’y pas plus de couple dans les hauts régimes qu’au ralenti. Il y a plus de puissance, certes (Puissance = couple * RPM), mais le couple est sensiblement le même.

Alors pourquoi une voiture cale si on lâche l’embrayage d’un seul coup au ralenti alors que ça ne semble pas être le cas si on fait la même chose à plein régime ?! (notez que je n’ai jamais eu le courage de faire le test sur une vrai voiture, de peur de laisser l’embrayage et la moitié de la boite de vitesses par terre)

Du coup, dans ma simulation actuelle, on commence à comprendre pourquoi la voiture cale systématiquement. J’accélère à plein régime, je passe la première, et comme je n’ai pas encore implémenté l’embrayage, toute la patate est directement balancée à la boite de vitesses puis dans les roues. Sauf que “la patate”, c’est quelques dizaines de Nm * le rapport de boite, c’est à dire pas de quoi faire réellement bouger la voiture. Tout pareil qu’au ralenti en fait.

Résultat, au timestep suivant, je regarde la vitesse de rotation des roues motrices, histoire de mesurer “l’impact” du moteur lors du timestep précédent, je constate que la roue tourne à peine, je traduis ça en RPM moteur (là encore, le ratio de la boite intervient) et j’arrive à peu près à 0 RPM : le moteur cale.

Accessoirement, le fait d’attendre le timestep suivant pour mesurer la charge du moteur semble probablement une méthode immonde, mais ODE ne me donne pas directement cette info (charge moteur), c’est donc la seule idée qui m’en venue pour l’instant.

Bref, résultat : je suis incapable de faire des “smoking starts” avec ma Ford Fiesta et son moteur de Fiat Panda, et ça c’est frustrant.

Les pistes

Je n’ai pour l’heure trouvé que deux explications possibles, peut-êtres complémentaires.

  1. l’embrayage
  2. l’inertie du moteur et de la transmission

En effet, une supposition serait qu’un embrayage, aussi sport soit-il, ne se “solidarise” pas tout de suite lorsqu’on embraye, même de manière violente. Dans mon exemple précédent, l’embrayage pourrait patiner un peu lorsqu’on relâche la pédale, permettant au moteur de ne pas subir tout de suite toute la charge de la voiture. Cela signifie que les RPM tombent toujours, mais moins rapidement, ce qui donnerait effectivement un avantage à un départ “à fond”. Mais je ne suis pas persuadé que cela suffise pour faire un démarrage en burn, puisqu’avec cette solution, on ne transmet aux roues qu’un couple encore amoindri (puisque l’embrayage patine).

C’est pour ça que la seconde piste m’intéresse un peu plus : un moteur lancé à pleine vitesse possède une inertie. Cette inertie, c’est du couple en plus, non ? En clair, je lance le moteur à fond, j’embraye, il devrait caler (= tomber à 0 RPM) mais avant ça il doit perdre son inertie, générant alors un couple en plus de son couple “nominal” (celui qui est sur les courbes). Mais d’après mes permiers tests, qui peuvent très bien êtres faux, pour faire un démarrage en faisant patiner les pneus, ce n’est pas quelques Nm en plus qu’il faut, mais bien quelques centaines ! (et encore, avec mes pauvres petits pneus de Fiat Panda [135/80/13 !]) Est-ce possible ? Comment calculer ce couple ? A partir de quelles données techniques ? Tout ce que j’ai concrètement à l’heure actuelle, c’est les RPM moteur au timestep n et ceux au timestep n+1, l’écart entre ces deux valeurs ayant probablement quelque chose à voir avec ce fameux “couple inertiel”.

J’ai aussi des interrogations du même genre sur la vitesse avec laquelle un moteur monte et descend dans les tours à vide (embrayage enfoncé, donc) … il doit bien y avoir  une histoire d’inertie là aussi.

Bref, que ce soit sur ce dernier point ou sur d’autres pistes, si vous avez des idées sur tout ça, je serais heureux de les lire, et si vous avez des compétences en mécanique, tout pareil. Bref, HALP§

Pacejka Magic Formula and ODE (Open Dynamics Engine)

Jeudi 12 novembre 2009 à 17:32

Sorry to the usual audience of this blog, but this article aims to document a very specific topic: Pacejka and ODE. Since I was unable to find any resource on the web, I hope that, thanks to search engines, it may help people trying to mix these two things together.

While working on preliminary tests for ManiaCrash, I had to understand and implement Pacejka Magic Formula, the famous tire model used to simulate quite accurately tires behavior. You may have a look at what is probably one of the best explaination and vulgarization about Pacejka, on Racer website. If it’s quite easy to find some documentation about Pacejka equations, I had hard times finding tips about how implementing it, especially in my particular case, where I need to “integrate” Pacejka into the physics engine I use in Raydium: ODE.

Doing a such thing implies a few points: you must “extract” inputs for Magic Formula from ODE, apply Pacejka on these inputs, and “send” the result to ODE. And each of these steps reveals to be an issue.

While the point of this article is not to explain Pacejka basics, let’s have a quick look at the main two forces, longitudinal and lateral, since the usual last one (aligning moment) is then very easy to understand.

  • longitudinal formula: computes Fx force the tire will apply on the road, “along” the car. Inputs: slip ratio (SR) and load (Fz)
  • lateral formula: compute Fy force the tire will apply sideways on the road (giving, more or less, the G force the car will support during the corner). Inputs: slip angle (SA) and load (Fz)

Obviously, the best place for all this is the dCollide() result loop, for each tire/road contact. If you’re using Raydium, see raydium_ode_CollideCallback.

Inputs

As a reminder, slip ratio gives how much the tire is “sliding” on the road along its X (It’s related to accelerating and braking situations, in other words) and is often described as the ratio between current angular velocity of the tire and free rolling speed, where I prefer to explain it as the the relative speed of the tire at road contact point. On the other hand, slip angle is the angle between wheel heading (local X axis) and its moving direction. The last input, Fz, is the vertical load of the tire.

The challenge is then to find the best way to get these informations from ODE, and here’s what I’ve come up with. Please note I’ve removed unnecessary variable declarations so the code is easier to read.

First, let’s try to determine the slip angle. The basic idea is to get the velocity of the wheel, turn it into a vector, get the wheel heading and then apply a scalar product on these two.

//// Slip Angle

dVector3 wh, wt; // wheel heading, wheel travel
dReal sa; // slip angle

// 1 - get wheel travel vector
// velocity of the wheel at (0,0,0)
dBodyGetRelPointVel(wheel.body,0,0,0,wt);
// same as wt=dBodyGetLinearVel(wheel.body);

// 2 - get wheel rotation (Y) axis (so we get wheel heading + 90, see step 4)
dBodyVectorToWorld(raydium_ode_element[e1].body,0,1,0,wh);

// we normalize wt (wh is already normalized)
vnorm(wt);

// 3 - determine angle between these two vectors, using scalar product.
// We need a result in the first quadrant only: SA>90 means nothing, since
// a tyre does not have forward/backward, but only a longitudinal axis.
scal=(wt[0]*wh[0]) + (wt[1]*wh[1]) + (wt[2]*wh[2]);
sa=180*(acos(scal))/PI;

// 4 - here, we "switch" from wheel Y to X, and limit SA to [0,90] range
sa=abs(sa-90);

Then comes the slip ratio. Using the “relative speed at contact point” idea and with the magic of ODE, the result is surprisingly simple !

//// Slip Ratio
dReal sr; // slip ratio

// 1 - relative speed at contact point (res is in world coords)
// "n" is a pointer to the dContact structure returned by ODE for the current contact
dBodyGetPosRelPoint (wheel.body,n->geom.pos[0],n->geom.pos[1],n->geom.pos[2],pos);
dBodyGetRelPointVel (wheel.body,pos[0],pos[1],pos[2],res);

// 2 - get velocity along wheel heading
// done using dot product : (fdir1 . relative speed)
sr=raydium_math_abs(
(n->fdir1[0]*res[0]) +
(n->fdir1[1]*res[1]) +
(n->fdir1[2]*res[2]) );

// note: fdir1 is the contact direction. See below.

The last thing is to get the tire load. We use some sort of temporal cohesion and get the last ODE step result as an input. It’s done thru ODE joint feeback, and if here I use Raydium functions to do so, it’s very easy to code your own system using dJointSetFeedback(). Of course, the result should probably be scaled before sending it to Pacejka, since you may not use real word units in your application/game.

//// Tire Load
dJointFeedback *jf;
dVector3 force; // local force produced by the tyre during last physics step

// let's find the generated "tire force" during last step
raydium_ode_contact_feedback_save(wheel); // we ask Raydium to store joint feedback during the next step ...
jf=raydium_ode_contact_feedback_get(wheel); // ... and we fetch the saved feedback data from the previous step.
// note: again, fdir1 is the contact direction. See below.
dRFrom2Axes(wheel_matrix,n->fdir1[0],n->fdir1[1],n->fdir1[2],wh[0],wh[1],wh[2]);
dMULTIPLY1_331(force,wheel_matrix,jf->f1); // "world to wheel"
// force[2] is the vertical load

Outputs

Once you’ve computed Fx and Fy using your Pacejka code (again, you’ll find a lot of documentations and sample implementations for this all around Internet), you need to send it back to ODE. As a simplification, Pacejka formula outputs a “maximum” force that the tire can support, but the situation may require way less force than that. And if it requires more, we must make the tire sliding. How can we explain this to ODE since the usual friction pyramid model does not allow this ?

This part was quite tricky to me, since I discovered that I was not that good at understanding the whole ODE contact model. In facts, the answer was somewhere in the ODE userguide, where it’s said that when dContactApprox “is not specified then the constant-force-limit approximation is used (and mu is a force limit).” Great, that’s just what we need: constant force limit model !

// "n" is a pointer to the dContact ODE structure for the current contact
n->surface.mode = dContactSoftERP | dContactSoftCFM | dContactMu2;
// note that there's no dContactMu1 in ODE (it's implied by mu2)

Since we use mu1 and mu2, another important thing then is to determine contact direction. This is also needed by previous code, where “fdir1″ was used. In facts, this is probably one of the first things to do in your contact callback.

//// contact direction (n->fdir1), based on wheel heading

// cross product of normal and wheelY (fdir2)
n->surface.mode |= dContactFDir1;
n->fdir1[0] = wh[1]*n->geom.normal[2] - wh[2]*n->geom.normal[1];
n->fdir1[1] = wh[2]*n->geom.normal[0] - wh[0]*n->geom.normal[2];
n->fdir1[2] = wh[0]*n->geom.normal[1] - wh[1]*n->geom.normal[0];

// wh is wheel heading dVector3 + 90 degrees. See slip angle, above

Then, you just have to set mu1 and mu2. Again, you may have to scale these values to suit your world units.

mu1=fx*PACEJKA_MC_SCALE;
mu2=fy*PACEJKA_MC_SCALE;

if(isnan(mu1) || mu1<0) mu1=0;
if(isnan(mu2) || mu2<0) mu2=0;

n->surface.mu=mu1; n->surface.mu2=mu2;

That’s it !

This article is a first try, comments are welcome. A few topics are left unexplained, as Pacejka computations and the need for a combined model, for instance. I’ll get on this later. Currently, ManiaCrash source code is not public yet (until the very first alpha), but I’ll add a link to suitable files once done.

[musique] La playlist qui dénonce

Mardi 6 octobre 2009 à 0:31

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)
YouTube Preview Image
… 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
YouTube Preview Image
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
YouTube Preview Image
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
YouTube Preview Image
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
YouTube Preview Image
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.
YouTube Preview Image
Achetez ce truc. Sans déconner.

Image exclusive TF2 : Le Pyro de la Team Verte !

Jeudi 20 août 2009 à 22:17

Mmmphh mphhhh mphh !

Mmmphh mphhhh mphh !

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

Désolé …

Pacejka, ODE, et bruits de moteur

Vendredi 7 août 2009 à 20:15

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 :

Raydium Pacejka ODE debug

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 :)

RMLL 2009 : conférence Raydium

Jeudi 16 juillet 2009 à 12:17

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.

YouTube Preview Image

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 !