Amélioration, modularisation et portage du logiciel de visualisation de modèles physiques masses-interactions par la gravure dynamique

Informatique et Création Artistique Simon Planès Polytech Grenoble - Réseaux Informatiques et Communication Multimédia Rapport de stage de quatrième année Amélioration, modularisation et portage du logiciel de visualisation de modèles physiques masses-interactions par la gravure dynamique Tome principal et annexes Maître de stage : Annie Luciani Tuteur universitaire : Florence Perronnin Année universitaire : 2012-2013 Stage du 13 mai au 23 août 2013

Résumé Le groupe ACROE-ICA développe des outils technologique dans le domaine de la création artistique, et notamment un formalisme de modélisation d objets physiques sous forme de masses en interaction. Les mouvements ainsi générés peuvent être mis en forme et habillés, notamment par le procédé de gravure dynamique, qui simule un corps en mouvement sur un milieu physique. Un logiciel implante ce procédé, dans lequel des marqueurs viennent perturber un ensemble de phyxels, que l on peut alors modéliser (par un paramétrage de propriétés physiques) et simuler. Il est hérité d un procédé physique, l écran d épingles, qui permet de produire des images en enfonçant les épingles à l aide de marqueurs. Ce stage a permis d améliorer ce logiciel, pour d une part le faire passer dans une version plus professionnelle, et d autre part, en modifiant sa conception (séparation noyau/interface), dans le but de connecter ce nouveau mode de visualisation à un modèle de simulation temps réel multisensorielle. Mots-clés : modélisation, simulation, visualisation, modèle physique masses-interactions, temps réel, synchronisation, séparation noyau/interface Abstract ACROE-ICA develops technology tools for artistic creation, and especially a modelisation engine for physical objects represented as interacting masses. Thanks to the dynamic engraving method, generated movements can be shaped and rendered. This method simulates a moving body in a physical environment, and is provided by a software, in which markers disrupt a set of phyxels that can be modeled (by setting its physical properties) and simulated. The idea comes from a physical device, the pins screen, which produces images by pressing the pins with markers. During this internship, the software has been improved. It is now almost debugged, and its design is different from what it used to be. Indeed, making the separation between the application s core and its graphical interface allowed us to use this new visualisation way for a multisensory real time simulation model. Keywords : modeling, simulation, visualization, mass interaction physical model, real time, synchronisation, core/interface separation

Remerciements Je tiens à remercier dans un premier temps mon maître de stage Annie Luciani, qui m a permis d effectuer ce stage et m a suivi tout au long de ces douze semaines. Je remercie également Nicolas Castagné, qui m a aidé, guidé et conseillé au quotidien, et pour toutes les connaissances et savoir-faire informatiques qu il m a apportés. Je tiens à exprimer toute ma reconnaissance aux personnes suivantes, pour l accueil qui m a été fait et l expérience enrichissante qu elles m ont permis de vivre : Stéphane Bœuf, pour ses conseils techniques et pour avoir partagé son bureau, Nicolas André, pour le temps passé à résoudre des problèmes techniques, James Leonard, qui m a accompagné durant l une des phases du stage, ainsi que de nombreuses personnes de l ACROE-ICA, pour leur accueil et la bonne ambiance qu ils apportent. Enfin, je remercie mon tuteur Florence Perronnin qui a suivi l avancement de ce stage. 1/31

Table des matières Introduction 5 1 Le groupe ACROE-ICA 6 1.1 Le groupe ACROE-ICA............................ 6 1.2 Les technologies................................. 7 1.2.1 CORDIS-ANIMA, un formalisme de modélisation physique particulaire.................................. 7 1.2.2 GENESIS et MIMESIS, des modeleurs/simulateurs pour le son et l image.................................. 8 1.2.3 La «gravure dynamique» comme moyen de visualisation...... 8 2 Gravure dynamique 10 2.1 Le logiciel.................................... 10 2.1.1 Modélisation.............................. 10 2.1.1.1 Choix des entrées....................... 11 2.1.1.2 Positionnement relatif.................... 11 2.1.1.3 Paramétrage physique.................... 11 2.1.1.4 Choix du mode de visualisation............... 11 2.1.1.5 Choix des fréquences..................... 12 2.1.2 Simulation................................ 12 2.2 Refonte..................................... 13 2.2.1 Corrections apportées au logiciel.................... 13 2.2.2 Conception et architecture logicielles................. 13 2.2.2.1 La structuration du code à l origine............. 14 2.2.2.2 Comment disposer d un noyau fonctionnel indépendant?. 14 2.3 Portage temps réel............................... 15 2.3.1 Le modèle «PebbleBox»........................ 15 2.3.1.1 Le fonctionnement d un modèle............... 15 2.3.1.2 Pourquoi PebbleBox?.................... 16 2.3.2 L écran d épingles pour visualiser un modèle............. 16 2.3.2.1 Enjeux et contraintes..................... 17 2.3.2.2 Les solutions envisageables.................. 17 2.3.2.3 Implémentation........................ 18 3 Retours sur le stage 19 3.1 Gestion de projet................................ 19 3.1.1 Plannings................................ 19 3.1.2 Suivi de l activité............................ 20 3.2 Connaissances acquises............................. 20 3.2.1 Génie logiciel.............................. 21 3.2.2 Technologies............................... 21 2/31

TABLE DES MATIÈRES TABLE DES MATIÈRES 3.2.3 Domaines complémentaires....................... 21 3.3 Bilan....................................... 22 Conclusion 23 Glossaire 23 Bibliographie 24 Annexes 26 3/31

Table des figures 1.1 L écran d épingles................................ 9 1.2 Phyxels..................................... 9 2.1 Le logiciel PinsScreen.............................. 11 2.2 Paramétrage physique de PinsScreen..................... 12 2.3 Transducteurs à retour d effort......................... 16 2.4 Communication des données entre le DSP, l hôte et le GPU......... 17 1 Image produite avec PinsScreen........................ 26 2 Productions de Pierre-Adrien Fouilland.................... 27 3 Unités composant le projet PinsScreen.................... 27 4 Diagrammes de classes du logiciel PinsScreen................. 28 5 Diagramme de Gantt effectif du stage..................... 29 4/31

