Voilà les nouveautés depuis le dernier post à propos de l'écran FTIR :
- vidéoprojecteur
- miroir + support à 45°
- webcam rabaissée, pour passer sous le cône de projection du vidéoproj'
- pas mal de Lego, pour le support miroir et le nouveau "boitier" de la webcam
- des réglages empiriques de la mort
- du papier calque (surface de projection)
- une émulation de la souris
... et ça marche plutôt pas mal !
Il faudrait maintenant imaginer un système de calibrage logiciel, une surface de projection suffisamment grande et en une seule pièce, un recul suffisant pour que la webcam puisse voir la totalité de la surface de la plaque, et surtout des applications exploitant le multitouch.
Et je commence sérieusement à penser à commencer l'écriture de "ManiaDrive 2".
Les choses bougent raisonnablement du coté de la réalisation de l'écran FTIR (épisode précédent). J'ai placé toutes les LEDs (40 !) sur le bas de l'écran, et il s'avère que ça crache tellement d'infrarouges que je ne vais probablement pas avoir besoin de placer de nouvelles LEDs sur la partie haute de l'écran. A voir à terme, mais je pense qu'une bande réfléchissante serait suffisante, dans le pire des cas.
J'ai eu l'occasion de trouver un peu de temps pour me pencher sur l'algo de détection des blobs. L'idée est d'arriver à détecter les "impacts" infrarouges laissés par les doigts en contact avec la plaque, pour déterminer combien de doigts (ou n'importe quelle autre extrémité composée de peau, bien sûr) sont posés sur la plaque de plexi, ainsi que la position, pression, et la vélocité de chaque doigt.
En environ une semaine (1h/jour ?), je suis arrivé à un truc pas trop mal. Étant en déplacement, je bossais avec une vidéo pré-enregistrée d'une minute, sur laquelle j'arrivais à un taux de réussite de 100%. L'algo offre des événements (OnTouch, OnUntouch, OnMove) très simples à utiliser ensuite. Hier soir, à l'aide de RyLe, nous sommes passés à un test grandeur nature, en temps réel. Nous avons massacré un volant Wii (les trucs à 10 euros vendus pour Mario-Kart [jeu de merde, soit dit en passant]) pour en extraire le filtre infrarouge que nous avons ensuite collé sur l'objectif de la webcam. Malgré de multiples essais (voir articles précédents), je n'ai jamais eu un résultant aussi probant : le filtre est excellent, et ne laisse quasi rien passer de la lumière visible ! En revanche, l'aglo a montré ses limites, étant très dépendant de l'éclairage ambiant et des réglages de la webcam (fps, taille de l'image, réglages de contraste, balance des blancs et autres).
La journée d'aujourd'hui a été l'occasion de pousser tout ça plus en avant, avec une belle découverte : la webcam (Philips SPC900NC) dispose d'un capteur d'excellente qualité qui, si on balance les bons réglages au driver (le non moins excellent "pwc" de Luc Saillard), fait ressortir différemment l'infrarouge "naturel" (soleil et la majorité des lumières artificielles, y compris halogènes) de l'infrarouge des LED (longueur d'onde différente, probablement), ces dernières générant à l'écran une teinte bleutée ! (à la différence du reste des IR, en gris). J'ai ainsi eu l'occasion de ré-écrire l'algo en tenant compte de cette nouvelle donne, et le résultat est maintenant excellent, même en pleine lumière.
Voilà, sous forme d'une toute petite vidéo très sombre (faizez péter le gamma !), ce que ça donne :
Sympa, non ? :)
Il reste un tas de choses à faire, mais c'est plutôt une belle avancée. Suite : trouver un vidéo-projecteur, et surtout une surface qui permette de projeter sur la plaque sans perturber le passage des IR.
Je ne suis pas un grand fan des articles à la con, mais là je viens de tomber sur une situation qui m'a fait sourire. J'étais en pleine séance intensive de boulot, quand une publicité très ciblée m'attire l'oeil :
D'un naturel inquiet, je décide de vérifier si mon Linux n'aurait pas besoin d'une petite mise au point, et clique sur le bouton "commencer" (au style assez inhabituel sous Linux, vous en conviendrez).
Il semble que ce soit une grosse application ... :
Peu de temps disponible des derniers temps, mais ça avance un peu du coté de la réalisation de l'écran tactile puisque les premiers tests rapides donnent des résultats corrects. Avec une bête détection de seuil, voila à quoi j'arrive à l'heure actuelle :
En rouge, les pixels dont l'intensité du rayonnement IR dépasse un seuil fixé empiriquement.
Pression plus forte du doigt sur la plaque.
Multitouch !
Rappel du fonctionnement de l'effet FTIR.
Au rang des problèmes, il s'avère que la distance entre la surface de la plaque de plexi et le corps en contact doit être inférieure à la longueur d'onde de la lumière qui inonde la plaque pour déclencher "l'effet FTIR" (ou plutôt son contraire, en l'occurrence). Or, l'aspect "rugueux" de la peau demande une pression relativement importante des doigts sur la plaque pour obtenir une belle surface de contact. Sans ça, le "touché" est a peine détectable. (comme si l'émission IR était exponentielle à la surface en contact)
Cette situation n'est pas très compatible avec des déplacements des doigts, du genre drag'n drop, en particulier avec plusieurs doigts d'une même main.
C'est aussi une différence assez perturbante avec les autres écrans tactiles, souvent hypersensibles. Je ne sait pas encore comment corriger ce problème : est-ce commun à tous les écrans FTIR ? La qualité de ma plaque de plexi est-t'elle insuffisante ? Le polissage des bords en contact avec les LED IR serait-il trop mauvais ? L'épaisseur de la plaque insuffisante (8mm) ? Il est peut être aussi possible d'ajouter une couche en plastique relativement souple pour aider les contacts avec les doigts ... A creuser donc.
Autre problème, la plaque de plexi que j'utilise génère un "pixel mort". Un petit corps étranger se trouve en effet emprisonné dans la plaque. Il est visible sur les captures présentent dans l'article. Je vais l'éliminer logiciellement en attendant d'acheter une éventuelle autre plaque.
Les autres soucis (installation laide et consommatrice d'espace, dissipation thermique des LED a étudier, écriture de l'application de tracking des impacts, ...) sont encore très secondaires.
Pour le projet d'écran multitouch FTIR que je suis en train de (tenter de) réaliser, il me faut une caméra sensible aux IR pour filmer le dos de l'écran.
Une manière très peu chère et archi-connue pour cela consiste à utiliser la sensibilité naturelle des capteurs CMOS et CCD aux IR.
Vous avez probablement déjà effectué ce test qui consiste a orienter une télécommande vers une webcam, un appareil photo, un téléphone, ...
Si on jette un oeil à une courbe de réponse typique d'un capteur CCD, on observe une chose assez étonnante : L'oeil humain couvre, au mieux, un spectre de 380 nm à 780 nm (du violet au rouge, donc).
La réponse au delà de 780 nm est excellente, et même en partie supérieure à ce que le capteur arrive a restituer dans les teintes voilettes/bleues ! C'est tellement vrai qu'en fait, les appareils photos numériques, les webcams et autres incorporent quelque part dans leur chemin optique un filtre destiné a éliminer les infrarouges, puisque ces derniers auraient en effet tendance à bruler et déformer le résultat à l'écran.
Il suffit donc d'enlever ce filtre et de le remplacer par un filtre qui élimine les couleurs visibles pour transformer une bête webcam en une "caméra infrarouge".
Pour ma part, j'ai sacrifié ma Philips 680k, excellente webcam dotée d'un capteur ICX098AK de chez Sony, souvent cité comme une référence (très utilisé en astro, par exemple). Avec un certain pincement au coeur, puisque j'ai toujours utilisé cette webcam pour mes bricoles vidéo (elle doit avoir ... 8 ans ?)
En ce qui concerne le filtre IR, coup de chance, cette webcam contrairement à beaucoup d'autres, ne nécessite qu'une petite intervention, le filtre en question étant placé dans l'optique amovible de la webcam. Un simple rondelle de plastique à faire sauter et le tour était joué.
Pour le filtre "lumière visible", la méthode la plus cheap et pourtant la plus efficace consiste à placer dans le chemin optique deux couches de pellicule développée (la partie unie que l'on trouve à la fin des pellicules, précisément). N'ayant pas ça sous la main (et vous, vous avez encore des péloches chez vous, hein ?), je me suis contenté de réaliser mes tests dans le noir, éclairé par une source infrarouge relativement puissante ... mon TrackIR ! (ce machin arrive a éclairer mon salon entier juste avec 4 LED IR)
Voilà quelques captures de tests sympa :
Le TrackIR vu de dos (dans le noir complet, j'insiste)
Ma main. Brrrrr ... (détail amusant : le tissu blanc derrière s'avère être une veste ... noire foncée avec des rayures blanches !)
Un billet de 20 euros.
La panne d'un fer a souder asthmatique, dans le noir complet, toujours, sans amplification au niveau de la webcam.
Une serviette de plage ...
... vue en IR !
Et enfin, le truc qui m'a le plus tué ... Un gobelet rempli de coca, éclairé par le TrackIR :
Si vous avez une vieille webcam ou un vieux numérique, n'hésitez pas, c'est super simple a faire et on découvre de tonnes de trucs étonnants juste en se baladant dans son salon (ou sa cuisine ... vous n'imaginez pas le rayonnement IR qu'émet une plaque chauffante !)
PS : Pour "lustrer" les bords de la plaque de plexi pour l'écran FTIR, je cherche du papier de verre méga-fin (jusqu'a 600). Vous savez ou trouver ça ?
Passée la première envie de se foutre de sa gueule, il faut quand même avouer que le montage a de la gueule, et que le type semble avoir donné pas mal de temps et de sueur pour arriver à ses fins (cf le petit making-of à la fin de la vidéo).
Bien évidemment, l'homme utilise un vrai siège, un Logitech G25, un Freetrack (WTF ?! La salle lui a probablement couté 29 millions d'euros et le mec utilise un clone tout naze de TrackIR ?), un pur HOTAS avec le palonnier, bref, le kit complet du fan de simulation PC.
L'histoire pourrait s'arrêter là, sur les "crédits" présents à la fin de la vidéo :
rFactor, ok, très bien, homme de gout ... mais c'est quoi ça "tactile feedback system" ?
Étant dans ma période "périphériques tactiles", j'ai d'abord pensé à une sorte d'écran tactile, faisant office de clavier ou d'écran de contrôle.
En se rendant sur le site web en question, on nous explique dans le détail que le ivibe est en fait un simple Tactile Feedback System Version 2.0 composé d'un TFS2 electronic controller et de son Tactile Feedback Seating Unit. Supair.
Un peu plus loin, on nous explique que le principe du ivibe est de permettre une immersion encore plus poussée dans les jeux, quels qu'ils soient, en la rendant encore plus réaliste, qui nous donnera la sensation d'être dans un vrai avion si on utilise une simulation d'avion. Je n'exagère rien, c'est exactement comme ça que leur produit est décrit. Aucune info sur ce que c'est vraiment et la manière dont ça marche. Cependant, on nous explique aussi que, contrairement à la concurrence, il ne s'agit pas ici de s'enfiler un caisson de basse dans l'arrière train. Un bon point.
Visiblement, ces gens ne veulent pas êtres copiés et souhaitent donc rester très vagues sur leur produit.
En creusant un peu, on se rend compte que le produit est composé d'un boitier à brancher sur le PC (USB ou port parallèle [WTF² ?!]) et d'une espèce de coussin avec dossier à placer sur votre chaise. En fouillant encore plus, on arrive à savoir que le "coussin" contient 6 moteurs 26 volts, et que le système cherche à créer une sorte de retour de force dans les jambes et le dos.
L'interface entre le ivibe est les jeu peut passer par deux méthodes, je cite, "AudioSense" et "IntelliVibe".
Dans le premier mode, le boitier de contrôle analyse le son qui sort du jeu et essaye de créer des effets de retour de force en fonction. Sounds great ... :/
Ensuite il semble que l'autre mode, Intellivibe, nécessite un plugin spécifique pour chaque jeu. Et la liste semble courte et pas franchement passionnante : on y trouve principalement des vieux jeux du genre Nascar Racing 2002 et autres Grand Prix 4.
Sauf que dans la liste se trouve rFactor. Et que les quelques retours que l'on trouve à droite et à gauche sur le net sont dithyrambiques. Manifestement, le siège ne se contente pas de vibrer de temps en temps, mais va reproduire une palette très large d'effets.
"you can feel the accelleration, the gear changes, the kurbs, gravel, impacts, braking, skidding and much more - it's like force feedback through a steering wheel, but 100x times more realistic and it really does increase the immersion of the game greatly."
"track such as Montreal, Canada seems to demonstrate the power of the TFS2 system very well, as you accelerate from the start-finish straight you can feel the roar of the engine and abrasion of the tarmac (to put it literally), reverberating right up your ass! As you swing around the first corner the TFS2 unit simulates G-force effects by "throwing" you around the cockpit - accurately represented by the vibration of the motorunits. Similarily, as you brake heavily you are "thrown" forward and the experience of braking is accurately represented. Skid, and the TFS2 unit will simulate this feeling as well."
"I'll give it a good run tonight after I finish working, but my initial reation is that this is really, very awesome. It's great to feel the G feedback, feel feedback from either side of the car (rumbles, for example) and crashing ALMOST hurts :P"
La chose coute 240 dollars + frais de ports, le type est tout seul donc ça fait un peur niveau support, ça supporte un seul jeu qui m'intéresse vraiment (et Lock-On pour être exact), mais c'est très tentant. Enfin je crois.
La fonctionnalité est très demandée des joueurs de ManiaDrive, donc il me semblait nécessaire de l'ajouter pour ManiaDrive 2 : les replays. En clair, la capacité de pouvoir sauvegarder une partie pour la rejouer plus tard.
Deux solutions basiques pour réaliser une telle tâche : jouer sur le déterminisme ou tout enregistrer. La première option part du principe que si on reconstruit la scène exactement comme lors de l'enregistrement et que l'on injecte les entrées (clavier, souris, joy, ...) du joueur au même moment, tout va se passer de la même manière que lors de l'enregistrement. Cette méthode à l'avantage d'être très simple à implémenter et de générer des enregistrements de taille très modeste (état initial de la scène + entrées utilisateur).
En revanche, avec cette méthode, il est nécessaire d'être très attentif puisque la moindre erreur, même infime, va complètement décaler la relecture dès les secondes suivantes. Et ces erreurs peuvent êtres engendrées pour des raisons parfois tordues (arrondi d'un nombre flottant, paramétrage différent du FPU de la machine à cause d'une autre application [DirectX est une cause courante de ce problème], léger décalage ponctuel dans la lecture replay, ...). Autre problème : les nombres aléatoires. Ils sont très souvent utilisés dans les jeux, et il est nécessaire que la série aléatoire soit la même lors de l'enregistrement que lors de sa relecture. Il faut donc être sur qu'aucune autre partie de l'application ne se serve du même générateur de nombres aléatoires pendant l'enregistrement et la lecture. Autre point noir : les entrées peuvent être complexes. Par exemple, l'enregistrement des entrées clavier ne pose aucun problème en général. Mais la souris et les joysticks/joypads/volants génèrent beaucoup plus d'évènements, ce qui va alourdir beaucoup le fichier final ... mais le pire reste le problème du réseau. Lors d'une partie multi, gérer les actions des autres joueurs va demander un travail énorme.
Raydium est multiplateforme (OS et CPU peuvent êtres différents), supporte les parties en réseau, et utilise ODE, un moteur physique connu pour être difficile à rendre déterministe. Inutile de perdre du temps à tenter d'implémenter ce genre de replays.
L'autre solution est toute simple : tout enregistrer. En permanence. Chaque création d'objet, chaque destruction, chaque déplacement. Le résultat est bien sûr un fichier beaucoup plus conséquence en taille, on arrive vite à plusieurs Mo par minute sur des scènes complexes. Les avantages en revanche sont très nombreux :
- La répétabilité est excellente : quelle que soit la plateforme, quel que soit l'OS et la version de l'application et de son moteur physique, peut importe ce que l'application fait d'autre que jouer le replay : le résultat sera le même.
- Possibilité de jouer sur la précision du replay. J'enregistre par défaut à 30 Hz, mais il est possible de générer des replays moins précis mais plus petits (10 Hz par exemple).
- Possibilité de jouer le replay en accéléré, mais surtout en arrière ! (très utile pour retrouver une action particulière dans un replay). Les sauts dans le replays sont aussi très peux couteux, quel que soit la taille du saut et son sens.
- Possibilité de jouer un replay pendant une autre partie ... et d'enregistrer en même temps !
- ...
Bref, j'ai cherché a implémenter cette méthode, et avec succès. L'écriture a été assez complexe, je dois l'avouer (on tombe par exemple sur quelques paradoxes temporels lors des lectures en sens inverse), et surtout, elle n'est pas encore complète. Par exemple, les vitesses de lecture inférieures à 1.0 sont encore mal supportées (je n'interpole pas encore entre les samples), et seuls les évènements principaux sont enregistrés. Les sons, les particules, explosions et autres ne font pas encore partie du replay.
Petite vidéo très vite faite de l'application de lecture des replays.
J'ai ici enregistré une partie solo, relancé l'application, joué le replay que je venais de créer tout en jouant "par dessus", tout en enregistrant le tout. Le résultat "ressemble" à une partie multi à deux joueurs. Le fichier pèse 900 Ko pour 61 secondes.
Bref, le sujet s'avère assez complexe, et demande encore quelques évolutions dans Raydium. Mais nous disposons maintenant d'une solution très souple et très générique au problème des replays. A suivre.
Autre sujet, sans grand rapport : les wiimotes. A la suite d'une soirée "Les lapins encore plus crétins" chez un ami en manque de wiimotes, j'ai dû me procurer une wiimote au Auchan du coin. Mais je ne possède pas de Wii. Que faire alors de ce machin tout blanc ? Jouer avec bien sûr !
Grâce à la libcwiimote, il est extrêmement simple d'écrire des applications utilisant la wiimote. Une heure après la découverte de la lib, j'avais une démo qui tournait. Alors certes, il ne se passe pas grand chose, mais l'écriture de cette démo était très intéressante :
A coder une telle appli, on découvre plein de choses sur le fonctionnement interne de la wiimote. Je recommande l'exercice à tous les curieux. Je n'ai pas l'intention d'inclure le support de la wiimote directement dans Raydium (en tout cas pour l'instant), en particulier pour des raisons de portabilité. Mais je compte bien continuer mes tests sur ce nouveau jouet.
Et tant qu'a parler de périphériques d'entrée, j'ai découvert récemment l'effet FTIR. Frustrated Total Internal Reflection pour la version longue. L'utilisation de cet effet permet de créer des écrans tactiles de toutes tailles à moindre frais, et supportant plusieurs pressions en simultané. Et j'avoue être très très tenté par la réalisation d'une telle chose. Je n'ai trouvé aucune vraie ressource en français, mais on trouve beaucoup de réalisations "homemade" à droite et à gauche en anglais.
L'idée de base des écran multitouch FTIR consiste a utiliser une plaque en acrylique (transparente donc) assez épaisse (de l'ordre du centimètre), au bord de laquelle on place des "guirlandes" de LED infrarouges. Ces rampes de LED sont souvent orientées à 45° même si ça ne semble pas strictement nécessaire. La lumière émise par ces LED va rebondir sur la surface de la plaque, ce qui fait que si on filme la plaque à l'aide d'une caméra infrarouge, on ne voit presque pas le rayonnement des LED (qui est "enfermé" dans la plaque). En revanche, il suffit de placer un doigt sur la plaque pour complètement modifier le rebond de la lumière ... et générer un "point" d'émission IR très distinctif.
A l'aide d'une webcam un poil bricolée (on enlève le filtre IR qu'on y trouve systématiquement), on peut filmer la plaque par l'arrière et détecter la présence et la position des contacts des doigts (à l'aide d'un algo qui est ni plus ni moins que celui que j'utilise pour les impacts laser).
Si l'on projette (à l'aide d'un vidéoproj donc) un image sur un papier fin accolé à la plaque d'acrylique (le "diffuser" du premier schéma), on obtient bien un écran tactile !
Pas si encombrant que ça :)
Et avec beaucoup de boulot coté logiciel, on arrive à des trucs du genre de ce que Perceptive Pixel arrive à faire :
Je vais continuer de chercher des infos là dessus, mais j'avoue être très tenté par l'expérience (la partie hard me fait beaucoup plus peur que la partie soft).
PS : Rien à voir, mais je recommande très vivement l'épisode 6 de la saison 10 de Top Gear diffusé dimanche dernier, on y trouve une course de Camping-cars absolument mémorable. Probablement l'un des meilleurs moments de cette saison pourtant déjà bien chargée (cf la traversée de la manche ou la Peel P50 par exemple).
Ces derniers temps, je tente quelques trucs "juste pour voir" au sujet de ManiaDrive 2 (ou quelque soit son nom final). Étant donné qu'il est toujours sympa de garder quelques traces des expérimentations passées sur un projet de ce genre, j'ai réalisé une petite vidéo sans prétentions des tests actuels. Au menu, la Ford Fiesta de Jambon, éclatée en sous-modèles (corps, roues, volant), et mixée avec un conducteur très (très) low-poly, issu de la vieille Clio, dont la tête a été séparée elle aussi.
Tout ça est attaché avec une 10aine de liaisons diverses et quelques moteurs. La voiture utilise ici une propulsion (centrale) et (pour l'instant) une transmission directe, ce qui l'éloigne pas mal de l'original :)
Cette vidéo en particulier le nouveau modèle physique pour les pneus, la vue dynamique et l'animation (et la gestion) du volant.
Lors de notre dernier petit week-end réseau au mois de mai, il s'est avéré que nous avons joué pour ainsi dire exclusivement à rFactor. Plutôt que d'essayer d'expliquer une fois de plus pourquoi ce jeu est scotchant, j'ai préféré utiliser les différents replays de ce réseau pour monter notre heu ... hommage au jeu.
