Cahier des charges - 42Capture

Transcription

1 Cahier des charges - 42Capture Etienne Folio - Antoine Leblanc Andrei Pastramagiu - Christophe Vignix (Document recompilé) 23 avril 2006

2 Bref aperçu du contenu Table des matières 1 Introduction 3 2 Le projet Origine Nature Découpage du projet Acquisition du ux vidéo Traitement de l'image Calculs 3D Transmission des données Interface Le site web Répartition des taches 9 5 Conclusion 10 2 EpiMotion / 42Capture - Cahier des charges

3 Introduction Chapitre 1 Introduction Bonjour. Bienvenue dans le cahier des charges du projet 42Capture réalisé pendant l'année scolaire 2005/ Capture est une solution de motion capture qui sera créée par Etienne FOLIO, Antoine LEBLANC, Andrei PASTRAMAGIU et Christophe VIGNIX. Ce cahier des charges précise tous les éléments qu'il faudra développer an que ce projet aboutisse. Il met également en évidence tous les autres facteurs à prendre en compte pour la réalisation de celui-ci comme les moyens matériels, ou logiciels. Il contient également un planning qui servira à rythmer la réalisation des diérentes parties du logiciel an que celui-ci soit le plus about possible pour le mois de Juin. EpiMotion / 42Capture - Cahier des charges 3

4 Le projet Chapitre 2 Le projet 2.1 Origine Nous aimons tous les quatre les jeux vidéos et l'année passée chacun d'entre nous a été confronté aux joies et aux peines que la réalisation de l'un d'entre eux entraînait. Nous avons pu faire des choses plus ou moins compliquées et nous étions globalement satisfait de nos créations. Néanmoins nous étions limités par le temps et certaines choses sont restées inachevées... C'est pourquoi nous voulons continuer dans un domaine relatif aux jeux vidéos (mais pas exclusif) et comprendre une chose élémentaire : l'animation. Il nous est donc venu l'idée d'élaborer un projet de "motion capture". La motion capture est la technique moderne utilisé dans le milieu professionnel pour concevoir des animations complexes, nous envisageons de comprendre ce mécanisme pour pouvoir tout d'abord créer des animations de haute qualité, an de nous soustraire à la maîtrise de logiciels d'animations (comme 3ds MAX) et de ne pas pâtir de leurs limites ou inconvénients. 2.2 Nature Il s'agit donc d'un projet de Motion Capture développé sous Linux qui permettra, comme son nom l'indique, d'enregistrer le mouvement de personnes ou d'objets. Au moyen de plusieurs webcams et de marqueurs (Diodes electroluminescentes) placées sur ces entités, le logiciel acquierera le ux vidéo an de repérer les marqueurs sur les images traitées, et ce pour chaque webcam. Il eectuera la synthèse des données capturées pour nalement obtenir la position dans l'espace des marqueurs, et ce avec la plus grande précision possible. Ces opérations devront être eectuées le plus rapidement possible, an d'obtenir une uidité maximale. L'animation sera ensuite enregistrée en vue d'une possible utilisation ultérieure. Ce projet touche des domaines très variés, allant du plus profond du hardware avec la "retouche" de pilotes pour nos webcams sous Linux, jusqu'à la couche logicielle de l'interface incluant entre autres des scroll bars, du texte, 4 EpiMotion / 42Capture - Cahier des charges

5 2.2 Nature Le projet des options, des boutons entièrement codée à l'aide d'opengl pour X Window System (GLX). EpiMotion / 42Capture - Cahier des charges 5

6 Découpage du projet Chapitre 3 Découpage du projet 3.1 Acquisition du ux vidéo Cet aspect du projet sera le premier étudié, puisqu'il est une base du projet : sans acquisition, pas de traitement d'image. Le but est d'adapter les drivers existants pour les optimiser selon nos besoins. Nous aurons notamment besoin d'accéder aux réglages hardware de la caméra comme la luminosité, le contraste, l'obturation, etc... Certains aspects nous sont inutiles, comme le réglage automatique de la sensibilité ou la gestion de la LED sur la camera. Nous avons récupéré un driver gérant diérentes caméras, dont les nôtres, fait en C. Nous allons nous en inspirer pour recoder le notre. 3.2 Traitement de l'image Chaque image prise par les caméras devra être étudiée an de déterminer la position des marqueurs (LEDs), leurs mouvements (et donc leurs positions probables sur la prochaine image). Les calculs seront long et devront donc être optimisés au maximum ; l'analyse de chaque image suivra des étapes bien précises : - trouver les points : à partir son ancienne position et de son mouvement, on peut déterminer la position future probable d'une LED, ce qui optimise la recherche du marqueur. Si celle-ci est infructueuse, c'est que la LED a été cachée : ce cas est particulier et sera traité a part. - transformer en 3D : les images donneront la position en 2D des marqueurs. Le programme devra réaliser une interpolation pour déduire grâce à certains paramètres (position, orientation, angle de vue de la caméra) la position en 3D du point dans le repère. - acher, stocker : tout le traitement lourd aura lieu ici : créer un squelette à partir des points détectés, gérer l'occlusion des marqueurs indéterminés, enregistrer l'animation capturée dans une structure adaptée, acher le résultat... 6 EpiMotion / 42Capture - Cahier des charges

