MASTER 2 INFORMATIQUE PROFESSIONNELLE & RECHERCHE UNIFIÉE RAPPORT DE STAGE

Transcription

1 Ministère de l Éducation Nationale Université Montpellier II Facultés des Sciences MASTER 2 INFORMATIQUE SPÉCIALITÉ À FINALITÉ PROFESSIONNELLE & RECHERCHE UNIFIÉE RAPPORT DE STAGE effectué à Ubisoft du 6 Avril au 30 Septembre 2009 par Christophe SICCARDI Directeur de stage de l entreprise Christophe BEAUDET Directeur de stage de l Université Vincent BOUDET TITRE SUR 2 À 5 LIGNES

2 Table des matières 1 Introduction Contexte du stage Présentation de la société Ubisoft Ubisoft Montpellier Activités de l entreprise Projet en cours Équipe de travail Objectifs du stage lettre de mission initiale Travail attendu Planning prévisionnel Les problèmes - Méthodologie - Outils Problématique et questions Visualiseur de miniatures Lecteur d animations Méthodologie Conception Débugage Archivage Outils Matériel Logiciels Synthèse de la solution apportée Visualiseur de miniatures Lecteur d animation Vue générale et gestion du graphe Le graphe d état Le graphe de mixage La vue trois dimensions Lecture d animation Sauvegarde du graphe Gestion des liens

3 Remerciements Je tiens à remercier la société Ubisoft de Montpellier pour accepter de prendre des stagiaires en fin de cursus universitaire et de leur fafire confiance au point de parfaitement les intégrés au sein de leur entreprise. Merci à mon tuteur, M. Christophe Beaudet, tant pour sa patience envers moi que pour la qualité de son encadrement. Merci également aux autres salariés de l équipe de travail dans laquelle j étais, M. Julien Richard, M. Alexandre Brissac et M. Daniel Raviart qui ont fait preuve de beaucoup d intérêt quant à l avancée de mon travail ainsi que pour leur aide plus que précieuse. Merci aux enseignants de L UMII département informatique pour leur gentillesse et la qualité de leurs enseignements, sans qui, je ne serais jamais arrivé là où j en suis. Je pense entre-autre à M. Frédéric Koriche, Mme Thérése Libourel, M. Pierre Pompidor, M. Jacques Ferber, Mme Mountaz Hascoët, M. Eric Bourreau et tant d autres. Merci enfin aux personnes qui liront ce rapport, à celles qui jugeront, critiqueront, ou complimenteront mon travail. 2

4 Chapitre 1 Introduction Dans le cadre du Master 2 Informatique à finalité professionnelle un stage en entreprise d une durée de six mois était à réalisé. Ayant choisi la spécialité I2A (Ingénierie de l Intelligence Artificielle) pour sa spécificité dans la création de jeux-vidéos, je me suis tourné naturellement vers la société Ubisoft pour effectuer ce stage. 1.1 Contexte du stage Présentation de la société Ubisoft Ubisoft a été créé en 1986 par les frères Guillemot et Yves Guillemot occupe actuellement le rôle de président-directeur général. Trois ans plus tard, Ubisoft commence déjà à s exporter. C est aux Etats-Unis, en Allemagne et au Royaume-Uni que les premières filiales de distribution s implantent. Les studios de productions naissent quand à eux en 1992 en France et en Roumanie. En 1995, sort Rayman, petit bonhomme sans bras qui deviendras par la suite une véritable icône et sera le plus grand ambassadeur d Ubisoft. C est nottement grâce à ce succès que l année suivante Ubisoft entre en bourse et ouvre des studios en Chine. C est pendant la fin des années 90 qu Ubisoft s accroît le plus. De nouveaux studios ouvrent dans six villes différentes à travers le monde, dont celui de Montréal au Canada, le plus grand à ce jour. C est aussi grâce à leur nombreuses acquisitions, comme l Américain Red Storm Entertainment (Splinter Cell, Rainbow Six, Ghost Recon), la division jeu de l Américain The Learning Company (Prince of Persia) que l ascension vers le sommet se fait aussi rapidement. En 2001, Ubi entre dans le Top 10 mondial des éditeurs indépendants. A l heure actuelle elle est la plus grande société française de jeux-vidéos. Elle emploi plus de collaborateurs dans le monde (dont plus de en production) ce qui en fait la deuxième force de production interne de jeux vidéo dans le monde avec vingt-deux studios répartis dans dix-sept pays, dont trois en France qui sont situés à Paris, Annecy et Montpellier. 3