Introduction Dans le cadre de ma deuxième année de formation d ingénieur à Polytech Grenoble, spécialité Réseaux Informatiques et Communication Multimédia, j ai eu l opportunité d effectuer un stage de treize semaines dans un laboratoire de Grenoble INP, Informatique et Création Artistique, en relation étroite avec l Association pour la Création et la Recherche d Outils d Expression. Cette expérience professionnelle s inscrit dans une logique de recherche de projets utilisant la technologie, mais n appartenant pas forcément spécifiquement au monde de l informatique. Cette même réflexion m a par ailleurs mené à réaliser d autres stages de recherches, dont l un lié à la physique, au CEA de Grenoble. C est donc dans cette optique que j ai postulé à un ensemble d offres de stage proposées par l ICA qui, avec l ACROE, mène des recherches sur les relations entre arts et informatique, et développe des outils liés à la création artistique. L art désigne ici notamment les domaines de la musique, de l image et de l animation. Seuls les deux derniers sont concernés par ce stage, qui se rapporte à la virtualisation d un dispositif inventé dans les années 1930 : l écran d épingles. Il s agit d un moyen de visualisation, que l on nommera également «gravure dynamique», qui permet, dans notre cas, de rendre visible pour l humain un phénomène physique simulé sur ordinateur, en produisant des images à partir du mouvement d un ensemble de points. Ce procédé a été doté d un moteur de simulation et d un logiciel pour le rendre accessible à tout type d utilisateur ; c est autour de ce logiciel que le contenu de ce stage s articule. L objectif est double : le logiciel doit non seulement passer de sa version «prototype» à une version plus profesionnelle, mais aussi faire profiter de son savoir-faire, c est-à-dire fournir un «habillage» à un phénomène physique, à d autres simulations que le seul écran d épingles. En effet le laboratoire utilise également des simulateurs qui interagissent avec l humain en temps réel et en empruntant plusieurs canaux sensoriels. Ceux-ci pourront alors bénéficier d un nouveau mode de visualisation. Après avoir détaillé le contexte d un tel outil ainsi que son fonctionnement, nous verrons comment son portage sur une plateforme de simulation temps réel a été mis en place. Pour finir, nous reviendrons sur l aspect «gestion de projet» du stage, en faisant notamment un bilan des tâches réalisées. 5/31

Chapitre 1 Le groupe ACROE-ICA et ses outils Le laboratoire dans lequel s est déroulé ce stage travaille sur les relations entre arts et informatique. En ce sens, il développe des technologies mettant à profit l outil informatique dans des processus de modélisation et de création artistiques. On en dévoile une partie dans ce chapitre, dont une qui représente le contexte même du stage. 1.1 Le groupe ACROE-ICA Le groupe ACROE-ICA regroupe un laboratoire, Informatique et Création Artistique, et l Association pour la Création et la Recherche d Outils d Expression, centre de recherche du ministère de la culture créé à l Institut National Polytechnique de Grenoble en 1976, par Claude Cadoz, Annie Luciani et Jean-Loup Florens, tous trois encore présents au laboratoire. Les activités de ce groupe pluridisciplinaire s articulent autour des rapports entre art, science et technologie, dans le but de produire des outils de création et d expression - dans les domaines de la musique, des arts du mouvement, de la robotique, des télécommunications, de l éducation, etc. - mais aussi dans un souci de recherche et formation scientifiques et techniques. L ACROE est à l origine de trois innovations, que nous développerons par la suite : la modélisation physique particulaire la simulation physique temps réel multisensorielle les systèmes à retour d effort Le groupe repose sur un ensemble de savoir-faire et d outils qu il a développés : le langage de modélisation physique particulaire CORDIS-ANIMA, présenté plus bas des prototypes d implantation temps réel sur processeurs génériques, sur cartes DSP (Digital Signal Processor) et sur architecturs multiprocesseurs des prototypes d interfaces utilisateur pour la modélisation physique particulaire masses/interactions : GENESIS et MIMESIS une librairie de modèles physiques, image et son une panoplie de systèmes haptiques ERGON_X des recherches scientifiques en perception des scènes virtuelles On note, enfin, la gestion de la plateforme AST (Art-Science-Technologie) pour l école PHELMA de l Institut Polytechnique de Grenoble. 6/31

CHAPITRE 1. LE GROUPE ACROE-ICA 1.2. LES TECHNOLOGIES 1.2 Les technologies développées par l ACROE-ICA Certains des outils mentionnés plus tôt sont présentés ici. Pour fonctionner et pouvoir communiquer entre eux, ils s appuient sur le système CORDIS-ANIMA. 1.2.1 CORDIS-ANIMA, un formalisme de modélisation physique particulaire Depuis 1978, L ACROE développe CORDIS-ANIMA [CLF90], un système complet pour la modélisation et la simulation numériques en temps réel d objets physiques manipulables, audibles et/ou visibles. Il assure un rôle de noyau d un outil informatique dans le processus de création musicale et d animation d images. C est à la fois un outil de modélisation (dans le sens où un modèle CORDIS-ANIMA représente un intermédiaire entre l univers des objets physiques et celui des objets simulés) et de simulation (sous la forme d un ensemble d algorithmes élémentaires), un système (différent de la physique mécanique et de l algorithmique de simulation) et un langage (composé d un ensemble d éléments et de règles de combinaison). Il permet de simuler, sur ordinateur, la réplique de certains objets du monde physique. Typiquement, ces objets sont des instruments de musique, ou plus simplement tout objet manipulable, mobile ou déformable. La réplique entre en communication avec l humain selon trois canaux sensoriels (acoustique, visuel, gestuel) via des transducteurs. Le laboratoire développe d ailleurs ses propres dispositifs, les TGR (Transducteur Gestuel Rétroactif), dont le fonctionnement est détaillé plus loin. Ainsi, l ensemble composé de l ordinateur et du transducteur est un moyen de la représentation de l instrument. Cette technique présente l avantage d aboutir à des productions (auditives ou visuelles) hautement réalistes, puisqu issues de simulations du monde réel. Un objet CORDIS-ANIMA est un agencement de plusieurs sous-objets. C est cet aspect modulaire qui confère au formalisme sa généricité : un ensemble limité de composants différents permet de construire une grande variété d objets. L objet est donc constitué de composants (on parle aussi de modules) et de connexions entre leurs points de communication, qui sont les constituants de base : les points matériels (M) et les éléments de liaison (L). Un point M prend en entrée une variable intensive, une force, et produit en sortie une variable extensive, une position ; c est exactement l inverse pour L. Les points M et L se connectent en affectant la sortie de l un à l entrée de l autre. Ainsi, si plusieurs points L sont connectés à un même point M, la force résultante appliquée à M sera égale à la somme des forces sortant des points L. Un module à un seul point M est appelé MAT, et correspond à un élément matériel qui, soumis à une force, produit un déplacement selon certains paramètres comme sa masse. Un module à deux points L est un élément de liaison, LIA, et permet de relier deux masses entre elles ; leurs deux déplacements en entrée aboutiront en sortie à deux forces d interaction. On peut associer cette liaison à la composante viscoélastique d une structure physique. In fine, un modèle CORDIS-ANIMA est un réseau de masses reliées entre elles par des interations, et régies par les lois du mouvement de Newton. Il s agit en fait d une généralisation du modèle masses-ressorts, dans le sens où la topologie physique est quelconque, et où tous les types d interactions sont possibles. On parle alors de modèle physique massesinteractions, modèle qui permet de simuler une grande diversité de comportements dynamiques : solides, fluides, objets déformables, etc. En pratique, les éléments fondamentaux de la matière de CORDIS-ANIMA sont la masse, le ressort et le frottement. 7/31

