Dessin 3D : Différence entre versions

Version du 4 mars 2015 à 21:57

Cahier des charges

Présentation générale du projet

Objectif

Le but du projet consiste à réaliser un système de dessin en 3 dimensions dans un environnement de réalité virtuelle.

Contexte

Le projet s'inscrit dans une collaboration avec l'équipe MINT de l'IRCICA. L'objectif de l'équipe consiste à rechercher de nouvelles méthodes d'interaction Homme - Machine. Le système aurait avant tout un objectif artistique, en l'occurence le dessin de lignes sur un fond neutre. Cependant il est possible d'imaginer d'autres applications, comme par exemple utiliser ce système avec la Réalité Augmentée ou dans la conception de bâtiments pour l'architecture.

Description du projet

Le projet consiste en le développement d'une application qui utiliserait les données d'un système de suivi de mouvements pour enregistrer les gestes d'un utilisateur. Ces données seront alors utilisées pour générer des lignes dans un environnement virtuel. L'utilisateur étant muni d'un Oculus Rift, il pourra alors voir en temps réel les dessins qu'il crée avec ses gestes.

Si cette étape du projet est achevée rapidement, d'autres options pourront éventuellement être mises en place, comme par exemple une méthode de sélection de l'épaisseur du trait.

Choix techniques

Matériel

Le matériel incontournable est un casque de réalité virtuelle. Dans notre cas nous utiliserons l'Oculus Rift. L'autre grosse partie de ce projet consiste à réaliser un suivi de position des mains de l'utilisateur.

Pour ce faire, nous avons pensé à différents éléments de réponse :

• Un suivi basé sur l'utilisation d'une ou plusieurs Kinect : on suit un point défini par la main de l'utilisateur de manière distante.

• Utilisation de WiiMote : on utilise les accéléromètres pour calculer les variations de position. Cette méthode donnerait probablement des résultats moins précis.

• Utilisation d'une caméra de suivi comme la caméra Pixy.

La solution retenue est celle proposée par M. Grisoni qui est le système AR-Track. Comme ce matériel est performant et disponible à l'IRCICA, les autres solutions envisagées ont alors été abandonnées.

Logiciel

Pour le développement logiciel, nous utiliserons les SDK des caméras AR-Track et de l'Oculus Rift.

Le choix du moteur graphique pour la génération de l'environnement 3D de l'Oculus Rift s'est porté sur Unity. En effet, les personnes s'occupant de la post production des dessins travaillent avec ce moteur graphique. De plus, il est plus facile d'utiliser Unity que de programmer sous OpenGL.

Étapes du projet

Étape 1

☐ Prise en main du SDK des caméras AR-Track.
☐ Génération d'un fichier .xml contenant des données de positions et de temps d'un mouvement.

Étape 2

☐ Prise en main du SDK d'oculus Rift.
☐ Génération des premiers graphismes avec Unity.

Étape 3

☐ Apport d'améliorations au système minimal selon les besoins

Présentation du dispositif

Le système est composé de deux composants majeurs à savoir l'ensemble de caméras AR-Track et un Oculus Rift.

Les caméras AR-Track sont des caméras qui, grâce à plusieurs images en deux dimensions, permettent de suivre la positions de plusieurs points. Evidemment, le nombre de caméras influe grandement sur la qualité et l'efficacité de ce tracking. Les caméras émettent des flashs de lumière infrarouge, qui sont réfléchis par les marqueurs, permettant ainsi d'obtenir une image en deux dimensions pour chaque caméra. Les données sont alors traitées par un ordinateur pour reconstituer les données des 6 degrés de liberté, c'est à dire 3 translations et 3 rotations (DOF : Degree Of Freedom).

Vue d'ensemble du dispositif

Les données en sortie peuvent alors être récupérées par Ethernet. Elles sont transmises par le protocole UDP sur le port 5000. Il suffit alors d'écouter le port avec un deuxième ordinateur pour récupérer ces données. On peut alors retravailler les informations de la manière que l'on veut.

Marqueurs pour le suivi de l'ensemble de la main

On utilise le dispositif ci-dessus pour traquer les mouvements de la main.

Après cela, on utilise les données pour construire l'environnement virtuel de façon dynamique avec Unity. Le programme pourra alors être utilisé pour faire l'affichage directement sur l'Oculus Rift.