5 1.1 Contexte du stage 4 C est grâce à sa force de production qu elle possède plusieurs licences classées Best-sellers Tom Clancy s Rainbow Six R : 21 millions d exemplaires vendus Rayman R : 20 millions d exemplaires vendus Tom Clancy s Splinter Cell R : 19 millions d exemplaires vendus Tom Clancy s Ghost Recon R : 17 millions d exemplaires vendus Petz R : 17 millions d exemplaires vendus Driver R : 14 millions d exemplaires vendus Prince of Persia R : 14 millions d exemplaires vendus Imagine TM : 13 millions d exemplaires vendus Assassin s Creed R : 8 millions d exemplaires vendus The Settlers R : 7 millions d exemplaires vendus Brothers in Arms R : 6 millions d exemplaires Far Cry R : 6 millions d exemplaires vendus Lapins Crétins R : 6 millions d exemplaires vendus Anno R : 5 millions d exemplaires vendus Shaun White : 3 millions d exemplaires vendus Red Steel R : 1 million d exemplaires vendus H.A.W.X. TM : 1 million d exemplaires vendus Les années suivantes sont tout aussi fastes. Ubisoft est très présent sur le marché et se voit attribuer de nombreuses distinctions pour les licences Spliter Cell, Prince of Persia Les Sables du Temps, Far Cry, Beyond Good and Evil, XIII et Tom Clancy s Rainbow Six 3. Des filiales de distribution voient le jour en Corée du Sud, en Finlande, au Canada et en Suisse. Au niveau des studios de développement, le groupe rachète le Montpelliérain Tiwak début Alors que sortent les consoles dites «next-gen», le positionnement précoce d Ubisoft en la matière lui permet de s imposer une nouvelle fois en tant qu éditeur pionnier. En 2007, les voilà ainsi au troisième rang mondial des éditeurs indépendants hors Asie. Ils acquièrent la célèbre marque Driver et continuent de s étendre à l internationale avec la création d une nouvelle filiale au Mexique et l ouverture d un studio de création en Bulgarie. La réussite d Ubisoft ne semble pas connaître de limite. Grâce à l énorme succès de sa licence Assassin s Creed et de ses jeux sur Nintendo DS, de nouveaux studios voient le jour à Chengdu (Chine), Singapour et Kiev. C est donc grâce à son succès que Ubisoft atteint un chiffre d affaire de milliards d euros en 2008/ Ubisoft Montpellier Le studio de Montpellier fut créé en 1990, grâce notamment à Michel ANCEL, qui créa Rayman. Depuis, le studio collectionne les succès : fruit de quatre ans de recherche, Beyond Good and Evil lui a valu d être choisi par Peter Jackson, réalisateur de King Kong, pour l adaptation vidéoludique de son film. Par la suite vint Rayman contre les Lapins crétins qui fut lui aussi un très grand succès et c est aussi en 2006 que sorti de ce même studio l un des plus grand succès de cette année Tom Clancy s Ghost Recon Advanced Warfighter 2. À Montpellier Ubisoft compte des créateurs à très forte sensibilité artistique ainsi que des équipes techniques très performantes. C est d ailleurs là que le moteur de jeu LyN, utilisé internationalement, à été conçu. À l heure actuelle les studios d Ubisoft Montpellier compte plus de 250 collaborateurs et prévoit encore de nouveaux recrutements.

6 1.1 Contexte du stage Activités de l entreprise Actuellement il existe six projets en phase de développement rien que dans les studios de Montpellier. Ces projets sont pour la plupart confidentiels, néanmoins certains ont été annoncés comme : YouUp : un utilitaire fun de webcam pour web messenger. Beyond Good And Evil 2 : La suite du premier opus du même nom. Rabbids Go Home : Un jeu d aventure avec les Lapins Crétins. The Lapins Crétins : La Grosse Aventure ou Rabbids Go Home en anglais, que je nommerais RGH par la suite est, pour le moment le seul jeu est en phase de production dans les studios Montpellierain d Ubisoft. Ce projet, destiné à la plateforme Nintendo Wii uniquement, est un jeu d aventure mettant en scène les fameux Lapins Crétins, déjà célèbres, qui décident de rentrer chez eux sur la lune. RGH est développé grâce à l éditeur et moteur de jeu LyN Technology. LyN est un programme développé par Ubisoft, pour une utilisation interne, et ce depuis Il existe sous deux principales formes qui sont LyN Wii, pour la Nintendo Wii, et LyN Gen3, pour les autres consoles dites de troisième génération comme la Playstation 3 et la XBOX 360. Chacune de ces formes se compose de deux principaux troncs qui sont LyN Editor et LyN Engine. Le premier étant l éditeur qui permet de créer le jeu à proprement parler et le second à le faire tourner. Actuellement aucun jeu créé sous LyN n est encore sorti mais beaucoup de projets en cours l utilise et ce, dans plusieurs studios d Ubisoft. RGH sera donc le premier jeu à sortir entièrement développé sous LyN Projet en cours LyN Editor est donc en perpétuelle évolution et ne cesse de s agrémenter de fonctionnalités diverses et variées afin de mieux répondre aux besoins des différentes personnes qui l utilisent, tant les graphistes 3D que les Gameplay Programmers. C est donc dans ce contexte que j ai rejoint l équipe tools de LyN Wii afin d assurer le maintient des outils déjà en place et d en développer de nouveaux Équipe de travail Je suis sous la tutelle de M. Christophe BEAUDET, lead programmer, qui dirige l équipe tools de LyN Wii. Cette équipe est aussi composée de M. Julien Richard, M. Alexandre BRISSAC et de M. Vincent LUHLLIER. En perpetuel contact avec les différentes personnes du studio cette équipe se doit de faire évoluer au mieux possible LyN editor afin de répondre aux mieux aux attentes et aux problèmes de chacun. En effet ce sont eux qui corrigent les eventuels bugs dans le programme, mais ce sont aussi eux qui développent les fonctionnalités qu on leur demande. Cette équipe subit une pression constante compte tenu du nombre d utilisateur de LyN Editor, et se doit d assurer une stabilité et une efficacité irréprochable dans chacun de ses développements. Car en effet LyN Editor étant le centre de l élaboration du jeu, si celui-ci n est plus opérationel, c est l ensemble de l entreprise qui en pâtirait.