7 3.3 Calculs 3D Découpage du projet - préparer l'étape suivante : du mouvement et de la position à un instant t, on calcule la position probable des points à l'instant t + 1 pour optimiser la recherche suivante. 3.3 Calculs 3D Une très grosse partie de ce projet est basée sur des fonctions mathématiques poussées. L'une d'entre elles, l'une des pires, sera le calibrage automatique des caméras (même le stratosphérique YJD a avoué son ignorance!). Le but est de placer la caméra n'importe où, de lui donner un ou plusieurs repères (un cercle de LEDs au sol ou sur les murs par exemple) et que, par interpolation 3D, le programme détermine seul la position et l'orientation de la caméra. Le but est évident : gagner du temps à l'installation. Sans cet outil, chaque caméra doit avoir une place xe ; il faut mesurer au centimètre près sa position, au centième de degré près son orientation... Cette partie, nécessaire mais pas susante, sera peut-être l'une des plus ardues de l'année. 3.4 Transmission des données Un seul PC, même puissant, ne peut pas supporter la gestion de toutes les caméras, l'analyse de toutes les images, et tout le traitement. Notre but étant de faire une analyse très rapide, nous utiliserons plusieurs PC (portables) pour les caméras, et un pc seul (puissant) pour la synthèse et le traitement. Ceci nécessite donc l'existence d'un réseau ecace et rajoute une certaine complexité à un projet déjà dicile, mais pas impossible, à réaliser Interface Notre interface sera entièrement faite à l'aide d'opengl, pour des raisons d'ecacité. Vous allez vous dire "Antoine ne va quand même pas me bassiner encore un an avec ses foutues fenêtres?" ; eh bien rassurez vous ce ne sera pas pendant un an mais pendant quelques mois seulement... La grande diérence avec le projet Athalantar de l'année dernière se résume en deux points : l'expérience et la simplicité. Pas besoin d'avoir un interpréteur dynamique, "parsant" un script de conguration... Et l'expérience de l'année dernière nous fera économiser les mois consacrés à la réorganisation des structures de données, et à la découverte des outils de programmation. L'interface devra toutefois permettre de dénir un squelette, d'exporter ou d'importer des données structurées, d'avoir une gestion de menus... En gros d'être parfaite et complète! EpiMotion / 42Capture - Cahier des charges 7

8 Découpage du projet 3.6 Le site web 3.6 Le site web Il présentera nos avancées et listera les sources qui nous auront été utiles. 8 EpiMotion / 42Capture - Cahier des charges

9 Répartition des taches Chapitre 4 Répartition des taches EpiMotion / 42Capture - Cahier des charges 9

10 Conclusion Chapitre 5 Conclusion Pour des raisons économiques, il nous est impossible d'atteindre une qualité professionnelle. Dans le résultat de notre travail, l'innovation est d'être très bon marché tout en permettant un enregistrement de mouvements, nous l'espérons, de bonne qualité. Le budget d'un studio d'animation 3D n'étant pas le même que celui d'un utilisateur moyen, il est probable qu'on puisse trouver à ce projet toutes sortes d'applications destinées au grand public. Imaginez les sensations que provoqueraient des jeux vidéos dans lesquels les joueurs se verraient dans la peau du personnage : les mouvements du jeu correspondraient à ceux du joueur, permettant à certains jeux un réalisme inégalé. Imaginez encore un ordinateur muni d'un système de ce genre : de simples mouvements de bras suraient à sélectionner des objets et à les déplacer. Tous les créateurs de science ction ont rêvé de ce genre de possibilités, aucun projet grand public n'a jamais vu le jour (en général pour des raisons de budget). Notre projet, bien que modeste, semble un pas vers l'utilisation plus générale des techniques de capture de mouvements. Les capacités des machines actuelles ne nous permettront probablement pas (quelque soit le degré d'optimisation de notre programme) de calculer les positions d'un grand nombre de marqueurs en simultané avec un seul ordinateur, limitant ainsi les applications de notre programme. Celui-ci ne sera qu'un aperçu de ce que seront peut-être les moyens de saisie de demain. 10 EpiMotion / 42Capture - Cahier des charges