Outils de maquettage virtuel

Matthias De Bie - Pierre-Jean Petitprez

Présentation

Objectif

En collaboration avec l'équipe de recherche MINT (IRCICA/LIFL), l'objectif du projet est de développer, en se basant sur un échantillon de code déjà fourni, des outils simples et avec un nombre de commandes réduit permettant d’interagir avec des applications d'édition de géométrie. Cette application sert à créer une couche supplémentaire entre le SDK ThreeGear et toute autre partie responsable de l'affichage de la géométrie. Elle se présente sous forme d'un outil générique qui doit permettre d'interfacer les flux du SDK ThreeGear avec Unity dans un premier temps. Ensuite, notre système doit pouvoir fonctionner avec n'importe quelle source d'entrée (Kinect, Leap Motion, ...) et permettre la réalisation d'applications Unity dans la plus grande transparence et sans dépendance avec la source d'entrée.

Matériel requis

En raison de l'utilisation de code déjà écrit, il est nécessaire de reprendre les mêmes outils.

• Utilisation du moteur Unity[1] : requiert Microsoft Windows
• Bibliothèque ThreeGear[2] permettant d'utiliser une Kinect et de faire du hand tracking : requiert un système 64 bits
• une caméra Microsoft Kinect

Les 2 Kinects empruntées en salle de projet ont été restituées le 24/02/2014.

Pilotes et logiciels requis

• Installation des librairies et pilotes requis :
  • Java SE[3]
  • ThreeGear SDK[4]
  • OpenNI 1.5.2.23 64-bit[5]
  • NITE 1.5.2.21 64-bit[6]
  • SensorKinect 5.1.0.25 64-bit[7]
  • Calibration de la caméra et lancement du serveur avec les scripts camerasetup.bat et handdriver.bat (nimble_server.bat depuis la version v0.9.32)
  • Unity 3D
  • Microsoft Visual Studio
  • POSIX Threads for Win32[8] (pthreadVC2 : placer la ddl dans C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\amd64)
  • Bibliothèque mathématique Eigen[9]
  • Bibliothèque Asio[10] pour la programmation réseau

Rendu

• Rapport de projet en PDF : Fichier:Maquettage virtuel Matthias DeBie PierreJean Petitprez.pdf

Gestion de Projet

Semaine 1

Choix des projets

Semaine 2

Réunion avec le professeur encadrant le mercredi 18 septembre : description de l'état de l'art, définition des attentes et des besoins, définition des choix technologiques.
Mise en place des outils sur PC personnel, l'idéal serait de pouvoir également travailler sur un poste fixe en salle de projet : nécessité d'installation de Windows 64 bit sur un poste.

Semaines 3 et 4

Interfaces Unity et ThreeGear

Prise en main du SDK ThreeGear et de la scène Unity fournie, après la phase d'installation plutôt longue mais documentée. Demande d'une licence académique chez ThreeGear (validité : 12 mois).