CHAPITRE 1. LE GROUPE ACROE-ICA 1.2. LES TECHNOLOGIES Des logiciels du laboratoire, comme ceux présentés ci-après, utilisent ce formalisme. 1.2.2 GENESIS et MIMESIS, des modeleurs/simulateurs pour le son et l image GENESIS est un logiciel du domaine musical : il permet de modéliser des composants physiques d un instrument de musique dans le but de créer des phénomènes sonores riches et contrôlables. MIMESIS porte sur l art du mouvement : sa conception et sa synthèse sont à l origine d images animées. Ces deux logiciels travaillent à différentes échelles, que ce soit d un mouvement sonore à une œuvre musicale, ou d un mouvement expressif à un macro-déplacement. 1.2.3 La «gravure dynamique» comme moyen de visualisation Les masses ponctuelles utilisées n ont pas de spatialité ; produire un rendu, c est-àdire une séquence d images animées, implique donc de créer une forme pour rendre visible ces mouvements. Dans les logiciels classiques (Maya, Blender, 3DStudio), le processus de modélisation associe la forme et le mouvement d un objet dans un seul modèle, qui est ensuite mis en image. Pour CORDIS-ANIMA, le principe est différent, et peut être résumé ainsi [Sil11] : 1. un premier modèle génère un mouvement, basé sur un modèle physique, 2. un deuxième modèle apporte une forme à l objet, 3. puis l objet est «habillé» par un troisième modèle (pour l image) On est alors en présence d une modélisation en cascade, chacun des modèles étant en interaction unidirectionnelle avec le modèle suivant. Ce choix de modélisation présente l avantage d être plus économique en information, puisqu il évite d avoir à définir, en même temps que le mouvement, les données relatives à la forme, qui peuvent être nombreuses : sommets, contours, faces, etc. De plus, rendre interdépendants le mouvement et la forme peut alourdir la simulation, tant dans son contrôle que dans sa compréhension. D autre part, les méthodes existantes, qui contôlent des formes prédéfinies, ne permettent pas aisément de décrire des objets à topologie variable, comme de la fumée ou du sable. La gravure dynamique propose une méthode de simulation d un corps en mouvement sur un milieu physique ayant son propre comportement. À la base du concept de gravure dynamique se trouve celui de l écran d épingles du graveur et réalisateur Alexandre Alexeïef, réalisé au début des années 1930. Il s agit d un écran dans lequel sont insérées 240 000 épingles, qui peuvent coulisser perpendiculairement à celui-ci. Projeter en biais une lumière sur l écran y fait apparaître les ombres des épingles, et donc des niveaux de gris dépendant de l altitude des épingles. En enfonçant plus ou moins les épingles, le jeu d ombres peut produire une image complexe, voire, en répétant cette opération un grand nombre de fois, une animation (figure 1.1). L analogie entre l écran d épingles et la gravure dynamique recouvre plusieurs points [Sil11, Fou10]. En guise d épingles, le support simulé est composé d un ensemble de phyxels, éléments de base de la discrétisation physique d un milieu, placés sur une grille régulière. Une masse mobile et une masse fixe composent un phyxel (figure 1.2(a)), que l on peut alors représenter par un scalaire définissant l altitude de la masse mobile par rapport au support. 8/31

CHAPITRE 1. LE GROUPE ACROE-ICA 1.2. LES TECHNOLOGIES (a) L écran, sur lequel les épingles forment une image (b) Image tirée du film A night on bald mountain (1933) Figure 1.1 L écran d épingles d Alexandre Alexeieff [Dol09] Les objets utilisés pour enfoncer les épingles sont eux représentés par des «marqueurs», qui viennent perturber le support et y laisser une trace. Dans ce modèle existent trois interactions (figure 1.2(b)) : l action unidirectionnelle des marqueurs sur les phyxels l interaction entre phyxels voisins l interaction avec le sol, c est-à-dire entre la masse fixe et la masse mobile du phyxel Chacune de ces interactions peuvent prendre plusieurs types. Ceux que l on considère dans ce document sont la butée, le ressort avec frottements et la plasticité. marqueur masse mobile interaction phyxel-marqueur interaction de voisinage masse fixe sol (a) Un phyxel (b) Les interactions en jeu interaction avec le sol Figure 1.2 Un phyxel, abstraction de l épingle, est composé d une masse fixe et d une masse mobile, et est impliqué dans trois interactions En définitive, la gravure dynamique est une simulation d un champ scalaire dans l espace, évoluant dans le temps et perturbé par des marqueurs provenant par des simulations amont. Il permet, d «habiller», de différentes manières, des phénomènes dynamiques impliquant des objets aux propriétés physiques variées. C est sur ce procédé, et plus précisément un logiciel qui lui est consacré, que le travail de ce stage porte. 9/31