L'Oculus Rift est un casque VR (Virtual Reality : Réalité Virtuelle). Il permet de visualiser un espace en 3D et de pouvoir d'y déplacer dedans. Dans notre cas le point de vue sera fixe, mais il sera possible de pouvoir voir tout autour. Il n'y aura donc que 3 degrés de liberté, à savoir 3 rotations.

Suivi de l'avancement du Projet

Semaine 1 (26/01/2015)

Nous avons pris rendez-vous avec M. Grisoni, et avons pu le rencontrer, ainsi que l'artiste Pauline De Chalendar et ses encadrants, le mercredi après midi. Nous avons alors discuté pour arriver à transcrire de manière technique les souhaits artistiques de Mlle. De Chalendar, et ainsi commencer à envisager des solutions techniques.

La principale requête est de pouvoir enregistrer l'aspect temporel du dessin, et non seulement la finalité. Cela aura pour but de visualiser en temps réel la création de l'oeuvre.

La question qui s'est posée est celle du format de fichier qui contiendrait les données de position. Le format de fichier qui a été déterminé est alors le .xml.

Semaine 2 (02/02/2015)

Fait : Nous avons pris en main le logiciel DTrack, utilisé pour récupérer les informations des caméras. Les différentes caméras sont reliées entre elles par un câble BNC permettant leur synchronisation. Elles sont aussi reliées par Ethernet à un ordinateur sur lequel le logiciel va calculer les informations sur les 6 degrés de liberté (3 translation et 3 rotation) des différents points suivis.

Le logiciel permet une sortie des informations sur le réseau via un câble ethernet. Nous avons donc configuré une autre machine afin de communiquer avec le premier ordinateur. Nous avons pu ainsi observer que la transmission se faisait bien grâce au logiciel WireShark. Il nous a fallu donc ensuite récupérer et interpréter ces données pour pouvoir récupérer les informations de position. Ceci se fait de façon relativement simple avec un programme C communiquant en UDP avec l'ordinateur.