Problématique : la caméra Kinect doit se trouver à une certaine hauteur au-dessus du plan de travail (de l'ordre de 1 m), en étant le plus horizontale possible afin de bénéficier de la meilleure détection des mains possible.

Première étape : analyser et s'approprier le début de code fourni sous Unity. Repérer les différents flux d'entrée provenant de ThreeGear.

Deuxième étape : Créer une application en C++ indépendante de Unity qui récupère le flux de sortie de ThreeGear et l'interprète.

Semaines 5 et 6

La phase de code débute réellement, avec l'écriture d'une application C++ qui reçoit les informations provenant de ThreeGear par TCP. La protocole déjà écrit dans l'application Unity en C# est à réécrire complètement en utilisant les conventions C++.

Semaine 7

L'utilisation de l'API ThreeGear se révèle assez fastidieuse car la documentation se limite aux headers des exemples C++.

Semaines 8 et 9

Nous avons développé une application qui récupère les messages de ThreeGear et qui les envoie tels quels à l'application Unity (sur protocole TCP). Les messages de configuration (Welcome et User) sont sauvegardés afin que la connexion des différentes parties puisse être indépendante.
On ouvre une socket TCP entre le serveur ThreeGear et notre application sur le port 1988 (port par défaut de ThreeGear). Ensuite une deuxième socket est créée entre notre application et le client Unity sur le port 1989.

Semaine 10

La prochaine étape est de repérer les messages provenant de ThreeGear et contenant les points remarquables comme les bouts des doigts, ou le centre de la main, ce qui va permettre de reconnaître de nouveaux mouvements et de nouvelles positions.

Semaine 11

En utilisant les coordonnées des bouts des doigts nous essayons de repérer les amplitudes de déplacement pour chaque doigt entre chaque réception. De cette manière nous pourrions savoir quand survient un mouvement d'un doigt. Pour y parvenir nous utilisons un singleton de manière à mémoriser les valeurs des coordonnées.

Semaine 12

Premiers tests de détection de geste : à partir d'un certain angle phalange - métacarpe défini par la soustraction de 2 positions, on affiche quel doigt de quelle main a été détecté

Nous récupérons les coordonnées d'autres points remarquables des mains : bouts des doigts, articulations, et poignet. Ces 2 derniers sont stockés par ThreeGear dans une matrice afin d'être utilisés pour le skinning des mains. Nous devons donc les extraire.
Grâce à ces différents points nous pouvons calculer l'angle formé par les doigts par rapport au plat de la main, c'est-à-dire l'angle que forment les phalanges avec les métacarpes.

	/*
	*
	*	     B __________ C
	*	   /
	*	 /
	*      /
	*    A
	*
	*/
        AB : phalange
        BC : métacarpe

Cependant depuis que nous avons ajouté ces fonctionnalités, nous rencontrons un problème de réception des messages TCP avec Unity : l'analyse syntaxique des messages ne se déroule pas correctement. Il nous faut donc trouver d'où vient le problème et le résoudre.

Compte-rendu de réunion du 28 Novembre

Plusieurs points ont été abordés et notre vision du projet a donc été mise à jour. Voici la liste des points abordés :

• Utiliser la bibliothèque EIGEN pour la gestion des matrices, vecteurs, quaternions, ... De manière à ne pas dépendre de la bibliothèque de ThreeGear.
• Modifier la détection des signes pour être pris en compte dans le référentiel de la main de manière à ce que les signes ne soient pas mal interprétés lorsqu'une main bouge dans l'espace.
• Implémenter des Observer, un design pattern (Patron de conception) qui nous permet de moduler la partie détection du mouvement. Pour chaque signe à détecter on implémentera un Observer qui possédera une méthode update et qui prendra en argument seulement les "input" indispensables.
• Pour chaque geste reconnu, définir une probabilité pour ce geste.
• Détecter les mouvements en se basant sur une temporalité indépendante de la vitesse du flux d'informations.
• Possibilité, selon l'application, de réduire l'échelle d'observation : par exemple, si une application requiert les 10 doigts, observer les 10 doigts, mais si une application requiert uniquement les index, observer uniquement les index et oublier les autres doigts.
• La démonstration de l'outil pourrait se faire sous la forme d'une application Unity simple présentant les différents gestes.

Il s'avère que le projet devient un peu plus précis et défini.

Semaine 13

Nous adaptons le développement de notre outil en fonction des remarques formulées lors de la dernière réunion.
Nous rencontrons des problèmes pour utiliser la bibliothèque boost qui permet de créer des threads. En effet, l'édition des liens se fait difficilement avec Visual Studio, la configuration est fastidieuse. Afin d'éviter de perdre trop de temps sur le sujet, nous prévoyons d'utiliser la bibliothèque pthread à la place.

Semaine 14

Suite à la réunion du 10 décembre

• Restructuration de l'architecture logicielle :
  • Création de projets dans Visual Studio séparant chaque fonctionnalité (écoute de ThreeGear, outils de connexion TCP, gestion de la reconnaissance de gestes, programme principal)
  • Mise en place de l'observateur "principal" qui récupère toutes les informations spatiales des points du squelette des mains à partir de ThreeGear.
• Portage des calculs de matrices et vecteurs utilisant initialement les types de ThreeGear vers les types de la bibliothèque Eigen[11].
• Mise en place de la structure servant à stocker nos données. Il s'agit d'une classe qui contient les données spatiales pour chaque jointure des deux mains. Cette classe est mise à jour par un observateur à chaque réception d'un message.

Semaines 15 - 16 (Vacances de Noël)

Scène Unity de travail pour la mise en place des interactions

Les points à travailler pour les vacances :

• Le serveur TCP. Celui-ci est désormais 100% fonctionnel grâce à la création d'un thread dédié (en utilisant la bibliothèque POSIX Threads Win32 [12]).
• Le changement de repère (repère global -> repère de la main) apparait plus compliqué que prévu, notamment car il faut créer le nouveau repère à partir de vecteurs non orthogonaux et de normes différentes. La nouvelle base, non orthonormée, rend difficile la mise en place d'une matrice de changement de base.

Semaines 17 - 20

Planning ralenti à cause des modules transversaux.
Les pistes majeures de travail :

• Reconnaissance de gestes de base :
  • "tap" d'un doigt / de la main (doigt : fonctionnel / main : à implémenter)
  • "pointing" d'un doigt (index) (fonctionnel, seuils de détection à vérifier)
  • "swipe" de la main (balayage horizontal de la main pour changer de menu par exemple) (à implémenter)
  • "pinch" (l'index et le pouce rapprochés comme pour attraper quelque chose) (seuils à vérifier et précision à améliorer)
• Mise en place de mutex pour les ressources partagées, utilisant la bibliothèque POSIX Threads Win32 [13]
• Développement de l'application graphique sous Unity :
  • Création d'un client TCP de réception des messages de gestes en parallèle du client recevant les informations de ThreeGear (utilisées pour la modélisation 3D des mains)
  • Création d'une scène 3D contenant une piste et une boule, dans le but de la faire bouger le long de la piste avec la main.

Semaines 21 - 24 (sprint final)

Semaine 21

Installation d'un poste à l'IRCICA pour démonstrations. Le SDK ThreeGear est mis à jour de la version v0.9.30 à la version v0.9.32. Cette nouvelle version apporte beaucoup sur la fiabilité et la rapidité des détections. Unity passe de la version 4.2 à la version 4.3, nous profitons de la grosse phase de mise à jour pour également mettre l'application Unity à jour.

Nous avons implémenté deux façons de détecter un "pinch" (pincement du pouce avec l'index) :

• En mesurant la différence entre les coordonnées du bout de l'index et celles du bout du pouce. Cela fonctionne tant que la main est perpendiculaire à la caméra, ce qui devient peu fiable dans une utilisation en position "normale" (le dos de la main pointant vers le bas)
• En récupérant les pinchs détectés par ThreeGear en amont de notre brique. ThreeGear utilise une bibliothèque de gestes pré-enregistrés pour comparer et détecter les gestes les plus probables, la détection du pinch est donc très fiable. Nous l'utilisons donc pour améliorer les résultats. Cependant si l'application doit être utilisée avec un autre système de tracking, l'autre technique de détection de pinch sera utilisée.

A noter qu'un pincement avec le pouce et un autre doigt que l'index (par exemple le majeur) est également détectable, il nous suffit de passer le doigt concerné en paramètre de l'observateur à la place de l'index.

Semaine 22

Travail planifié pour cette semaine :

• Réussir à brancher 2 caméras sans qu'elles n'entrent en conflit l'une avec l'autre. L'une doit être utilisée pour ThreeGear, l'autre ne doit pas être reconnue par ThreeGear et doit servir pour le suivi de la tête de l'utilisateur. En effet, un nouvel objectif nous a été confié : comment faire en sorte que la caméra de la scène Unity coïncide avec le point de vue de l'utilisateur lorsqu'il regarde cette scène sur la table tactile.

Au final nous utilisons deux PC, ce qui résout un grand nombre de problèmes : deux applications Unity ne peuvent pas tourner sur un même poste (seule celle en premier plan est active, l'autre se met en pause), deux caméras Kinect ne peuvent pas être branchées au même poste si leur utilisation est différente.

• Donner la possibilité de paramétrer des courbes de type NURBS dans Unity. Cela servirait à définir des trajectoires de déplacement.

Visualisation d'une courbe de Bézier cubique (d'ordre 3)

Courbe de Bézier

La première étape est de savoir comment représenter une courbe de Bézier, qui est un cas particulier de NURBS. Une courbe d'ordre 3 semble appropriée car avec 4 points de contrôle, on peut obtenir des courbes suffisamment complexes tout en gardant un calcul simple.
Une fois la représentation choisie (les coordonnées en 3 dimensions de chaque point de contrôle sur une ligne d'un fichier qui est lu par le script), les autres étapes sont les suivantes :

• savoir modéliser en 3 dimensions cette courbe au lieu d'une simple visualisation dessinée. Pour ce faire nous créons des cylindres procéduralement (autrement dit grâce à un algorithme) : positionnés entre deux valeurs d'échantillonage de la courbe, si l'échantillonage est sufisamment petit, la chaîne de cylindres donne l'impression qu'il s'agit d'une vraie courbe.
• faire en sorte que le "curseur de progression" se déplace le long de cette courbe ; pour cela il faut :
  • savoir calculer le point le plus proche de la courbe à partir du bout du doigt
  • modifier la translation et la rotation de l'objet représentant le curseur en fonction de la direction donnée par la courbe.

La plus grosse difficulté ici fut de mettre en place un algorithme de calcul de projection du point indiqué par le bout du doigt, et qu'il faut projeter sur la courbe. Nous utilisons un algorithme de "détection du point le plus proche", adapté depuis les articles Solving the Nearest Point-on-Curve Problem et A Bezier Curve-Based Root-Finder de Philip J. Schneider (Graphics Gems, Academic Press, 1990) dont des exemples pour C++ et ActionScript sont disponibles sous licence libre.

L'effet de 3D sans stéréoscopie

Vue conceptuelle de l'installation prévue. L'hexaèdre aux contours blancs montre le principe de déformation du frustum de la caméra, virtuellement placée au niveau de la tête de l'utilisateur.

Une application développée par Bruno De Araùjo, membre de l'équipe MINT et notre intervenant technique sur le projet, utilise une table tactile sur laquelle l'utilisateur peut manipuler des objets 3D qu'il voit réellement en 3D grâce à l'utilisation de la stéréoscopie : deux images sont calculées, une pour chaque oeil, et l'utilisateur possède des lunettes permettant à chaque oeil de ne voir que l'image qui le concerne. Pour notre projet, l'utilisation d'équipements tels que des lunettes 3D semble inappropriée. C'est pourquoi nous nous basons sur un travail réalisé par Bruno De Araùjo pendant sa thèse, et qui consiste à adapter la frustum de la caméra de la scène 3D en fonction de la position de l'utilisateur.
Il s'agit d'un calcul mathématique plutôt complexe, qui nécessite de bien comprendre de principe des matrices de transformation et la succession des transformations effectuées lors de l'affichage d'une scène 3D.

Semaine 23

Nous travaillons à temps complet sur les applications Unity, au nombre de deux : une "principale" qui gère la réception des différentes informations (en provenance de ThreeGear, de notre brique C++ et d'un module développé par l'équipe MINT permettant un tracking de la tête de l'utilisateur) et une secondaire qui affiche du contenu artistique en relation avec la position de la caméra.
Afin de rendre les scènes plus attrayantes, nous avons téléchargé des modèles 3D de bâtiments libres de droits à partir du magasin en ligne de Unity. Avec quelques modifications réalisés par nous-mêmes (ajout de textures pour améliorer l'esthétique), nous obtenons une scène de style médiéval parfaite pour nos démonstrations.
Globalement, à la fin de cette semaine, nous avons répondu au cahier des charges : notre application est fonctionnelle et dispose des fonctionnalités indispensables. Nous avons défini un prototype d'installation ainsi que les différentes étapes pour la mettre en place : positions des différentes caméras, étapes de calibration et de mise en route de l'application.

Semaine 24

Semaine finale : rendu du rapport et soutenance. Nous rendons définitivement le travail que nous avons réalisé.

Technologies

Protocole de fonctionnement

Schéma de description par blocs des différents modules

Notre brique se décompose en plusieurs blocs, dont la dépendance de l'un à l'autre est réduite au minimum pour disposer d'une architecture modulaire simple à modifier et à compléter.

Réception des informations de tracking

A l'entrée nous récupérons les informations qui nous sont envoyées par le système de tracking utilisé. Pour le moment nous utilisons exclusivement le SDK ThreeGear, qui se compose d'un serveur TCP qui envoie les messages décrits ci-dessous, et d'une partie réception que nous avons incorporé dans notre application. Le port par défaut est le port 1988. Le client de réception est lancé à partir de notre fonction main, dans thread dédié.
La sortie de ce bloc est une structure contenant toutes les coordonnées des articulations des mains :

• "root" (un point commun à toute une main et légèrement en retrait du poignet)
• poignet (commun à toute une main)
• Points uniques à chaque doigt :
  • articulation carpo métacarpienne (pouce uniquement)
  • articulation métacarpo phalangienne
  • articulation interphalangienne proximale
  • articulation interphalangienne distale (index, majeur, annulaire, auriculaire uniquement)
  • bout du doigt (finger tip)

cf les os de la main.

Peuplement des données

A chaque mise à jour envoyée par le handtracker, nous mettons à jour les données. Nous recevons les articulations sous forme de coordonnées dans l'espace en 3 dimensions. Afin de réaliser des calculs dans un repère local à la main au lieu du repère global, nous transformons ces coordonnées : chacune des mains possède un repère qui lui est propre, et les coordonnées des articulations de chaque main exprimées dans ces repères permet de se concentrer uniquement sur des mouvements de doigt et non des mouvements de la main complète par exemple.
Les coordonnées sont exprimées en millimètres et rangées dans une matrice dont la taille est dépendante du nombre de points fournis par le handtracker, mais globalement ce nombre est sensiblement le même car la majorité des systèmes de hand tracking se basent sur les mêmes articulations.
Nous sauvegardons les coordonnées sur un certain historique (par défaut 10 mises à jour), et grâce à un chronomètre nous pouvons ainsi connaitre la vitesse de déplacement et son accélération de telle ou telle articulation.

Appel des observateurs de geste

Lorsque la structure de données est mise à jour, les observateurs sont notifiés. Il existe un observateur par type de geste à reconnaitre : un observateur de pointé de la main droite, un autre de pointé de la main gauche, un observateur de clic de l'index droit, de l'index gauche, ...
Une fois notifié, chaque observateur va vérifier grâce aux coordonnées des points si le geste pour lequel il est programmé a été réalisé ou non. Si le geste a été reconnu, un objet de type "Message" est créé, contenant toutes les informations nécessaires : nom du geste, doigt ou main concerné(e), coordonnées des points utiles ... Ce message est ensuite dirigé vers le serveur TCP pour envoi vers l'application graphique.

Communication avec l'application graphique

Pour communiquer avec l'application graphique développée sous Unity, nous utilisons le protocole TCP. Un serveur est implémenté grâce à la bibliothèque Asio. Le client (l'application Unity) se connecte alors dessus.
Les messages à envoyer au client sont stockés dans une file d'attente de type "FIFO", au cas où plusieurs gestes auraient été notifiés simultanément. Lorsqu'un message est présent dans le file d'attente, celui-ci est récupéré, supprimé de la liste, et envoyé par TCP. Puis le serveur repasse en attente de message.
Du côté client, nous récupérons ce message et nous le décodons pour récupérer les arguments concaténés après le nom du geste reconnu. Ceci nous permet d'agir en conséquence dans l'application.

Application graphique

L'application graphique, développée sous Unity, reçoit les messages envoyés par le serveur. En fonction du message reçu, des actions interagissent avec la scène. Par exemple, si l'utilisateur pointe la balle du doigt, celle-ci devient "sélectionnée" et se déplace alors en fonction du déplacement du doigt.

ThreeGear

ThreeGear est un système de captation de mouvement destiné à récupérer les positions ainsi que l'orientation des mains de l'utilisateur, il peut aussi interpréter quelques poses basiques (en utilisant notamment les 10 doigts) telles que la saisie et le pointé.

Données transmises

Données de base

ThreeGear utilise une connexion TCP. Il faut donc utiliser un client pour se connecter et recevoir les informations. Celles-ci ne sont pas brutes car elles sont déjà typées d'une certaine manière : nous récupérons des messages de types différents :

• WELCOME : reçu lors de l'établissement de la connexion TCP, contenant les informations de version et de protocole
• USER : reçu juste après WELCOME, contient les informations relatives à l'utilisateur telles que le maillage 3D des mains
• CALIBRATION : envoyé lorsque l'utilisateur adopte une pose de calibrage (mains tendues à plat)
• POSE : le message le plus utile pour nous car il contient les coordonnées spatiales des jointures des mains. Ce message est envoyé lorsqu'une modification de la pose des mains est détectée.
• INVALID_DATA
  

Les messages suivants indiquent des poses particulières déjà reconnues par ThreeGear :

• PRESSED : pincement de l'index et du pouce
• DRAGGED : déplacement de la main pendant un pincement
• RELEASED : relâchement du pincement
• MOVED : déplacement de la main sans placement
• SIMULTANEOUSLY_PRESSED : pincement réalisé aux 2 mains simultanément
• INDIVIDUALLY_PRESSED : pincement réalisé uniquement sur 1 main
• SIMULTANEOUSLY_RELEASED : pincement des 2 mains relâché simultanément
• INDIVIDUALLY_RELEASED : pincement relâché à une seule main
• DRAGGED_BIMANUAL : déplacement des 2 mains pincées
• POINT : l'utilisateur pointe avec son index

Messages traités

Nous utilisons presque exclusivement les messages de type POSE, car ce sont eux qui contiennent les coordonnées spatiales du squelette. Les autres messages sont des interprétations propres à ThreeGear, ce qui est incompatible avec le principe même du projet : la plus grande compatibilité possible entre les différents systèmes.
Néanmoins, dans un souci de fiabilité et étant donné que dans un premier temps seul ThreeGear sera utilisé dans le projet final, nous réutilisons les messages d'indication de pincement (que nous traduisons tout de même en message générique) car la pertinence de détection de ce geste par ThreeGear est meilleure que notre implémentation personnelle.

Limitations

Ce système n'est pas générique, dans le sens où il s'appuie sur une base de données pour reconnaitre des mouvements. Des poses et mouvements ne faisant pas partie de la base de données de ThreeGear ne peuvent pas être utilisés car ils ne seront pas reconnus. C'est pourquoi l'idée du projet est de rendre plus générique ce système.

Patrons de conception (Design patterns)

Singleton

Afin de résoudre les problèmes d'accès à une variable dans les différents threads de l'application (partie client, partie serveur), il est nécessaire d'utiliser une variable "globale". En C++, nous utilisons une classe qui contient les différentes variables nécessitant d'être accessibles partout. Or, cette classe ne doit être instanciée qu'une fois dans tout le programme. C'est pourquoi nous utilisons le pattern Singleton qui permet de créer une unique instance de la classe.

Observateur

Le patron de conception Observateur / Observable (aussi appelé listener) permet d'obtenir un comportement similaire à des fonctions de callback : l'objet observé envoie un signal à son observateur qui peut alors réaliser l'action adéquate.
Nous utilisons ce patron pour appeler les actions correspondantes lorsque telle ou telle position est détectée.

Bilbiothèques

ASIO

ASIO est une bibliothèque C++ haut niveau spécialement conçue pour le développement d'applications réseau. L'avantage de la bibliothèque est d'être portable et non dépendante du système d'exploitation. À l'instar de POSIX, ASIO implémente les objets socket, bind, connect, listen ou accept ce qui nous permet de créer une connexion entre un serveur et un client TCP ou UDP. Nous l'utilisons principalement pour la gestion du protocole TCP que nous utilisons pour l'envoi des informations entre notre brique C++ et l'application Unity.
A l'origine, Asio fait partie de l'ensemble Boost. Cependant, il existe une version indépendante de Boost, qui dispose néanmoins de quelques limitations, mais que nous utilisons tout de même car cela nous permet d'éviter d'inclure Boost dans notre projet.

Threads

Etat de l'art

L'utilisation de POSIX Threads n'est pas disponible nativement sur Windows, contrairement aux systèmes UNIX. Comme nous avons besoin de créer un thread pour le serveur TCP et que nous souhaitons implémenter des sémaphores pour protéger nos ressources partagées, nous cherchions une bibliothèque pouvant remplacer pthreads sur Windows.

Threads Windows

Windows dispose de plusieurs bibliothèques développées par Microsoft qui remplacent des outils disponibles nativement sur d'autres systèmes. Pour les threads, Microsoft propose l'API CreateThread. Cependant nous gardons à l'esprit qu'il se pourrait qu'un jour notre logiciel soit utilisé sur une autre plateforme que Windows, nous cherchons donc plutôt une bibliothèque multi-plateforme.

Boost

La bibliothèque Boost, ou plutôt l'ensemble de bibliothèques Boost, propose l'accès simplifié à des outils comme le calcul linéaire, la génération de nombres pseudo-aléatoires, le traitement d'image, et dans notre cas, le multithreading. Seule une petite partie de cet ensemble nous intéresse, et Boost dans sa totalité est très conséquent, et bien trop lourd pour notre projet, comparé au pourcentage que nous utilisons. Il est vrai que Boost est extrèmement utilisé dans le développement C++, mais le fait que des alternatives soient disponibles nous a poussé à éliminer Boost. Cependant il est à noter que pour l'instant nous dépendons encore de Boost à cause de l'interface proposée par ThreeGear, qui se base sur cette bibliothèque. Mais grâce à la mise à jour de janvier 2014, il semble possible de retirer entièrement les dépendances à Boost.

C++11

La nouvelle norme pour le C++ est C++11, qui remplace aujourd'hui C++98 et C++03. Cette nouvelle norme inclut désormais une implémentation native de threads dans la bibliothèque standard. En réalité il s'agit uniquement de l'implémentation faite dans Boost, mais adaptée à la bibliothèque standard.
Nous ne pouvons malheureusement pas utiliser la norme C++11 pour ce projet, car nous souhaitons garder le maximum de compatibilité, et de nombreux compilateurs sont encore incompatibles. Par exemple, nous utilisons l'environnement Visual Studio 2010, qui n'est pas compatible avec C++11.

Solution retenue : PThreads for Win32

Après un essai peu concluant de Boost, qui est bien trop lourd pour notre projet, nous avons choisi d'utiliser pthreads for Win32 qui est un portage des POSIX Threads pour Windows. De plus les fonctions étant très similaires à la version Unix, nous savions déjà nous servir de la bibliothèque. Pour Windows nous incluons donc la bibliothèque pthreads for Win32, et sur un système Unix il nous suffirait de retirer cette dépendance et d'utiliser les threads POSIX.

Eigen

Le calcul de positions et les différentes opérations dans l'espace nécessitent une bibliothèque pouvant gérer les vecteurs, les matrices et les opérations mathématiques. Nous nous sommes tournés vers Eigen qui propose une implémentation des vecteurs, matrices et des opérations d'algèbre linéaire nécessaires.