Chapitre 2 Réalisations autour de la gravure dynamique Le procédé de gravure dynamique s est doté d un logiciel, appelé «PinsScreen» 1, muni d une interface graphique, pour proposer à l utilisateur un système de modélisation et de simulation. Ce stage visait d une part à apporter des améliorations à ce logiciel, et d autre part à faire profiter de son savoir-faire en matière de visualisation à d autres applications. L équipe impliquée est décrite dans le tableau?? en annexe. 2.1 Le logiciel : origines et fonctionnement Le développement de l application a commencé en 2010, dans le cadre de la thèse de Kevin Sillam [Sil11] et du stage ingénieur de Pierre-Adrien Fouilland [Fou10], avec comme objectif de proposer une interface manipulable et interactive pour le procédé de gravure dynamique. L implémentation repose sur les technologies C++ et Qt, en déportant le calcul de la simulation physique sur GPU avec OpenGL ; les calculs, bien que simples, sont en effet nombreux, et n étant pas tous chaînés, se prêtent bien à l exécution sur architecture parallèle. Ces calculs sont assurés par une bibliothèque logicielle 2, volontairement séparée de l application en elle-même ; c est uniquement sur cette dernière que le travail de ce stage porte. On notera toutefois que l algorithme général de la gravure dynamique recouvre deux phases. La première correspond au calcul physique, c est-à-dire la détermination de la hauteur des phyxels selon les phyxels voisins, les marqueurs, et les paramètres physiques des interactions que nous détaillons plus loin. Il s agit donc de l étape la plus coûteuse, où les performances décroissent avec l augmentation du nombre de phyxels et de marqueurs. Dans la deuxième partie de l algorithme, les données issues des calculs précédents sont exploitées pour produire une image : c est la phase de visualisation. À travers ce logiciel, l utilisateur affecte à l écran d épingles différentes propriétés physiques lors de la modélisation, puis contrôle ensuite la simulation. Ces deux niveaux sont représentés respectivement en partie gauche et en partie droite de la figure 2.1. 2.1.1 Modélisation L animateur joue sur plusieurs aspects du modèle, que l on présente ici. Il est cependant nécessaire d introduire une autre technologie développée par l ACROE, le GMS (Gesture Motion Signal). Ce format de fichier permet de stocker des mouvements et gestes sous forme de signaux multidimensionnels. On verra que PinsScreen peut produire ce genre de fichier, comme d autres applications décrites plus haut (Genesis et Mimesis, par exemple). 1. Bien qu il soit toujours employé actuellement, ce nom devra être changé faute de droit. 2. Une première version du moteur de simulation de l écran d épingles a été réalisée à la fin années 1990, dans le cadre de la thèse de Arash Habibi [HL02]. 10/31

CHAPITRE 2. GRAVURE DYNAMIQUE 2.1. LE LOGICIEL Figure 2.1 Le logiciel «PinsScreen», à l issue de ce stage 2.1.1.1 Choix des entrées Le logiciel prend en entrée les positions des marqueurs au cours du temps. Celles-ci peuvent être transmises en temps réel ; dans ce cas, la souris fait office d unique marqueur, solution efficiente pour tester rapidement le modèle créé. Nous verrons par la suite un autre type d entrée temps réel (voir 2.3). Il est également possible de fournir un fichier GMS, issu d une simulation en amont, auquel cas la simulation est cette fois en temps différé. 2.1.1.2 Positionnement relatif L utilisateur définit la manière dont sont positionnés l espace des marqueurs et l espace des phyxels l un par rapport à l autre, en leur appliquant des homothéties. Il travaille séparément en XY et en Z. Dans cette deuxième calibration, c est la hauteur des marqueurs par rapport aux phyxels qui est affectée. 2.1.1.3 Paramétrage physique C est ici que sont calibrées les trois interactions définies dans le premier chapitre : entre les marqueurs et les phyxels, entre la masse fixe et la masse mobile des phyxels, et entre phyxels voisins (figure 2.2). Pour chacune d elle, l opérateur choisit ou non un type de liaison (parmi la butée, le ressort et la plasticité), et en fixe les grandeurs physiques : raideur (K), viscosité (Z), longueur à vide (L0) et longueur de seuil (S). 2.1.1.4 Choix du mode de visualisation Indépendamment du modèle physique, l animateur choisit un type de visualisation parmi un panel de six qu il peut éventuellement enrichir, chacun d eux apportant un angle de vue différent. On recense notamment une visualisation de contrôle regroupant plusieurs vues dans différentes dimensions, une autre sous forme de surface, plus fidèle à 11/31

CHAPITRE 2. GRAVURE DYNAMIQUE 2.1. LE LOGICIEL l écran d épingles originel, ou encore une visualisation qui fait la correspondance entre les couleurs d une texture fournie par l utilisateur et la hauteur des phyxels. Figure 2.2 Le paramétrage physique dans PinsScreen consiste à définir les interactions qui affectent les phyxels 2.1.1.5 Choix des fréquences Enfin, l utilisateur fixe trois fréquences : la fréquence d acquisition des positions des marqueurs au cours du temps, qui correspond soit à la fréquence d échantillonnage du fichier GMS, soit à la fréquence de rafraîchissement de la position de la souris la fréquence de simulation de l écran d épingles, soit celle à laquelle le calcul de la position des phyxels est effectué la fréquence de visualisation On impose d ailleurs la contrainte selon laquelle les fréquences d acquisition et de visualisation doivent être des sous-multiples de la fréquence de simulation. 2.1.2 Simulation En parallèle de la modélisation, l utilisateur peut à tout moment charger le modèle dans le simulateur. C est ce dernier qui assure : le contrôle de la simulation : démarrage, arrêt, et, en cas d entrée sous forme de fichier GMS, pause et modification de la vitesse de lecture l affichage du résultat de la simulation selon le mode de visualisation choisi l export sous forme de vidéo, d image(s), ou de fichier GMS contenant les positions au cours du temps des marqueurs Un modèle tel qu il est décrit ici peut être sauvegardé et réouvert dans un fichier au format XML, dans lequel tous les paramètres et leurs valeurs sont enregistrés. Le format a été 12/31

