Pour commencer, une nouvelle image :


Le principe est le même que la vidéo d'hier, mais avec un travail sur la lumière et les ombres, l'intégration des objets 3d y gagnant beaucoup.

A la suite de ça, je me suis lancé dans des tests d'occlusion. Voilà la vidéo, histoire d'éviter les explications compliqués pour rien:


http://raydium.cqfd-corp.org/captures/rayAugmentedReality2.avi

L'idée est tout simplement que la voiture entre en collision avec un objet réel, et surtout ... est cachée par cet objet lorsqu'elle passe derrière !

Pour le reste, voilà quelques explications :
Raydium se fait aider par ARToolKit dans la recherche d'un motif dans l'image. Le motif (marqueur) utilisé ici est "Hiro" :


En connaissant certaines caractéristiques optiques de la caméra, il est possible de déduire quelle est la position et l'orientation de ce motif en fonction de sa déformation (rotations et perspective). Dès lors, avec quelques calculs, il est possible de venir incruster des objets 3D sur la scène filmée. C'est l'ensemble de ce système qui était utilisé dans la précédente vidéo.

L'évolution dans la vidéo d'aujourd'hui réside dans l'occlusion de visibilité. C'est en fait très simple à réaliser une fois qu'on a calibré ses outils. J'ai ici modélisé (dur travail d'artiste) ma ... mon ... le machin qui me sert de salière, depuis de rapides mesures :


J'ai placé cet objet 3D sur la scène 3D, et l'objet original (celui ou il y'a du sel dedans) sur la scène réelle (celle ou mon appart est mal rangé), le tout en quelques calculs très simples pour adapter les repères.
La suite est simple, on déclenche le rendu mais en dessinant la salière uniquement dans le Z-Buffer de la carte 3D (et non plus dans le Color Buffer, celui que vous voyez avec vos yeux visuels...), de façon à ce que le rendu de la voiture prenne en compte la présence de la salière.
Résultat : quand la voiture est dans l'alignement de la salière et suffisement loin, eh bien comme dans toute scène 3D, le Z-Buffer refuse que les pixels de la voiture soient affichés, sous prétexte qu'un autre objet (la salière) est plus proche. Sauf que cette salière n'existe pas dans le Color Buffer et laisse donc apparaître le fond : l'image capturée depuis la webcam ou se trouve justement la véritable salière.

A essayer de faire des explications trop détaillées, j'ai peut être embrouillé certains ... n'hésitez pas à le faire savoir si c'est le cas.

La suite : la présence de plusieurs marqueurs dans la scène filmée et des interactions entre de vrais objets et les objets 3D.

J'ai les yeux qui piquent, mais après quelques dizaines d'heures de lutte, je suis fier de vous présenter la première vidéo de réalité augmentée, réalisée avec Raydium !


http://raydium.cqfd-corp.org/captures/rayAugmentedReality.avi

Les explications viendront demain, j'en suis incapable pour l'heure...

edit : les saccades sont dûes à l'encodage à la volée de la vidéo, c'est du 30 FPS (fréquence de la webcam) sinon.

..., c'est exactement ce qu'il me faut !

Les specs

Ce truc est capable de retourner en permanence la position et la rotation de 2 capteurs dans l'espace ... les six degrés de liberté ! 60 fois par seconde ! avec des pilotes Linux !

Sauf que après recherche, on trouve pas l'engin à moins de ... 2400 euros (et encore). Snif.

PS : si vous connaissez des moyens de financement pour des assos (ville, région, ...) ou des systèmes "amateurs" équivalents, je suis tout ouïe.

Pour des besoins "internes" (eeeerk) j'ai releasé un "pack" qui contient les applications Raydium de démo en version Windows, ce qui est assez rare pour que ça puisse intéresser du monde ici.

http://raydium.cqfd-corp.org/data/binary_packs/raydium-win32-binary-pack.zip (4 Mo)

Pour ceux qui n'ont pas peur, vous trouverez :
- Test6 (petit FPS de démo)
- Train (démo de scripting pour une création de train)
- Kinghill2 (un jeu de roi de la montagne en jeep)
- Raydium_Modler (un outil de gestion des exports)
- Skydiver (jeu complet de saut en parachute, avec scores en lignes, cf le site du jeu pour plus d'infos)
- Willou (un petit visualisateur de modèles)
- D'autres trucs que j'ai oublié

Je n'assure aucun support sur tout ça (perdez pas de vue que c'est destiné à un usage "interne"), donc pas de "mais y'a un bug dans tel jeu quand je fais ça" ou de "la texture à tel endroit est pas jolie", ... on est parfaitement au courant.

Je reste ouvert à toute remarque ou critique (avec plaisir, même).

Quelques pistes :
- Les applis sont trèèèèès longues à se lancer la première fois, puisqu'elles vont chercher leurs données sur le net. Attendez la fin du premier lancement, et relancez l'appli.

- Si vous vous mangez une erreur "openal32.dll" ou un truc du genre, lancez l'installation de l'installeur OpenAL, je l'ai laissé dans le répertoire (ça dure 2 secondes) : OpenALwEAX.exe

- Les applis sont gavées d'arguments sur la ligne de commande, si vous en avez besoin (ce qui me vient en tête, c'est déjà le "--fullscreen").

- Si vous avez déjà touché à PHP, vous devez avoir moyen de vous marrer un peu (cf la console [touche ²] qui est un interprèteur PHP, par exemple)

- 99% de ces applis fonctionnent en réseau, mais le pack ne propose par le serveur. Si vous deviez en avoir besoin, dizez le !