7 1.2 Objectifs du stage Objectifs du stage lettre de mission initiale Le sujet de ce stage est Développement et amélioration du pipeline de création d animation, par la maintenance de l existant et la mise en place de nouveaux outils selon les besoins des productions en cours Travail attendu Je travaille donc au sein de l équipe tools de LyN Wii comme expliqué plus haut et dès mon arrivée mon tuteur m a expliqué plus en détail ce qu il attendait de moi. Visualiseur des miniatures Dans un premier temps j étais chargé de la création d une vue miniature pour l explorer de LyN Editor qui devait être capable d afficher des vignettes d aperçus de tout types de données présent. Cette vue devait comporter toutes les fonctionnalités d un explorer et d un visualiseur de photos, à savoir, des tris par catégories basés sur les caractéristiques génériques des fichiers (nom, poids, type, date de dernière modification, clef du fichier...), différents types de visualisations (mode icônes, images et images plus détails). Parmi les types de fichiers présents on peut trouver, en plus des types habituels, des objets modélisés en trois dimensions qui sont animés, des fichiers représentant des mouvements de particules, des animations, etc... Pour ces fichiers le visualiseur devrait afficher des miniatures interactives lorsque l utilisateur sélectionnera le fichier. Cette interactivité est gérée grâce à une vue en trois dimensions dans laquelle on peut se déplacer, ou encore à l aide d un lecteur de vidéos miniature intégré. La vue se devait d être ergonomique, sobre, intuitive, fonctionnelle et utile afin de séduire le plus d utilisateur possible au sein de l entreprise et de mieux répondre à leurs besoins.

8 1.2 Objectifs du stage 7 Lecteur d animations Une fois cet outil terminé je me suis vu confier la création d un nouvel éditeur qui permet la lecture d animations. Il est composé d une vue en trois dimension dans laquelle le squelette choisit exécute l animation créée grâce aux mélanges des animations sélectionnées. L agencement des animations à été modélisé à l aide d une interface graphique à base de graphes. Le graphe se compose de deux principales parties : Le graphe d états et le graphe de mix. Le graphe d états contient des nœuds qui représentent des animations et les transitions entre celles-ci sont assurées par les liens entre ces nœuds. Le graphe de mix est spécifique à un état et contient les animations qui sont jouées dans cet état. C est dans ce graphe que l on peux mixer plusieurs animations entre elles grâce à un nœud spécial. Entre les états les conditions de passage d un état à un autre sont représentées par les liens entre les états. Ainsi il existe quatre type de contrôleur de passage entre deux états à savoir : L absence de contrôleur, qui se débloque dès la fin de l animation en cours. Le contrôleur de temps, qui lui se débloque au bout d un certain fixé par l utilisateur. Le contrôleur compteur, qui se débloque au bout d un certain nombre d itération de l animation en cours de lecture. Le contrôleur par bouton, qui lui se débloque dès la pression d un bouton (Inclus dans l interface et paramétrable sur une manette de jeu). C est en équipe que nous avons réaliser ce travail, avec M. BRISSAC Alexandre, M. RICHARD Julien et moi-même.

9 1.3 Planning prévisionnel Planning prévisionnel Avril Pour les premiers jours la familiarisation avec LyN est nécessaire ainsi qu avec le code et ses conventions. La première semaine sera donc réservée à cette adaptation ainsi qu au temps nécessaire de faire plus ample connaissance avec mon équipe de travail. La mise en place de l architecture de bas niveau du programme, création des miniatures fixes, du gestionnaires de ressources qui distribue les Bitmaps, des catégories et de l affichage devrait aller jusqu à la fin Avril. Mai La première partie du mois de Mai sera consacrée à l amélioration des fonctionnalités, de l aspect graphique et de l interface à la suite d une première phase de tests. À ce moment là une phase de debugage et le cas échéant d optimisation sera probablement nécessaire. Une partie de l affichage animé étant déjà en place dans les tooltips son intégration ne devrait prendre que quelques jours. Juin L affichage animé des vidéos pourra prendre une quinzaine de jours compte tenu de la librairie à prendre en main. Les commandes d opérations sur les fichiers seront aussi à implémenter car bien qu elles le soit déjà dans l explorer, à terme ce visualiseur devrait être quasi indépendant de l explorer. Un système de cache de fichiers sur le disque local devra être mis en place pour améliorer la vitesse de chargement des miniatures ainsi que sa gestion. Juillet Début de la création du nouvel éditeur AnimPlayer. Mise en place du système de graphe et de l insertion des animations. Travail sur la lecture de animation selon un graphe simple. Août Gérer les transitions entre les états grâce aux contrôleurs. Mise en place du graphe de mix. Phase de debuggage. Au delà, d autres choses seront sûrement à rajouter selon les besoins qui viendrons à la suite d une première utilisation de ce visualiseur. Le temps qu il reste servira donc à rajouter ces fonctionnalités qui me seront demandées ainsi qu à continuer l optimisation et le debugage.