CHAPITRE 2. GRAVURE DYNAMIQUE 2.2. REFONTE changé au cours du temps, mais tend à être standardisé pour assurer la rétrocompatibilité du logiciel. 2.2 Refonte du logiciel de gravure dynamique La première partie du stage a été consacrée à améliorer ce logiciel, du point du vue utilisabilité, mais aussi dans la qualité de son développement, dans le but de le faire évoluer d une version prototype vers une version «professionnelle». 2.2.1 Corrections apportées au logiciel La première tâche de ce stage consistait à juger le logiciel d un œil neutre, sans a priori sur les contraintes de développement. Il était alors intéressant de disposer d un double point de vue : celui de l utilisateur ordinaire, et celui bénéficiant de connaissances en conception logicielle et en interface homme-machine. Nous avons pu dès lors établir un certain nombre de remarques à partir de la seule utilisation du logiciel, qui ont été ensuite discutées avec les responsables de ce stage. Elles concernaient aussi bien l ergonomie de l interface que les bugs à proprement parler. Puis une synthèse a été faite, tenant également compte d une liste de critiques et réflexions du même genre faites au préalable par les personnes ayant participer au développement du logiciel. Au final, on peut distinguer deux ensembles de corrections : les plus triviales, et celles qui nécessitent des réflexions sur la sémantique ou l ergonomie des fonctionnalités proposées. Les modifications du premier type ont pu être apportées rapidement : elles avaient trait par exemple à la terminologie (choix de termes adéquats ou fautes de français), à des propriétés des éléments de l interface graphique, ou encore aux actions accessibles ou non à l utilisateur. Dans le deuxième cas, il a plus été question de poser précisément le problème, pour une correction ultérieure. Une partie de ces «bugs» a toutefois été corrigée, notamment ceux qui entravaient la bonne utilisation de l application. On peut citer parmi ceux-ci divers plantages liés à l utilisation d OpenGL, mais aussi un problème de traitement d erreurs concernant les fichiers externes. En l occurrence, ouvrir un projet qui exploite des fichiers qui n existent plus (une image faisant office de texture par exemple) faisait fermer brutalement le logiciel, sans avertissement. De même, un tel fichier a pu être modifié sans que l utilisateur en soit informé. Il a donc fallu d une part vérifier au plus tôt la présence des fichiers nécessaires, et dans le cas contraire proposer à l utilisateur de corriger le problème, et d autre part utiliser un code détecteur d erreurs (SHA-1) pour rendre compte d un éventuel changement dans le contenu d un fichier. D autres modifications ont été faites, visant pour la plupart soit à améliorer le contrôle des actions de l utilisateur (pour les champs de saisie par exemple) ainsi que le guidage, soit à améliorer la qualité du code (par exemple en privilégiant les fonctionnalités offertes par une bibliothèque portable comme Qt plutôt que des appels systèmes UNIX). Restent donc les erreurs et remarques qui n ont pas été traitées du fait de la durée du stage et en raison de l importance des autres tâches à réaliser. Parmi ces dernières se trouve celle liée à l architecture du code. 2.2.2 Conception et architecture logicielles Comme toute application informatique, PinsScreen doit répondre à un ensemble de règles de génie logiciel. L une d elles préconise de séparer les différentes fonctions du 13/31

CHAPITRE 2. GRAVURE DYNAMIQUE 2.2. REFONTE logiciel, ce qui est d autant plus vrai ici qu une partie du code devra être utilisée en externe. 2.2.2.1 La structuration du code à l origine On l a vu, le savoir-faire du procédé de gravure dynamique était séparé en deux parties : l une, sous forme de bibliothèque, assure la simulation de l écran d épingles et offre ses services à l autre, l application exécutable que manipule l utilisateur. Cette séparation était en réalité plus fine que cela, dans le respect des bonnes pratiques de l interface homme-machine, qui préconisent de rendre indépendants les traitements effectués par le noyau fonctionnel de ceux de l IHM. En effet, un changement sur l interface ne doit pas impacter le cœur de l application, de même que ce dernier devrait pouvoir, dans l absolu, fonctionner avec d autres types d interfaces. C est en ce sens qu à l intérieur même de l application étaient séparées ces deux unités. 2.2.2.2 Comment disposer d un noyau fonctionnel indépendant? Cependant, cette séparation pouvait être améliorée sur plusieurs points. Ce travail était nécessaire dans l optique de la tâche rapportée dans la dernière partie de ce chapitre. Il est en effet judicieux d avoir un noyau totalement autonome, c est-à-dire n ayant nullement besoin de l interface actuelle pour fonctionner, et de pouvoir l utiliser dans d autres applications ; en l occurrence, on fait le choix de construire ce noyau sous forme de bibliothèque statique. Cette tâche concerne principalement la gestion des erreurs de l utilisateur. La finalité étant de simuler un modèle, celui-ci doit en effet répondre à un certain nombre de contraintes avant de pouvoir être chargé dans le simulateur : les fichiers utilisés existentils, les fréquences sont-elles valides, etc. Dans cette optique, plusieurs corrections ont été effectuées : Les erreurs ont été standardisées, avec leur dégré de gravité (une erreur grave empêche le modèle d être simulé, une erreur moins grave peut rester en l état) ainsi qu un message descriptif à destination de l utilisateur. À l ouverture d un projet, c est-à-dire lors du parsage du fichier décrivant le projet, les erreurs sont traitées au cas par cas, et non plus indiféremment. Enfin, et c est la partie la plus conséquente, ces erreurs ne doivent plus être détectées par le code de l interface, comme c était le cas, mais par celui du noyau. Ainsi, lors d une requête de chargement du modèle dans le simulateur, le noyau vérifie sa validité. En cas d erreurs, celles-ci sont transmises à l interface qui les soumet à l utilisateur. Ce dernier peut alors les corriger, tout en étant guidé par l interface. La complexité ici réside dans le besoin de conserver à tout moment un état cohérent du modèle : si des modifications qui lui sont apportées le rendent invalide, il est indispensable de pouvoir revenir facilement à un état stable. Finalement, le noyau vérifie le respect des contraintes sans avoir besoin de passer par l interface. Ces vérifications sont par ailleurs effectuées au plus tôt, et une seule fois, au contraire de la version précédente. De son côté, l utilisateur est mieux guidé dans la correction de ces erreurs. En résumé, le code se répartit dans les paquets suivants : une bibliothèque de simulation physique de l écran d épingles (avec le calcul sur GPU et l API sur l hôte), une bibliothèque implantant le noyau fonctionnel du logiciel PinsScreen pour la modélisation, et un ensemble de classes fournissant une interface graphique. En annexe, la figure 3 dé- 14/31