C'est tout, bonne chance pour réussir à faire tourner tout ce merdier :)

Pour faire de la réalité augmentée avec nos pauvres moyens, il faut déterminer les caractéristiques optiques de notre "matériel" de prise de vue, ici une webcam Philips Vesta Pro (modèle 680K, si ma mémoire est bonne).

J'ai fait une capture à 1 mètre de ma boite de Freebox et j'ai modélisé très vite la scène sous Blender, exporté tout ça au format Raydium (.tri) et écrit un tout petit programme dans lequel je change le niveau de zoom.



Le rendu est à gauche, la capture à droite. L'angle (approximatif) semble être de 28.5°, ce qui me semble très peu (ça commence à faire un sacré zoom).

J'ai testé d'autres méthodes, mais mes faibles capacités en maths m'interdisent de penser que les valeurs que je trouve de manière plus mathématiques sont correctes.

Avez vous une idée ou des informations qui pourraient me faire y voir un peu plus clair ?

Ceux qui suivent l'ont peut être remarqué lors du dernier article de ce blog : Raydium cherche des affinités avec la vidéo. Le but principal de cette démarche est de pouvoir, lors des présentations publiques de Raydium, offrir une interaction directe et plus fun auprès des "spectateurs".

En général, on souffre beaucoup de l'image relativement négative du jeu vidéo auprès de certaines tranches d'age, sans compter l'aspect passablement fermé du stand Raydium : une bande de gens, vraissemblablement très concentrés sur leur truc, autour d'un tas de machines. Sexy.

C'est là que la vidéo peut nous aider beaucoup, en complément de méchanismes de reconnaissance d'image, de réalité augmentée, ... pour proposer des interfaces intuitives, abordables et amusantes.

Avant d'arriver à ce niveau, il faut déjà que Raydium dispose d'une interface dédiée à la vidéo, intégrée de manière la plus transparente possible au reste du moteur. Et c'est cette première étape qui est sur le point de se concrétiser.

L'idée à été de séparer le problème de la vidéo-in-game en 2 domaines distincts :
- Ouverture d'un périphérique vidéo, configuration du périphérique, système de capture
- Modification d'une texture déjà chargée dans le matériel, à la volée

Le système porte le nom de live textures, et la partie capture va -évidemment- utiliser l'API live.

Histoire d'être bien précis (terre à terre ?), voilà la liste des fonctions intéressantes ajoutées à l'API de Raydium pour le sujet qui nous intéresse.


// "live"

// création d'une texture live depuis un device (voir la section vidéo en dessous)
int raydium_live_texture_video(int device_id, char *as);

// création d'une texture live depuis une image (à la responsabilité de l'utilisateur)
int raydium_live_texture_create(char *as, unsigned char *data_source, int tx, int ty, int bpp);

// callback à appeler à chaque changement de la source de données
void raydium_live_texture_refresh(int livetex);

// Partie chargée de la gestion des périphériques vidéo

// ouverture d'un périphérique, avec détails (ex: "/dev/video0",352,288)
int raydium_live_video_open(char *device, int sizex, int sizey);

// ouverture d'un périphérique, détection et configuration automatique
int raydium_live_video_open_auto(void);

L'utilisateur de cette API (simple, dans l'esprit Raydium donc) peut disposer d'un callback pour être informé de chaque arrivée d'une nouvelle capture depuis le périphérique vidéo, et ainsi mettre en place son système de reconnaissance d'image ou autre (cf images de l'article précédent).

Nous avons eu la possiblité de tester cette API hier soir, et dans une situation relativement poussée : 2 webcams (des Philips 680K, Vesta Pro) connectée à la machine de test, chacune associée à une texture.


FlexH, filmé par les deux webcams, après un subtil calibrage


Les deux Vesta, se filmant l'une l'autre


L'une filme l'écran, l'autre filme la première


Tentative d'image stéréoscopique, qui marche a peu près (attention, elle fait quand même un peu mal aux yeux :)

Toujours est-il que le test est concluant, et qu'il devient possible d'avancer maintenant vers les étapes suivantes de ce sous-projet, principalement vers deux pistes :
- Reconnaissance d'un marqueur (un pointeur laser, pour l'instant) pour agir sur l'image.
- Réalité augmentée, pour insérer des objets 3D (avec la gestion de la physique) sur un terrain réel filmé.

Ah, si vous avez des idées originales quand à l'utilisation de ce système, n'hésitez pas !

More to come ... (pour les curieux, toujours le site de Raydium)

... Une actualité débordande qui fait que j'ai du mal à assurer le contenu de ce blog. Bla, quelque part, c'est bon signe !


- Kinghill2 -


- Niveau pour Kinghill2 avec éclairage par radiosité -


- Une partie de l'équipe CQFD pour Scopitone 2005 -


- Une autre partie de l'équipe -


- Interview JetFM pour l'émission "le midi" -


- Test ragdolls (cf vidéo plus bas) -


- Je .. heu... je sais pas trop pourquoi je montre ça. Je crois que j'aime la prise de vue -


- Rocket flooding / Test6 modifié par Flex / Capture 3D depuis réseau puis prise de vue -


Test ragdoll : explosion.


Test ragdoll : mouvements (sort of).


Test ragdoll : chute.


J'espère que tout ça montre plus que des mots que je n'ai pas le temps de formuler en ce moment, à quel point le projet bouge.
Pour la suite, je compte bien vous faire un topo sur le festival Scopitone 2005 (Nantes / Rezé) au delà du lieu de jour auquel nous participions : grandiose !