10 1.3 Planning prévisionnel 9 Fig. 1.1 Répatition mondiale d Ubisoft

11 Chapitre 2 Les problèmes - Méthodologie - Outils 2.1 Problématique et questions Visualiseur de miniatures Comme expliqué plus haut dans le descriptif des objectifs de mon stage, je devais réaliser une vue miniature à partir d une liste de fichiers. Le premier problème était de pouvoir réaliser cet outil de sorte qu il soit le plus indépendant possible et le plus générique possible. L indépendance du visualiseur Pour le début une liaison avec l arborescence de fichiers, autrement dit l explorer déjà en place, était à réaliser. Mais cette liaison devait se limiter à l envoi de fichiers dans la Thumbnail View. Car à terme le but était de réaliser un outil complètement indépendant capable de fonctionner uniquement avec une liste de fichier drag n droppés par exemple. Généricité du visualiseur Comme cet outil se devait d afficher des miniatures, il était important de le rendre le plus générique possible. La création des miniatures se devait d être commune à tout types de fichiers et c est ensuite l aperçu qui les spécifies. Rapidité de chargement et espace mémoire Afin de palier à la lenteur logique qu un tel outil subirait deux systèmes de caches ont été implémentés, un cache système tenu par un gestionnaire de ressources, ainsi qu un cache local qui stocke les prévisualisations des fichiers les plus lents à créer. Manipulation classique d un explorer Il fallait, enfin, pouvoir rendre la navigation intuitive pour l utilisateur avec toutes les fonctionnalités basiques de sélection, de tris et du reste. 10

12 2.1 Problématique et questions Lecteur d animations Pour la seconde partie de mon travail dans ce stage la plupart des problématiques sont d ordre plus techniques, spécifiques à la gestion des animations dans LyN. Gestion du graphe Afin d assurer l enchaînement des animations, une vue représentative par graphe était à réaliser. Elle devait fonctionnelle et intuitive afin de ne pas faire perdre de temps aux utilisateurs. La construction graphique de cette vue devait donc respecter les standards de l IHM (Interface Homme Machine), à savoir, entre-autres, la connexion des nœuds par glisser-déposer, la sélection par rectangle et la création des menus contextuels via un clic droit. Visualisation des animations créées Le graphe permettant de monter son animation, une vue en trois dimensions se devait d être présente afin de la visualiser de façon indépendante du moteur. Ainsi cet éditeur n était pas dépendant de l exécution du moteur, plutôt lourde. Assurer le mélange et les transitions Le but premier de cet éditeur était double. En premier il fallait assurer le mélange des animations avec des contrôleurs de poids, pour favoriser telle ou telle animations. Et ensuite assurer la transitions entre l état final de l animation et l état d origine de la suivante. En anglais ces deux tâches s appelle respectivement le mix et le blend. Permettre la sauvegarde de l enchaînement créé Enfin un système de sauvegarde à du être mis en place afin que les utilisateurs puissent utiliser le résultat qu ils ont produit sur cet éditeur, et aussi de reprendre le travail en cours de réalisation.

13 2.2 Méthodologie Méthodologie Conception Les développements qui m ont été assignés étaient de nouvelles choses qui n étaient pas encore présentes dans LyN, il m a donc fallu créer moi-même mes architectures de classes et mon mode de fonctionnement de chacun des outils que j ai eu à construire. Dans ces constructions on peux distinguer plusieurs étapes : La première est la phase d analyse. C est là que nous avons établi quels étaient les besoins et les fonctionnalités que devrait avoir notre futur outil. C est après le visionnage de quelques vidéos ou l essai de logiciels plus ou moins similaires à notre outils que nous décidions plus précisément nos attentes en terme de gestion, de représentation graphique ou encore de fonctionnalités. La création de l architecture. Une fois les besoins ciblés nous pouvions nous permettre d établir une architecture UML de l organisation de notre outil et de créer les classes des objets dont nous avions besoin. Phase de développement. A partir de là nous avons commencer l implémentation des fonctionnalités et de l Interface de notre outil. C est naturellement cette dernière phase qui est la plus longue car elle est entre-coupée de phases de tests et de débugage nécessaires afin de ne pas tout avoir à reprendre à la fin. Pendant cette phase de développement il est très important de respecter les conventions de code du studio. En effet lorsqu une multitude de personnes travaillent sur les mêmes fichiers, il va de soi que certaines règles sont à respectées. En voici une liste non exhaustive : Écrire toutes les macros en majuscules. Préfixer le nom des attributs par un m, pour member, suivit de l initial du type de variable et d un underscore (mi counter, pour member int counter). Mettre un espace après chaque virgules dans les appels de fonctions. Placer les accolades des if ou autres a la ligne. Séparer les fonction par des lignes de pointillées en commentaires.... Et bien évidemment il faut mettre le plus de commentaire possible, en anglais afin qu ils soient compréhensibles par la majorité des gens Débugage Les phases de débugage sont généralement organisées de cette façon : En premier lieu on repère des bugs en utilisant l outil et on les notes sur un papier sous forme de check list avec une brève description afin de reproduire le bug. Ensuite nous nous répartissons les tâches selon les personnes les plus concernées par l origine du bug. Et enfin nous prenons les éléments de la liste les uns après les autres et nous corrigeons les problèmes. Si un utilisateur repère un bug ou un crash, il dispose d une plateforme web nommée JIRA, dans laquelle il peux saisir les bugs qui seront automatiquement assignés au développeur en charge de l outil concerné. Afin de corriger un bug la méthode est assez intuitive. On repère a peu près l origine du problème dans le code et on y met un breakpoint afin d avancer pas à pas pour pouvoir identifier