CHAPITRE 2. GRAVURE DYNAMIQUE 2.3. PORTAGE TEMPS RÉEL taille le rôle des paquets, et la figure 4 donne l architecture de classes du noyau et de l interface graphique. 2.3 Portage du logiciel sur les simulateurs temps réel La dernière phase d implémentation de ce stage revenait à exploiter ce qui avait été réalisé sur la gravure dynamique pour faire profiter d autres applications de ce mode de visualisation. En l occurrence, l objectif était de connecter le noyau de PinsScreen aux simulateurs temps réel à interaction multisensorielle du laboratoire. 2.3.1 Le modèle «PebbleBox» Le laboratoire développe des modèles, sous forme d expériences, sur lesquels il applique ses systèmes haptiques. Ce travail s est porté sur un modèle particulier, appelé «PebbleBox» (la boîte à cailloux). Celui-ci nous permet d ailleurs d introduire les aspects techniques et matériels d une telle expérience. 2.3.1.1 Le fonctionnement d un modèle «PebbleBox» est la reproduction virtuelle d une boîte dans laquelle seraient disposés huit cailloux [ACR07]. Ce modèle utilisant le formalisme CORDIS-ANIMA, ceux-ci sont associés à des masses mobiles, rentrant en collision selon des interactions visco-élastiques dont les propriétés - élasticité, viscosité et longueur de seuil - sont paramétrables. Pour interagir avec ces masses, l expérimentateur manipule un dispositif haptique de la gamme ERGOS [CLFC04]. Les transducteurs gestuels à retour d effort Un TGR (Transducteur Gestuel Rétroactif) est un système haptique permettant d appliquer un geste réel à des objets virtuels, et d en restituer des sensations chez la personne qui le manipule (on parle de retour de force générique) ; celle-ci a alors une perception kinesthésique de leurs comportements : poids, rigidité, consistance, etc. Il a fait son apparition suite au besoin exprimé par l ACROE en 1975 d interagir de manière instrumentale avec l ordinateur dans les activités sensibles (musique, animation), à une époque où il n y avait pas de transducteur gestuel capable de transmettre le geste bilatéralement entre l homme et l ordinateur. Un transducteur est donc constitué de capteurs de position absolue, pour détecter l action du geste, et de moteurs, pour restituer la sensation (figure 2.3). Ces derniers disposent d un nombre de degrés de liberté adaptable à l application souhaitée, ce qui est nécessaire si l on veut produire des rendus artistiques de même qualité qu avec des instruments réels. Pour utiliser ce type de transducteur, on y connecte un adaptateur mécanique : clavier, joystick (deux ou trois degrés de liberté), levier (trois), boule (six), etc. En plus de l application artistique (où un adaptateur en forme d archet permettrait de simuler des cordes frottées, par exemple), le domaine scientifique peut aussi en bénéficier : en donnant un aspect haptique à un phénomène nanoscopique (observé avec un microscope à force atomique), il devient plus aisé de distinguer des paramètres caractérisriques d une force. 15/31

CHAPITRE 2. GRAVURE DYNAMIQUE 2.3. PORTAGE TEMPS RÉEL Un coprocesseur dédié au calcul de simulation physique temps réel dur synchrone 3 Les signaux produits par le transducteur doivent être traités en temps réel par l ordinateur. Cela se fait à travers un DSP (Digital Signal Processor), un microprocesseur dont l architecture est optimisée pour les opérations de traitement du signal [Pro13]. Celle-ci est en effet conçue pour effectuer des calculs en parallèle et pour gérer efficacement des signaux (envoyés sur un port série synchrone rapide), ce que ne fait pas un processeur classique. Une telle carte d acquisition dispose d un convertisseur analogique-numérique, puisque les calculs sont naturellement exécutés en numérique, et d un convertisseur inverse. Ce dispositif est typiquement employé dans les systèmes de transmission ou communication : téléphonie, télévision, sonar, etc. Le modèle actuellement utilisé dans le laboratoire est la TORO d Innovative [Inn13], avec seize canaux d entrés-sorties analogiques en simulatané, fonctionnant en théorie jusqu à 250 khz. Figure 2.3 Transducteurs à retour d effort, respectivement à trois et six degrés de liberté [AI13] 2.3.1.2 Pourquoi PebbleBox? Ainsi dans ce modèle particulier, une masse représentant le TGR interagit avec huit autres masses, qui modélisent les cailloux. L expérimentateur dispose de trois de ses sens pour appréhender la scène : le toucher grâce au retour d effort du transducteur, l ouïe qui capte les sons émis par les collisions, et la vue, à travers l écran. Mais selon les paramètres de visualisation, il n est pas forcément aisé de comprendre qu il y a effectivement huit objets, où ils sont placés, etc. À l origine, deux modes de visualisation sont disponibles : sous forme de boules, et un flou gaussien. Et avec ce dernier, les impressions des testeurs sont vagues [ACR07] : ils pensent manipuler du coton ou une pâte lorsque les collisions sont faibles, ou bien des objets clairement séparés mais sans arriver à déterminer leur nombre et leur taille 4. Le but est donc ici de fournir d autres visualisations des masses grâce à l écran d épingles. 2.3.2 L écran d épingles pour visualiser un modèle À l origine, PebbleBox est un programme écrit en C++ qui lance un thread dédié à la visualisation OpenGL. La durée de vie de l application est d ailleurs celle de ce thread. Il 3. On parle de temps réel «dur» lorsque les contraintes temps réel doivent être strictement et systématiquement respectées. 4. À l heure d écrire ces lignes, je n ai pas encore eu l occasion de faire par moi-même cette expérience. 16/31