Le système de coordonnées est pour l'instant un système orthonormé classique, formant un trièdre direct. C'est à dire (le point d'origine étant la personne traquée) :

• Axe X : Dans le sens de la largeur, vers la droite

• Axe Y : Dans le sens de la hauteur, vers le haut

• Axe Z : Dans le sens de la profondeur, vers l'arrière

Ce système peut être amené à changer, notamment pour la compatibilité avec d'autres logiciels en l'occurence Unity.

Il reste à mettre en forme ces informations selon la nomenclature suivante :

timestamp line_type line_x line_y line_z head_x head_y head_z head_dir_x head_dir_y head_dir_z

Avec :

• timestamp : temps en sec (précision 3 chiffres après la virgule = 1 ms) depuis le début de l'enregistrement de la séquence

• line_type : 0 (pas de ligne), 1, 2 ou 3 (ligne fine, moyenne ou épaisse)

• line_x/y/z : coordonnées en mètres (précision 3 chiffres après la virgule = 1 mm) de la "pointe du bic" dans l'espace, par rapport à l'origine de la scène 3D, à définir.

• head_x/y/z : coordonnées en mètres (3 chiffres après la virgule) de la tête (position caméra de l'oculus rift) dans l'espace, par rapport à l'origine de la scène 3D, à définir

• head_dir_x/y/z : coordonnées xyz d'un vecteur normalisé (longueur 1 mètre) qui indique l'orientation de la tête (direction dans laquelle l'oculus rift).

Pour ce qui est de la fréquence d’échantillonnage, l'idéal serait 60Hz. Sinon, 30Hz pourrait être suffisant. Ces informations seront enregistrées dans un fichier .txt. Elles pourront aussi être affichées sur l'écran, peut-être à une fréquence réduite, pour pouvoir suivre le bon déroulement de l'acquisition.

Semaine 3 (09/02/2015)

Nous avons prévu d'aller au Fresnoy afin de pouvoir situer le contexte dans lequel sera mis en place notre projet.

A faire : Prendre en main le SDK des caméras AR-Track et enregistrer les informations de position et de temps pour chacun des points suivis. Générer un premier fichier qui servira de base d'enregistrement des informations. Ce fichier test sera envoyé à la post production pour vérifier que l'édition puisse se faire. Le format retenu pour l'instant est le .xml.

Fait :Nous avons réussi à écrire dans un fichier .txt à l'aide d'une application codée en C qui reçoit directement les paquets UDP. Cette application écrit donc directement les coordonnées dans un fichier tout en les affichant à l'écran.

Nous sommes allé au Fresnoy le jeudi afin de tenir une réunion avec Pauline De Chalendar, les artistes et Xavier Wielemans le programmeur qui travaillent avec elle. Nous avons principalement discuté de la finalité du projet, mais nous avons également parlé des logiciels allant être utilisés afin d'arriver au résultat escompté. Nous nous sommes fixé sur Unity pour plusieurs raisons : c'est un moteur graphique polyvalent et relativement simple à mettre en place, il existe un plugin pour Oculus Rift et Xavier Wielemans à l'habitude de travailler avec cet outil.

Les scripts étant écrits en C# sous Unity, nous avons alors décidé d'essayer d'intégrer le code C pour la communication UDP à un fichier C#. Après plusieurs tests et essais, comme cela était trop compliqué à mettre en oeuvre, nous avons décidé de re-coder le client UDP en C# afin de faciliter son intégration à Unity.

Nous avons également réussi à générer les premiers graphismes sous Unity, ainsi que créer des scripts de base.

Semaine 4 (16/02/2015)

Fait : Nous avons réussi à reprogrammer le serveur UDP en C#. Cela nous permet au passage d'implémenter une interface graphique, rendant le programme plus facile d'utilisation.

Nous avons également incorporé une fonction de traitement qui permet de mettre en forme les données suivant le template demandé. La détermination du type de ligne est aussi implémentée. Tout cela est prévu d'être testé la semaine prochaine. Il faudra également vérifier que la vitesse de traitement soit suffisamment rapide pour traiter les données de façon instantanée. En effet cette semaine, nous avons pu observer un retard s'accumulant sur la durée. Cependant la cause est probablement identifiée : à chaque itération de la boucle récupérant les informations, nous faisons un affichage de données dans la Console du logiciel de développement. Ce problème est par conséquent très simple à corriger.

Nous avons généré un environnement 3D sous Unity simple. Nous avons ensuite intégré l'Oculus à cet environnement. Pour cela, nous avons télécharger le SDK Oculus qui permet de l'utiliser sous Unity, puis nous avons intégré les différents objets (caméra, joueur...) nécessaire à l’immersion du joueur dans l'environnement précédemment créé. Nous avons rencontré un problème sur la version de Unity que nous avions installé : elle ne permettait pas de vois à la foi à travers l'Oculus, et sur l'écran de l'ordinateur. Pour palier ce problème nous avons étendu l'affichage, et nous affichons alors le rendu sur la partie réservée à l'Oculus.

Semaine 5 (23/02/2015)

A faire : Prendre en main le SDK de l'Oculus Rift et Unity pour réaliser une première version très basique de l'application. Seule la fonction de dessin de ligne sera implémentée.

Fait : Le serveur UDP est finalisé. Nous avons réussi à générer un fichier texte contenant les informations suivant la nomenclature décrite précédemment, à la différence que nous avons ajouté en premier champ le numéro de frame. Nous obtenons alors :

frame timestamp line_type line_X line_Y line_Z head_X head_Y head_Z head_dir_X head_dir_Y head_dir_Z

Vous pouvez consulter ce fichier en suivant ce lien : Fichier:Outputsav.txt. De plus, le programme marche sans latence. Nous arrivons à récupérer les données à la vitesse ou les caméras les transmettent. Finalement, malgré l'utilisation des capteurs pour les doigts, la fréquence de rafraîchissement n'est pas réduite. Nous pourrons travailler à 60 Hz sans problème.

Nous avons aussi revu la structure de notre code afin d'en améliorer la portabilité.

Semaine 6 (09/03/2015)

Semaine 7 (16/03/2015)

Semaine 8 (23/03/2015)

Semaine 9 (30/03/2015)

Semaine 10 (06/04/2015)

Semaine 11 (13/04/2015)

Semaine 12 (20/04/2015)