14 2.3 Outils 13 précisément le comportement gênant lors de l exécution. En cas de crash on tente de reproduire ce crash et une fois ce dernier fait un break automatique est en place ce qui permet de pouvoir visualiser la callstack afin de remonter aisément à l endroit du problème. Pour les cas un peu plus sensibles, comme les décalages de pile, il faut tenté de repéré quelle action entraîne ce décalage et tenté de cibler le plus possible la zone à problème dans le code. Ensuite il faut vérifier l ensemble de ses pointeurs et de ses accès pointeurs afin de voir lequel fait ce décalage. Pour ma part c est ce dernier type de bug le plus difficile à corriger. On pourrait aussi rajouter dans cette section la correction des fuites mémoire qui sont créees par la non-libération des mémoires allouées lors de l exécution, comme les tableaux dynamiques ou les pointeurs. LyN possède sont propre allocateur mémoire qui permet de tracer les allocations effectuées et de notifier les fuites mémoires à la fermeture. Ainsi nous pouvons aisément savoir quel allocation n a pas été libérée et y remédier Archivage Une fois le développement achevé en local nous archivons le code dans la branche. Cet archivage envoie nos modifications sur le serveur. Habituellement la procédure pour nous est l archivage dans la branche tools ou une autre branche de travail et ensuite l intégration de la branche tools vers la branche de production qui sert à générer les exécutables pour les utilisateurs. 2.3 Outils Matériel A mon arrivée dans le studio d Ubisoft Montpellier, un ordinateur neuf, composé d un processeur Intel Core 2 Quad TM cadencé à 3 Giga hertz, fut mis à ma disposition, il était agrémenté, pour la partie graphique d une NVidia GeForce GTX260, et accompagné de deux écrans plats dix-neuf pouces. Coté software, à Ubisoft les ordinateurs sont équipés du système d exploitation Microsoft Windows XP TM Logiciels Comme nous développons sur Windows c est donc naturellement que les ingénieurs développeurs travaille sous Microsoft Visual Studio TM et utilisent le compilateur intégré à ce logiciel. Visual Studio Visual Studio 2005 est un environnement de travail très complet. En effet il permet aisément la création de programmes rassemblant une multitudes de fichiers tout en restant plus ou moins performant. En ce qui concerne la compilation Visual Studio est asser pratique. Il permet en effet rapidement l accès aux erreurs via un simple double-clic sur l erreur, même si certaines contiennent un intitulé parfois mystique. En revanche la plupart du temps ces erreurs sont accompagnées d un code unique pour le type d erreur qui est explicité et détaillé exemples à l appuis sur la documentation en ligne MSDN. Un auter plus non négligeable est qu il possède un débugeur intégré.tandis que nous étions forcés de passer par des moyens détournés pour consulter la valeur d une variable, le retour d une fonction, la raison d un crash ou la présence de fuites mémoire, le débogueur présent dans Visual Studio m a considérablement facilité la tâche. Ce débugeur permet