CHAPITRE 2. GRAVURE DYNAMIQUE 2.3. PORTAGE TEMPS RÉEL utilise également une librairie externe pour toutes les communications entre le processeur central (on parlera d hôte) et la carte d acquisition (DSP). 2.3.2.1 Enjeux et contraintes On se propose d abandonner tout ce qui a trait à la visualisation, et de faire appel au noyau de l application PinsScreen, pour lequel les marqueurs sont les masses de PebbleBox. L intérêt pour PebbleBox est de disposer d autres visualisations de manière plus souple, paramétrable et donc non limitée. Le principe est le suivant : le DSP calcule la simulation physique de la «boite à cailloux» ; en particulier, il met à jour les positions des masses au cours du temps. Sur l hôte, un timer logiciel déclenche l acquisition de ces positions, puis exécute le calcul physique de l écran d épingles sur GPU, calcul qui génère la visualisation (figure 2.4). Une première contrainte apparait alors : l hôte récupère les données et les transmet à une fréquence de l ordre de 50 ou 100 Hz, là où DSP et GPU calculent à 1050 Hz. Pour pouvoir synchroniser l hôte avec le GPU (la communication hôte-dsp est elle asynchrone), on utilise un timer logiciel sur l hôte. Or il s avère difficile d atteindre une précision satisfaisante pour une telle résolution, et l hôte est finalement cadencé à la fréquence de visualisation de PinsScreen. hôte timer DSP positions des masses acquisition GPU simulation de l'écran d'épingles simulation de la boite à cailloux affichage position du TGR Figure 2.4 Communication des données entre le DSP, l hôte et le GPU 2.3.2.2 Les solutions envisageables Porter PinsScreen dans PebbleBox peut se faire de différentes manières, avec dans tous les cas le remplacement de la visualisation existante. Une première étape a donc consisté à produire un «prototype», dans l optique de disposer rapidement d une démonstration. Cependant ce choix n est pas pérenne, puisqu impliquant de la recopie de code de PinsScreen et une adaptation spécifique au modèle particulier qu est PebbleBox. Restaient alors deux solutions, spécifiées en fonction du temps restant pour l implémentation. Dans un souci de généricité maximale et de réutilisabilité de l existant, c est finalement un compromis entre les deux pistes étudiées qui a été choisi. 17/31

CHAPITRE 2. GRAVURE DYNAMIQUE 2.3. PORTAGE TEMPS RÉEL 2.3.2.3 Implémentation Une deuxième contrainte s est imposée : pour respecter la compatibilité descendante du logiciel PinsScreen (ce dernier doit pouvoir lire des fichiers produits antérieurement), le format de fichier ne doit pas être modifié ; dans un sens plus large, c est l ensemble même du code qui ne doit pas être trop perturbé. On a donc considéré un nouveau type d entrée, en plus de l acquisition à la souris et depuis un fichier GMS, de type «flux GMS». Le principe de la simulation est ensuite similaire à ce qui est fait dans les deux premiers cas, pour lesquels dans une boucle temporelle étaient appelées l acquisition et la calibration des marqueurs, puis le calcul du rendu de l écran d épingles. On a donc pour chacun de ces deux types d entrée une classe dédiée à l acquisition des données, et une autre qui gère la boucle temporelle à l aide d un timer. Pour ce nouveau type, on a donc également une nouvelle classe pour faire office de boucle, mais la différence réside dans l acquisition des positions des marqueurs. En effet, ce mécanisme est externe à PinsScreen, qui n a aucune connaissance du fonctionnement de PebbleBox. L enjeu était donc de fournir un procédé suffisamment générique pour qu un modèle quelconque puisse se «greffer» sur cet ajout de code dans PinsScreen. Ainsi dans notre cas, l objet chargé de l acquisition des données est créé côté PebbleBox, puis transmis au noyau de PinsScreen dont le contrôleur de la simulation le traite comme un flux GMS (voir l algorithme 1). L utilisateur doit ensuite donner, en tant que paramètres du modèle, le fichier modèle de PinsScreen, ainsi que la liste des masses qu il veut considérer comme marqueurs. Algorithme 1 Principe général de la simulation de PebbleBox habillée par l écran d épingles {Initialisation} créer le gestionnaire de marqueurs le transmettre au contrôle de simulation initialiser l écran d épingles lancer la boucle de simulation {Squelette temporel} pour tout pas de visualisation faire afficher l écran d épingles pour tout pas de simulation faire si c est un pas d acquisition alors récupérer les positions des marqueurs les calibrer finsi simuler l écran d épingles fin pour fin pour Nous sommes donc partis d un logiciel implantant le procédé d écran d épingles ; après l avoir amélioré dans sa conception et son utilisabilité, nous l avons structuré de telle sorte qu il puisse fonctionner en tant que visualiseur de simulations temps réel. 18/31

Chapitre 3 Retours sur le stage Nous présentons ici le déroulement du stage sous son aspect «projet» : structuration et planification des tâches, apport de connaissances et expériences, retour sur ce qui a été fait et ce qu il reste à faire. 3.1 Gestion de projet Ce stage était soumis à la politique de gestion de projet de l ACROE, et en a donc suivi les conditions, notamment en matière de documentation. La structuration en tâches a été clairement établie dès le début, leurs durées prévisionnelles étaient en revanche volontairement plus floues. semaine tâches prévues tâches réalisées 1 13/05 prise en main du logiciel PinsScreen prise en main du logiciel PinsScreen 2 20/05 recherche de bugs, prise en main des debug sources 3 27/05 debug, extension de l étude 4 03/06 du code (libpinsscreen) 5 10/06 extensions séparation noyau/interface 6 17/06 7 24/06 modèles et tests étude des sources Pebble- Box/libErgonSim, discussion portage PinsScreen 8 01/07 portage temps réel implémentation du prototype 9 08/07 10 15/07 retour sur les deux branches (debug modèles temps réel et séparation) implémentation du portage 11 22/07 12 29/07 réalisation de films Table 3.1 Plannings prévisionnel (au 13/05) et effectif du stage 3.1.1 Plannings Les tâches définies lors de l élaboration du sujet de stage étaient prévues pour pouvoir être adaptées en fonction de la durée du stage et de son avancement. C est la raison pour laquelle plusieurs plannings ont été établis au cours des premières semaines, en tenant compte du fait que les durées prévisionnelles des différentes activités ne pouvaient être fixées très précisément. D une part, il était parfois difficile d anticiper la complexité de certaines tâches : par exemple, comment savoir quelle quantité de travail représentent la spécification et l implémentation de la séparation entre noyau et interface dans le code du 19/31

CHAPITRE 3. RETOURS SUR LE STAGE 3.2. CONNAISSANCES ACQUISES logiciel. D autre part, l avancement a pu être soumis à des questions matérielles, comme une machine pas disponible à temps, ou encore une installation de logiciels plus longue que prévue. Les risques étaient toutefois limités par le découpage relativement clair des tâches. On peut en effet considérer trois activités successives : la prise en main et l amélioration du logiciel PinsScreen, la refonte de son architecture logicielle, et enfin le portage de son noyau sur une simulation temps réel (voir le tableau 3.1, et le diagramme de Gantt en annexe, figure 5). 3.1.2 Suivi de l activité L ACROE a adopté une démarche qualité imposant à chaque personne travaillant au laboratoire de tenir à jour un classeur, servant d outil de communication avec toute autre personne étant amenée à travailler sur le même sujet, ou, dans le cadre d un stage, avec ses responsables. Ce classeur contient tout le travail réalisé durant le stage, sous forme de documents étiquetés selon la norme ISO 9000 simplifiée (on peut en trouver la liste en annexe, tableau 3). Ces documents sont classés selon des types ayant des fonctions particulières : compte-rendus de réunions fiches opération (le travail étant découpé en problèmes suffisamment petits) pour l implémentation logicielle : fiches de spécification, de validation, et d implémentation bibliographie plannings En l occurrence, puisque le gros du travail dans notre cas se ramène à de l implémentation, il était courant de suivre le schéma suivant : le stagiaire rédige le compte-rendu de la dernière réunion, s appuie dessus pour établir une fiche opération fixant le problème, puis propose la manière de l implémenter dans une ou plusieurs fiches de spécification, et enfin, après le retour du ou des responsables de stage et leur validation, procède au codage. Cette rigueur permet de tenir un suivi précis des réflexions et discussions qui se sont tenues - j ai par exemple été amené à chercher pourquoi dans le développement du logiciel telle décision avait été prise, et ai pu trouver la réponse dans le classeur du stagiaire ayant travaillé dessus trois ans auparavant - mais aussi d assurer une certaine sécurité dans les choix faits par le stagiaire, qui est, par définition, inexpérimenté. Des réunions régulières rythment l évolution du stage, avec une moyenne d une par semaine pour ma part. Elles ont pour la plupart été de deux types : celles concernant l orientation globale du stage et les tâches à effectuer ont rassemblé mon maître de stage Annie Luciani et mon responsable technique Nicolas Castagné, celles ayant trait à des questions plus spécifiques au développement (au sens large) n étaient faites qu en présence de ce dernier. 3.2 Connaissances acquises Ce stage m a amené à découvrir et approfondir un ensemble de savoir, qu ils soient strictement techniques ou plus théoriques. 20/31

CHAPITRE 3. RETOURS SUR LE STAGE 3.2. CONNAISSANCES ACQUISES 3.2.1 Génie logiciel Travailler sur un projet de plus grande ampleur de ce à quoi j ai pu être habitué a été formateur sur plusieurs points en matière de génie logiciel. La gestion de versions des codes sources, avec SVN, est un de ces points. En effet, bien qu étant seul à travailler sur ce projet, j ai été confronté à la contrainte de conserver à tout moment le logiciel dans un état stable. C est pourquoi il était nécessaire de développer dans des «branches», duplications du «tronc», avant de pouvoir intégrer les changements effectués au code de l application une fois qu ils ont été validés par mon responsable. On peut également citer le paradigme de programmation qui consiste à séparer le code du noyau fonctionnel d une application de celui de son interface utilisateur, que j ai pu expérimenter en abordant tous les aspects que cela implique. 3.2.2 Technologies À l exception de la bibliothèque Qt, les outils utilisés au cours de ce stage ne m étaient pas inconnus, mais leur utilisation intensive m a fait progresser. En particulier pour le langage C++, et dans un sens plus large la programmation orientée objet, le fait de reprendre un code existant et de cotoyer plusieurs développeurs chevronnés m a permis d approfondir bien des aspects et d adopter certaines bonnes (ou nouvelles) pratiques de programmation. PinsScreen, comme d autres logiciels développés par l ACROE, s appuie fortement sur la bibliothèque Qt, que ce soit pour l interface graphique, les structures de données, l analyse XML, etc. Son utilisation ne diffère pas spécialement d autres bibliothèques courantes (comme Swing pour les interfaces graphiques par exemple), et n a donc pas posé de véritable problème d adaptation. Enfin, d autres aspects m étaient moins familiers et m ont demandé une attention particulière : comment construire et utiliser une bibliothèque logicielle, ou encore comment reconnaître et prendre en compte les limitations matérielles. Un point particulier de ces problèmes techniques concerne l utilisation des processeurs graphiques dans l exécution de l application. Il a en effet été établi, au prix de nombreux tests, que PinsScreen ne pouvait pour l instant tourner qu avec des cartes de la marque Nvidia, et pas avec les pilotes installés nativement. Or l installation des pilotes a pu s avérer fastidieuse sur certaines distributions Linux. 3.2.3 Domaines complémentaires Si l outil informatique est omniprésent dans les activités du laboratoire, leur finalité est très différente de ce que j ai pu expérimenter jusque là. En effet le monde de l art, en l occurrence pour la musique, l image et l animation, ne m était jusqu à présent jamais apparu comme un domaine s appuyant autant sur ces technologies. Cette démarche présente l intérêt de devoir se soucier encore davantage de l utilisabilité des logiciels que l on développe, à plus forte raison lorsque les utilisateurs finaux viennent d univers aussi différents et surtout aussi éloignés de l informatique. D autres aspects plus théoriques ont été abordés au cours de ce stage. J ai en effet dû m intéresser, bien que de manière très superficielle, à certaines notions de physique, puisque les logiciels utilisés simulent le monde réel. Quelles peuvent être les interactions entre des masses mobiles dans l espace, quels paramètres physiques les régissent, sont des exemples de questionnements que j ai été amené à me poser. Enfin, le concept de 21/31