15 2.3 Outils 14 entre autre d apposer des point d arrêts dans le code (fig 2.1), d avoir la pile d appel de fonctions lors d un point d arrêt (fig 2.2) ou encore d avoir une fenêtre de surveillance des variables de notre choix (fig 2.3). Visual Studio viens aussi avec plusieurs outils de debug assez pratiques comme par exemple spy++ qui m a servi à plusieurs reprise. Cet outil liste l ensemble des ressources graphiques en cours d exécution affiche leurs propriétés et les affiche en surbrillance. Ainsi quand une toolbar ne s affiche pas convenablement ou bien qu elle ait été créée ne s affiche pas du tout spy++ nous donnera ses caractéristiques et ses flags ce qui la plupart du temps suffit à comprendre où est l erreur. Pour finir Visual Studio nous permet aussi d assurer la liaison avec le gestionnaire de version que nous utilisons. Un simple double-clic sur un fichier de la solution va check out le fichier en question pour nous l ouvrir en écriture et l ajouter automatiquement à la changelist en cours. Perforce et les Branches Pour les archivages des données et le versionnage du code le logiciel utilisé est Perforce. Il permet la bonne gestion des fichiers sources de sorte de pouvoir géré lorsque plusieurs utilisateurs modifient les même données. Les fichiers modifiés sont conservé localement sur la machine et apparaissent dans un liste de changements. Une fois les modification finies l utilisateur vas donc soumettre cette liste sur le serveur dans la branche sur laquelle il travaillait. En cas de conflits, si une tierce personne a modifié les mêmes fichiers que lui, l utilisateur se retrouve à effectuer un merge afin de prendre en compte les modifications qui ont été effectuées entre-temps et d intégrer les sienne convenablement. A Ubisoft, nous utilisons Perforce avec un systèeme de branches.ces branches sont des copies de LyN qui évoluent de leur coté et qui sont vouée à être intégrées dans la branche principale, celle de production. Cela donne la possibilité à chacun de travailler sur une branche différente, et donc de modifier le code sans risquer de conflits avec des changements effectués par une tierce personne. La branche de production, la plus importante du système, reçoit ensuite les modifications apportées sur les autres branches qui sont détruites au fur et à mesure. C est à ce moment-là que les conflits sont résolus. L équipe outils de LyN Wii dispose d une branche qui leur est propre et les intégrations dans la branche de production se font une fois par semaine. Ainsi nos développements, qui peuvent parfois mettre en branle tout LyN Editor, ne gênent personne. Mais en contre-partie nous nous retrouvons régulièrement à faire de lourdes intégrations parfois délicates. Jira LyN étant en perpétuelle évolution et subissant de nombreuses modifications faites par plusieurs différentes personnes, il n est pas rare qu il comporte certains bugs. Certains sont de simples problèmes graphiques mais d autres provoquent des crashs. Bien évidement il est de notre devoir de corriger ces bugs. Et pour en être averti le plus rapidement possible afin d y remédier tout aussi vite nous avons à disposition un système de suivi des bugs et de gestion des incidents répondant au nom de Jira. Jira est une plateforme web possédant une instance pour chaque projet Ubisoft en cours. Lorsqu un utilisateur dénote un bug il peut directement le notifier dans Jira qui vas créer une entrée à résoudre par les programmeurs. En cas de crash une entrée est automatiquement créée. Ensuite ces bugs sont affectés à un ingénieur, la plupart du temps celui en charge de la partie fautive, qui se doit de corriger le problème et de rapporter dans Jira la notification de correction

16 2.3 Outils 15 faite. Les entrées peuvent être triées par sévérité, priorité, projet, il est possible d y attacher un ou plusieurs fichiers, par exemple l état de la call stack au moment du crash afin de donner un maximum d informations à la personne qui va devoir faire face au problème... Bref, une solution très puissante pour gérer les incidents. LyN Les fichiers créés par l intermédiaire de LyN sont enregistrés sur le disque dur avec l extension.bf, correspondant au terme «BigFile». Le BigFile est un fichier qui regroupe à lui seul tous les éléments du jeu : les graphismes, les sons, les animations, les dialogues, les scripts... LyN n a pas réellement été pour moi un outil de travail en ce sens que je ne l ai pas utilisé, mais plutôt que j ai contribué à sa réalisation. Cependant, son importance au cours de mon stage a été telle qu il m était impossible de passer à côté dans cette section de mon rapport. Comme décrit plus haut, LyN possède son propre allocateur mémoire ce qui permet de tracer les allocations et de repérer aisément les fuites mémoire (fig 2.4). Néanmoins il existe deux types de fuites : les fuites mémoires allouées par LyN et celles allouées par windows. Ces dernières ne sont pas repérables dans le code mais néanmoins elles sont signalés (fig 2.5).

17 2.3 Outils 16 Fig. 2.1 Points d arrêt dans le code Fig. 2.2 Pile d appel de fonctions Fig. 2.3 surveillance des variables

18 2.3 Outils 17 Fig. 2.4 signalement fuites mémoire LyN Fig. 2.5 signalement fuites mémoire windows

19 Chapitre 3 Synthèse de la solution apportée 3.1 Visualiseur de miniatures Dans un premier temps j étais chargé de la création d une vue miniature pour l explorer de LyN Editor qui doit être capable d afficher des vignettes d aperçus de tout types de données présent. Cette devait comporter toutes les fonctionnalités d un explorer et d un visualiseur de photos, à savoir, des tris par catégories basés sur les caractéristiques génériques des fichiers (nom, poids, type, date de dernière modification, clef du fichier...), différents types de visualisations (mode icônes, images et images plus détails). Parmi les types de fichiers présents on peux trouver, en plus des types habituels, des objets modélisés en trois dimensions qui sont animés, des fichiers représentant des mouvements de particules, des animations, etc... Pour ces fichiers le visualiseur devrait afficher des miniatures interactives lorsque l utilisateur sélectionnera le fichier. Cette interactivité est gérée grâce à une vue en trois dimensions dans laquelle on peut se déplacer, ou encore à l aide d un lecteur de vidéos miniature intégré. La vue se devait d être ergonomique, sobre, intuitive, fonctionnelle et utile afin de séduire le plus d utilisateur possible au sein de l entreprise et de mieux répondre à leurs besoins. 18

20 3.2 Lecteur d animation Lecteur d animation Afin de réaliser ce lecteur d animation, nous nous sommes inspiré d une vidéo d un logiciel existant du même genre, bien que beaucoup plus complet, Morphème. Une fois que nous avions bien ciblé ce que nous voulions nous avons donc établi un diagramme UML qui devait nous permettre de réaliser notre outil. Ce diagramme est composé de deux parties, la partie graphique, qui contient l organisation des fenêtres et des vues que l on va utiliser (fig 3.1), et le second contient les objets qui nous servirons pour gérer ce graphe (fig 3.2). Fig. 3.1 Diagramme UML classes graphiques AnimPlayer Afin de visualiser cette animation il nous fallait une vue en trois dimensions, et pour assurer la gestion de l animation il fallait un graphe modelable sur deux niveaux. Le premier niveau représenterait un graphe d états et le second un graphe de mixage au sein d un état. Voici comment nous avons géré ces contraintes : Vue générale et gestion du graphe Afin de rendre cet outil efficace nous nous devions de simplifier son utilisation au plus haut point. Ainsi réaliser un graphe d états et visualiser un personnage animé avec plusieurs animations devait être une tache des plus rapide à faire. Pour ce faire nous avons réalisé au sein de notre éditeur trois vues, une vue 3D dans laquelle on visionne l objet animé, une vue dans laquelle on construit le graphe d animations voulu, et une troisième contenant les propriétés contextuelles de la sélection en cours (fig 3.3). Pour ce qui est de la manipulation, nous avons voulu faire au plus simple, ainsi la majeure partie de la création du graphe se fait à l aide de la souris via glisserdéposer depuis certaines zones vers d autres. Pour ajouter un état on peux directement déposer une animation depuis l explorer de fichiers vers le graphe ce qui va créer un état avec cette animation à l intérieur. La création d un lien entre deux états se fait par simple glisser-déposer depuis une zone en surbrillance autour du nœud de départ vers le nœud d arrivé souhaité.

21 3.2 Lecteur d animation 20 Fig. 3.2 Diagramme UML classes Objets AnimPlayer 1. La vue 3D qui permet de visualiser l animation courante. 2. Le canevas dans lequel apparait le graphe d état de l animation ou le graphe de mixage correspondant à un état. 3. La fenêtre des propriétés contextuelles selon les éléments sélectionnés. 4. La fenêtre des contrôleurs Le graphe d état Le graphe d état est composé de nœuds et de liens. Un nœud correspond à un état de l animation et comprend une ou plusieurs animations. Les nœuds peuvent être reliés par un ou plusieurs liens qui représentent des transitions entre ces états. Les liens comportent, quand a eux, un contrôleur qui autorise ou non le passage d un état à l autre. Pour le moment il existe 4 type différents de contrôleur : Aucun contrôleur (none) : Passe à l état suivant après la lecture de l état en cours. Contrôleur de temps (Timer controller) : Passe à l état suivant après une durée spécifiée. Contrôleur d itération (Counter controller) : Passe à l état suivant après un certain nombres d itération de lecture de l état en cours. Contrôleur Bouton (trigger Controller) : La lecture changera d état dès que l utilisateur appuiera sur un bouton de l interface ou de son joystick. A noté qu un même Trigger peut être affecté à plusieurs liens. C est ces contrôleurs qui permettent la notion d état de ce graphe. En effet des liens sortant non valides entraîneront la lecture en boucle de l animation en cours. Ces contrôleurs nous permet-

22 3.2 Lecteur d animation 21 tent aussi de mapper les boutons d une manette de jeu pour lancer la lecture de telle ou telle animation. Il est aussi possible, au niveau du lien, de définir une durée de transition entre les deux états, cela s appelle le blend. On défini une durée en image qui va assurer la transition entre l état final d une animation vers l état initial de la suivante. Ainsi on a une continuité du mouvement sans saccade. Pour chaque état, il existe un graphe, dit graphe de mixage, qui permet de définir les animations qui vont être jouées pendant l état ainsi que diverses options de mixage entre ces animations Le graphe de mixage Le graphe de mixage représente l ensemble des animations d un état. Ce graphe ne peut contenir pour le moment que deux types de nœuds, les nœuds animations et les nœuds de contrôle. A l heure actuelle, seul un type de nœud de contrôle est disponible, car c est le seul disponible coté moteur, il s agit du nœud de Mix. Sur la plateforme Nintendo Wii, les contraintes techniques du moteur ne nous autorisé qu un seul nœud de Mix par état et il ne peut contenir que quatre animations additives. Un nœud Animation correspond à un fichier d animation (.trl) qui contient une liste de pistes de modificateurs pour chaque os du squelette à animer. Ces modificateurs peuvent être de différents types, par exemple le type translation qui contiendra un vecteur à appliquer sur un os qui sera interpolé pour obtenir un rendu. Le nœud Mix permet de créer un mixage entre une animation principale (première entrée de la boite) et plusieurs autres. L utilisateur connecte donc une animation principale et plusieurs autres afin de les mélanger à la lecture de la première. Ce mélange peut s appliquer sur un seul os, plusieurs ou même tous les os du squelette. De cette façon on peux mixer une animation de marche d un personnage avec une animation durant laquelle le personnage se penche et ne spécifier que les os de la tête, ce qui donnera en rendu un personnage qui marche en penchant juste la tête, pour regarder sur les cotés par exemple. Le degré de mixage est lui aussi modifiable dans les options. Il permet de choisir le niveau de mixage entre l animation mixée et celle d origine. Ainsi si on met le degré au maximum nous n allons voir que l animation mixée, à contrario à zéro nous ne verrons que l animation d origine. Ce degré de mixage est lui aussi mappable sur la manette de jeu. Pour reprendre notre exemple cela permet de pouvoir faire tourner la tête de plus en plus à notre personnage selon si l amplitude de notre joystick est grande ou pas La vue trois dimensions Cette vue permet à l utilisateur de visualiser la lecture de son animation dépendant de son graphe. Afin de voir ces animations s appliquées sur un objet désigné l utilisateur se doit d avoir chargé dans cette vue l objet en question. Une fois le graphe réalisé l utilisateur dispose d une barre de lecture qui contient les boutons lecture, pause, stop, augmenter la vitesse de lecture, diminuer la vitesse de lecture. Ceci permet donc de voir très précisément l enchaînement des animations sur l objet souhaité. Cette vue étant en trois dimensions l utilisateur peut aussi déplacer la caméra où il le souhaite afin d obtenir l angle de vue qui lui convient le mieux. Il est à noter que nous n avons pas réaliser cette vue qui était déjà présente dans LyN, nous avons seulement hérité de cette classe et implémenté nos propres fonctions de lectures avec le comportement que nous souhaitions.

23 3.2 Lecteur d animation Lecture d animation Une fois le graphe réalisé par l utilisateur, il a fallu être capable d interprété notre graphe d état et de mixage afin de créer un rendu visualisable dans la vue en trois dimensions. Pour ce faire nous avons utilisé un outil déjà présent dans LyN qui se nomme le kit d action. Cet kit d actions sont des tableaux d actions, et une action représente une ou plusieurs animations. Ainsi il suffit de faire une passe sur chacun de nos nœuds d état en créant pour chacun une entrée dans un kit d action et de générer une ou plusieurs actions selon le graphe de mixage contenu dans l état. Une fois ceci fait nous avons un kit d action qui contient chacun de nos états et nos animations sont contenues dans les actions à l intérieur de ce kit. Quand on lit une animation il nous suffit donc de regarder quel nœud est en cours de lecture, de chercher le numéro de l action du kit pour ce nœud, et d appliquer l action sur l objet à animer Sauvegarde du graphe Afin d offrir un éditeur utilisable nous nous devions d implémenter une fonction de sauvegarde des graphes créés ainsi qu une autre afin de les recharger. Pour sauver nous avons utilisé une fonction déjà présente qui permet de créer un fichier sur le BigFile du projet dans lequel nous envoyons nos informations les unes à la suites des autres dans un gros buffer en respectant un ordre précis afin de les recharger dans le même ordre pour tout reconstruire lors du chargement Gestion des liens Dans un représentation par graphe le point clef de l interface est la gestion des liens. Si les liens sont mal gérés alors le graphe sera fouilli et l outil très pénible à utiliser. C est donc pour cela que nous avons passer énormément de temps sur la gestion des liens afin d obtenir un résultat le plus convenable possible. Nous avons commencé par créer des liens en ligne droites enter des point d accroche sur les nœuds situés au milieu des cotés et sur les angles. Mais le rendu ne nous convenait pas complètement, la gestion des doubles liens (aller-retour) n était pas claire et le fait d avoir des liens fixés sur des points posait des problèmes quand on avait plusieurs liens qui partaient ou arrivait sur le même point d accroche. Nous avons donc repris entièrement le système en remplaçant les lignes droites par des courbes de Béziers quadratiques (à trois points de contrôle) avec un système d accroche automatique ou manuel selon le choix de l utilisateur (fig 3.6). En mode automatique le point d ancrage est situé sur le bord du nœud à l intersection de la droite du point de contrôle et du centre du nœud. Ainsi le point d ancrage est totalement mobile autour du nœud et bouge dynamiquement quand on déplace le nœud ou le point de contrôle. En mode manuel le point d ancrage reste fixé la où l utilisateur à souhaité le fixer quoi qu il arrive. Il est cependant forcément en bordure du nœud. Graphiquement un point de contrôle en mode automatique apparait en vert tandis qu il est rouge en mode manuel. Afin de changer de mode un simple glisser-déposer suffit. Si on dépose le point de contrôle sur le bord du nœud manuellement alors il passera en mode manuel tandis que si on le dépose dans la zone centrale du nœud il repasse en mode automatique.

24 3.2 Lecteur d animation 23 Fig. 3.3 vue globale de l AnimPlayer Fig. 3.4 Graphe d état

25 3.2 Lecteur d animation 24 Fig. 3.5 Graphe de mixage Fig. 3.6 Liens en représentation par courbes de Bézier