## II.2.1 Acquisition de logiciels existants

### II.2.1.1 Le logiciel commercial propriétaire, solution par défaut

En 2019, une grande majorité des studios préfère utiliser les logiciels de création 3D* du commerce plutôt que de développer en interne des logiciels de création. Il y a plusieurs raisons à ce choix. D'abord, ces logiciels sont très performants, et ont fait leurs preuves, selon le programme, sur des centaines ou milliers de films. Comparés au développement interne, ils sont très économiques. Créer un logiciel aussi complexe et spécialisé qu'une suite de création 3D demande des milliers d'heures à des ingénieurs hautement qualifiés, et c'est un investissement long à rentabiliser, particulièrement dans un contexte très concurrentiel. Un support et une maintenance doivent être constamment fournies pour corriger les bugs qui pourraient survenir en cours de production. De nouvelles fonctionnalités doivent aussi être régulièrement développées, et une équipe R&D* doit donc travailler à plein temps. Cette possibilité n'est a priori accessible qu'aux plus grosses structures.

La deuxième raison de préférer les logiciels du commerce est que les employés, c'est-à-dire les graphistes, sont dans la majeure partie des cas formés dans des écoles. Ces dernières échangent avec les professionnels afin de former les étudiants aux logiciels les plus utilisés. Inversement, compte tenu du temps et donc du coût de formation des employés, les studios préfèrent souvent utiliser des logiciels répandus. Dans une étude de l'observatoire des métiers de l'audiovisuel parue en 2018 [67], une section est consacrée aux compétences logicielles « en tension », c'est-à-dire recherchées par les entreprises, et pour lesquelles il est difficile de pourvoir les postes. Les quatre premiers logiciels sont des programmes d'animation 2D ou 3D propriétaires, le cinquième est Blender, représentant 8% des compétences recherchées. Une autre catégorie dans la même étude répertorie les compétences « valorisées » par les entreprises et elle est également tenue par les logiciels Autodesk et Adobe. Cet état de fait crée un cycle difficile à rompre entre les formations et les entreprises.

Cependant, on peut modérer cette affirmation, car les techniques de l'animation
évoluent très vite, et on observe des phénomènes de mode, certains logiciels étant adoptés en quelques années, et d'autres complètement oubliés en très peu de temps. Par exemple, en 2019, Houdini<fnref n="1" /> et Substance Painter<fnref n="2" />, commencent à être bien implantés dans les studios et les écoles, même s'ils ne sont pas cités dans l'étude. À l'inverse, un logiciel comme Softimage|XSI, qui était très utilisé pendant plusieurs années, a cessé de l'être presque du jour au lendemain, lorsque son éditeur a arrêté de le commercialiser (cf. section II.1.2).

## Un exemple concret de coût

Afin de déterminer l'impact direct du coût des licences pour un studio, nous allons prendre un cas réel de prévisionnel d'investissement pour le film *Dilili à Paris*. Le choix d'utiliser des logiciels libres a été fait avant le début du projet. On compte dans le nombre de licences le nombre maximum de graphistes travaillant en même temps sur le projet, dans les différents départements. Si nous avions utilisé des logiciels propriétaires, il se serait agi, soit d'un outil de dessin et de peinture (Photoshop), soit d'un logiciel de création 3D* (Maya), soit des deux en même temps, ainsi que d'un logiciel de suivi de fabrication (Shotgun).

<table><caption>TABLE II.2.1 – Estimation du coût des licences pour le projet *Dilili*.</caption><thead><tr><td>Logiciel</td><td>Type de licence</td><td>Nombre</td><td>Coût par licence</td><td>Total sur 18 mois</td></tr></thead><tbody><tr><td>Maya</td><td>mensuelle</td><td>15</td><td>175</td><td>47250</td></tr><tr><td>Photoshop</td><td>mensuelle</td><td>10</td><td>30</td><td>5400</td></tr><tr><td>Shotgun</td><td>mensuelle</td><td>15</td><td>30</td><td>8100</td></tr><tr><td>Windows</td><td>perpétuelle</td><td>15</td><td>280</td><td>4200</td></tr><tr><td>Total</td><td></td><td></td><td></td><td>64950</td></tr></tbody></table>

En comparaison, le prix *minimum* à payer pour un nombre illimité de licences pour Blender, Krita et Linux* est rapide à calculer : 0 €. Un regard non habitué à considérer des questions de gérance et développement technique pourrait voir là une grande écono-

<footnote n="1">1. Houdini est un logiciel de création 3D* édité par SideFX. Au départ destiné aux effets spéciaux, il est de plus en plus utilisé pour effectuer d'autres étapes du pipeline, de la modélisation au rendu.</footnote>

<footnote n="2">2. Substance Painter [54] est un logiciel de texturing permettant une approche procédurale et largement non-destructive de la peinture de surface.</footnote>
mie, qui selon le budget du projet, pourrait rendre un projet immédiatement rentable. Pourtant, il y a d'autres facteurs économiques à considérer dans le choix des logiciels libres.

### II.2.1.2 Le logiciel libre : l'alternative

En effet, les modèles économiques du logiciel libre ne sont pas intuitifs. La première considération souvent abordée quand on parle de logiciel libre est son prix, qui peut prendre la forme d'un achat initial ou d'un abonnement pour une période donnée. De nombreux groupes ou individus peuvent être préoccupés par le coût des programmes : les individus qui ne peuvent s'offrir de licences légitimes des programmes commerciaux ; certaines formations, pour lesquelles les tarifs pratiqués par les éditeurs ne sont pas toujours en adéquation avec leur budget de fonctionnement ; les étudiants, auxquels les éditeurs proposent cependant souvent des licences éducatives gratuites. Mais la question intéresse aussi les studios, pour lesquels la gratuité des licences peut sembler constituer une économie substantielle.

#### Logiciel libre, mais pas forcément gratuit

L'idée communément admise selon laquelle le logiciel libre est nécessairement gratuit dénote une incompréhension. Le calcul précédent, arrivant à une somme de 0 € pour les licences, est trompeur à plusieurs titres.

D'abord, ce calcul part du problème terminologique associé au logiciel libre, en anglais *Free Software*, que beaucoup comprennent comme signifiant « gratuit » plutôt que « libre ». Cette mauvaise interprétation s'est largement transmise en français, où on entend fréquemment l'expression « logiciel libre et gratuit ». En pratique, les licences libres accordent aux utilisateurs le droit de redistribuer gratuitement ou commercialement le code. Il est donc difficile pour les éditeurs de logiciels libres d'obtenir un monopole commercial sur leurs programmes. En revanche, rien ne les oblige à donner leur code.

D'autre part, l'équation « je ne suis pas obligé de payer » = « je ne dois rien à personne » est simpliste. Si elle est strictement vraie légalement, y compris pour un logiciel
téléchargeable gratuitement, elle ne rend pas compte du fait que le développement des logiciels est en partie financé par les dons, et que les utilisateurs en profitent directement. Les entreprises ont donc tout intérêt à donner de l'argent aux développeurs afin de leur permettre de corriger et d'améliorer les programmes qu'elles utilisent, et elles sont les mieux placées pour le faire. Une question légitime pourrait être : combien ? Il n'y a pas de consensus en réponse à cette question, mais on pourrait dire en première approche que dès que l'entreprise en a les moyens, elle devrait approcher le prix qu'elle aurait consacré à des logiciels commerciaux équivalents.

## Flexibilité du nombre de licences

Outre ce coût initial, un facteur important à considérer par une production est l'estimation du nombre de licences. En effet, c'est un calcul qui fait partie du budget d'un projet, et éventuellement des frais de fonctionnement d'une société. Le nombre de postes peut beaucoup varier d'une production à l'autre, et même d'un moment à l'autre d'une production. Ainsi, lors du passage de la préproduction à la production, il peut être nécessaire d'engager beaucoup de graphistes d'un coup<fnref n="3" />. Le nombre de postes augmente proportionnellement, ce qui signifie que les licences doivent être commandées en conséquence.

Parfois, un imprévu demande d'engager de la main-d'œuvre qui n'était même pas prévue dans les plannings et budgets prévisionnels, ce qui a également un impact puisqu'il faut prévoir suffisamment de licences pour que chacun puisse travailler. Bien sûr, les licences ne sont pas le seul poste de dépense affecté, car il faut également prévoir les machines, les bureaux, et même simplement les locaux en conséquence. Mais c'est tout de même un facteur important pour la souplesse de production.

Le fait d'utiliser des logiciels libres réduit ce problème à néant, car même si le logiciel était payant, c'est-à-dire s'il fallait payer pour en obtenir une copie, une licence libre confère à la société le droit d'installer le programme sur un nombre illimité de postes de

<footnote n="3">3. En France, ces graphistes sont généralement intermittents, ce qui encourage la souplesse de ce type de projet.</footnote>
travail, éternellement, et de le redistribuer comme bon lui semble (cf. section II.1.1.1).

## II.2.2 Développement interne des logiciels

### II.2.2.1 Contrôle de la chaîne de fabrication

À l'opposé de l'acquisition de logiciels existants, le choix du modèle de développement interne offre un contrôle total à la structure puisqu'elle est non seulement maîtresse des droits d'exploitation du code, mais qu'elle peut l'étendre autant que nécessaire pour répondre aux nouvelles contraintes apportées par un projet ou par le marché. En tant que secret industriel, ce modèle pouvait en outre offrir un avantage concurrentiel considérable à une époque où les studios et les éditeurs de logiciels étaient moins nombreux. Cet avantage se réduit concernant les programmes de fabrication, mais il existe encore dans certains domaines précis.

Comme l'écrit François Elie dans le contexte du logiciel libre [3] :

> « On réduit souvent l'économie du logiciel au domaine de l'édition logicielle. Pour un éditeur, les choses sont très simples : il faut investir, payer des gens pour programmer et se refaire en vendant le plus possible de licences de son logiciel. Le retour sur investissement peut être colossal (ou nul), et les marges très élevées.

> « Or, il s'écrit beaucoup de logiciels en dehors des circuits de l'édition. Au sein des entreprises, il peut y avoir des informaticiens qui produisent du logiciel et les entreprises peuvent recourir à du service, qui peut donner lieu à de l'écriture de logiciels. Il faut donc intégrer cet immense pan d'activité lorsqu'on parle d'économie du logiciel. C'est d'autant plus important que ce « chacun pour soi » est un gaspillage de ressources, car il conduit à refaire tous un peu la même chose. »

L'observation d'Elie est valable dans le domaine de l'animation, car même si beaucoup de studios utilisent des logiciels du commerce, la pratique du développement interne existe toujours, en particulier dans les gros studios, où les équipes R&D* sont indispensables au bon fonctionnement des productions. Ceci dit, en ce qui concerne les logiciels de création, seules quelques sociétés en France dépendent entièrement d'outils internes.
On peut par exemple citer la société BUF [17].

En s'industrialisant progressivement, beaucoup de studios élaborent leurs outils de gestion d'assets, de suivi de production, et plus généralement de pipeline*. Ils choisissent parfois des outils du commerce comme Shotgun, mais beaucoup développent leurs propres outils, pour plusieurs raisons. Ils peuvent vouloir fonctionner sans dépendre d'éditeurs logiciels (cf. section II.1.2). Les conditions d'accès aux logiciels propriétaires peuvent être trop restrictives, par exemple dans le cas d'un parc informatique très grand ou très variable, demandant de nombreuses licences ou un nombre fluctuant de licences, ce qui entraîne dans un cas une facture conséquente, et dans l'autre une gestion complexe (cf. section II.1.1.1). Enfin, ils peuvent souhaiter avoir une totale maîtrise de leurs processus, ce qui n'est pas toujours possible avec des logiciels propriétaires impossibles à modifier (cf. section II.1.1.3).

### II.2.2.2 Fonctionnalités développées par la communauté

Un autre facteur économique à considérer pour un studio est le coût de développement d'outils internes, en plus des applications principales. Ces outils peuvent être des scripts* et add-ons*, comme l'exemple du rig de pantins exposé à la section III.3.1. Ce type de développement dédié à un projet est presque toujours nécessaire dans les studios, et les programmes, commerciaux comme libres, permettent ces extensions grâce à leurs interfaces de programmation. Cependant, le cas du logiciel libre est différent, dans la mesure où les développements internes peuvent être dans certains cas intégrés au logiciel principal par la suite.

Les développeurs principaux d'un projet de logiciel libre n'ont pas forcément les mêmes priorités que les studios, et ne proposent pas toujours rapidement des fonctionnalités qu'on pourrait qualifier de « standards ». Par exemple, la bibliothèque* de cache* de géométrie Alembic (cf. section II.3.2.1) a mis plusieurs années avant d'être incluse dans Blender, même si elle était considérée comme incontournable par une grande partie de l'indutrie, et même si les autres logiciels de 3D l'avaient pour la plupart déjà intégrée. Mais son intégration ne figurait pas dans la feuille de route de la fondation Blender, qui
préférait affecter ses ressources à d'autres projets. Le studio français Dwarf Animation a créé un patch* permettant d'utiliser Alembic, et l'a proposé aux développeurs de Blender<fnref n="4" />. Afin de répondre à la demande de nombreux utilisateurs, et puisqu'une grande partie du travail de design et de développement était déjà faite, ces derniers ont terminé l'intégration du code, et Alembic a été disponible dans les versions suivantes.

Un exemple très similaire est celui de Cryptomatte, un système permettant de décomposer une image en différentes couches, selon des identifiants d'objets et de matériaux. Cette bibliothèque a été d'abord intégrée à Blender par le studio canadien Tangent Animation pour les besoins d'un long-métrage, puis proposée, corrigée d'après les critiques des développeurs, et intégrée dans Blender.

On voit que le fait de pouvoir étendre le cœur de Blender est acquis avec l'obtention du programme, et ces extensions peuvent soit rester internes à un studio, soit servir à toute la communauté. De fait, les sociétés peuvent aussi utiliser leurs ressources internes pour leur propre intérêt, mais aussi celui de la communauté, et profiter en retour de développements d'autres sociétés.

De même, pour une société indépendante développant des programmes pour son propre usage, la publication en open source peut être intéressante. Comme le déclare le créateur du logiciel Storyboarder (cf. section III.2.1), Charles Forman, sur le site web du logiciel, Storyboarder a été créé au sein d'une société de production de film, qui « gagne de l'argent en faisant des films, et non pas des logiciels » [45]. Il ajoute que le logiciel répond à un besoin de niche, et que pour que le logiciel soit profitable, il faudrait le vendre pour un coût exorbitant. La décision de le publier sous licence libre est donc logique, puisque la société ne compte pas gagner d'argent avec le logiciel, mais peut espérer profiter d'un développement communautaire pour l'améliorer.

La mutualisation des coûts de développement est donc intéressante économiquement, pour peu qu'assez d'acteurs travaillent sur un logiciel, c'est-à-dire pour peu que la communauté soit suffisamment établie, et le logiciel adopté.

<footnote n="4">4. On peut lire les échanges entre le studio et les développeurs sur la forge de Blender, à l'adresse suivante : https://developer.blender.org/D1783</footnote>
II.2.3 Financement du développement logiciel

Le développement informatique demande des ressources : du temps et de l'énergie. Ce lieu commun est utile à rappeler dans le contexte du logiciel libre, car il pose des questions fondamentales sur la manière dont les logiciels sont développés. On parle parfois du logiciel libre et open source avant tout comme d'un passe-temps, une passion qu'ont les développeurs pour la découverte, le partage, ou simplement la joie de la création, comme par exemple ÉLIE [3, § Le modèle communautaire d'individus]. Beaucoup consacrent du temps à cette passion, sans attendre de compensation financière. Comme l'expliquent JULLIEN et ZIMMERMANN [13], ce modèle n'est viable que pour des individus développant des petits programmes en dilettante, sans commercialisation ni support, et sans attente de la part des « clients ». Dès lors qu'un projet prend assez d'ampleur, les ressources nécessaires à son développement dépassent les capacités d'un seul programmeur du dimanche. Il faut alors y consacrer plus de temps, soit en attirant d'autres développeurs bénévoles structurés autour d'une communauté, soit en embauchant des développeurs professionnels, c'est-à-dire rémunérés pour leur travail. Pour cela, il est nécessaire de trouver un financement.

Plusieurs modèles de financement open source ont émergé, qui sont souvent complémentaires. Ils sont étudiés du point de vue du logiciel lui-même, c'est-à-dire les moyens employés par la communauté pour développer le logiciel. Nous nous concentrerons plus particulièrement ici sur l'action des studios dans ce développement.

Salariat

Beaucoup de développeurs open source sont salariés par une entreprise ou une as-
sociation et développent leur logiciel dans ce cadre. Le groupe, à son tour, peut avoir
différents modèles économiques. Certaines entreprises de développement logiciel vendent
du service pour des logiciels libres (support, maintenance), et le développement du lo-
giciel est alors au cœur du modèle économique, puisque les anomalies corrigées pour les
clients dans le cadre d'un contrat de support sont reportées dans le code public.
Pour d'autres structures, le développement logiciel est secondaire. Ces sociétés ont une autre activité principale, et investissent dans leur R&D* pour développer des logiciels qui peuvent leur être utiles indirectement. C'est souvent le cas des studios d'animation, dont l'activité principale est la production et la fabrication de contenu audiovisuel, mais qui s'appuient pour cela sur l'informatique. Ils doivent donc allouer des ressources au développement et à la maintenance de leurs outils, soit dans le cadre d'un département R&D à part entière, soit informellement, par les graphistes eux-mêmes ou les TD*. Pour les studios qui utilisent des logiciels libres et souhaitent y contribuer, c'est-à-dire rendre publics leurs outils, proposer des correctifs ou des améliorations à l'inclusion dans le programme, la participation à des projets peut augmenter le coût de développement, car les exigences d'un logiciel public peuvent être plus élevées que celles d'un outil ad hoc développé en interne pour une production. De plus, les interactions nécessaires avec la communauté peuvent prendre du temps aux développeurs. Néanmoins, si un outil a été développé une fois pour une production, s'il est susceptible d'intéresser d'autres utilisateurs, et si son développement est pensé dès le départ pour une publication, le surcoût entraîné peut être limité.

## Dons

Un autre modèle de financement des programmes open source est le don des utilisateurs ou d'entreprises. Ces projets fonctionnent alors grâce à un système de mécénat<fnref n="5" />. Certains projets ont une approche hybride, comme la Blender Foundation, qui salarie des développeurs avec des dons des utilisateurs, ainsi que des bourses conséquentes d'entreprises du secteur de l'animation ou du jeu vidéo<fnref n="6" />. Il est particulièrement important pour les studios d'animation de considérer les partenariats qu'ils peuvent établir avec les projets des logiciels qu'ils utilisent, selon leur stratégie de développement. On peut considérer qu'une bourse ressemble à une externalisation du développement, dans la me-

<footnote n="5">5. C'est le cas par exemple de Krita et de Godot, qui proposent en option aux utilisateurs de donner de l'argent pour supporter le développement, soit ponctuellement, soit régulièrement.</footnote>

<footnote n="6">6. Ainsi, des entreprises comme Ubisoft et Epic Games ont annoncé en 2019 l'octroi de bourses de développement conséquentes sur plusieurs années. Ces bourses sont gérées par la Blender Foundation, qui conserve la maîtrise d'œuvre sur le développement du programme.</footnote>
sure où le travail effectué par les développeurs du logiciel sera utile au studio. Il est vrai
que dans les exemples cités, les entreprises donatrices n'ont pas officiellement de contrôle
sur les décisions des développeurs. Cependant, dans le cas d'Epic, il était entendu que la
bourse octroyée à Blender devait conduire à des améliorations dans un domaine précis <fnref n="7" />.

Subventions

Les subventions publiques constituent une autre source de financement pour les en-
treprises. Dans l'animation, il existe des aides régionales à la production, pour la fabri-
cation des films. Une partie de cette subvention peut être imputée au développement
informatique pour un projet précis. Mais il existe aussi des aides spécifiquement dédiées
au développement d'outils dans le cadre d'une opération de R&D. Ainsi le CNC* peut
accorder aux entreprises du secteur un soutien financier aux industries techniques. Cette
aide concerne les entreprises présentes sur le territoire, et peut soutenir plusieurs caté-
gories de travaux, parmi lesquels le développement et l'innovation. Dans cette catégorie,
l'aide à un nouveau produit ou nouveau service concerne spécifiquement les outils « à
destination commerciale ou qui [permettent] d'engendrer une augmentation chiffrable
de [la] productivité » [62]. Dans le cadre de cette aide, le taux de soutien (pourcentage
des dépenses pour un projet) est plus élevé pour les logiciels « diffusés gratuitement ou
en logiciel libre » que pour les autres (60% contre 45%).

Développement externe pour les studios

Un modèle économique souvent adopté par les développeurs de logiciels libres est
celui de la prestation de service : le logiciel est libre, et son développeur ne le commer-
cialise pas. En revanche, il monnaie du service annexe au logiciel. Il peut développer des
fonctionnalités pour le compte d'une entreprise, fonctionnalités qui seront ensuite ren-
dues disponibles pour la communauté. Il peut s'agir de support technique, de formation,
de maintenance. Un exemple notable est le système d'exploitation GNU/Linux*, dont

<footnote n="7">7. L'annonce officielle de la bourse stipule : « L'Epic MegaGrant sera versée progressivement durant les trois prochaines années, et contribuera à l'initiative de développement pour professionnaliser Blender. » (Traduction de l'auteur)</footnote>
il existe de nombreuses variantes appelées distributions, et dont certaines sont commer-
ciales. La distribution Red Hat, répandue dans les décennies 1990 et 2000 a exploité ce
modèle en vendant du service aux entreprises.

Ce modèle a été également adopté par des développeurs de logiciel libre dans le cinéma d'animation, et plusieurs exemples existent en France. Ainsi, Frank Rousseau, auteur du logiciel de gestion de production Kitsu [53] au sein de sa société CGWire, est financé depuis 2017 par plusieurs studios pour développer son logiciel. Il le développe en permanence, en lien avec un ou plusieurs studios à la fois, tout en faisant du support et de la maintenance [36]. Le fruit de ces développements prioritaires est reversé dans le code source* public, et les studios bénéficient des améliorations conçues avec ou pour d'autres clients.

Une autre manière de mettre en commun le développement entre studios se pro-
duit lorsqu’un même outil est utilisé et développé en interne par plusieurs studios. Par
exemple, le framework* Kabaret (cf. section III.5.1.2) de Damien Coureau, a d’abord
été développé pour le studio Supamonks, et publié ensuite sous licence libre. Il a été
notamment adopté et adapté par Flavio Perez, directeur technique sur le pipeline* des
Fées spéciales. Le principe de ce programme, en tant que framework, est d’offrir un
environnement de développement permettant d’écrire sa propre solution. Il faut donc
nécessairement du développement pour construire un pipeline autour, mais la solution
est conçue pour faciliter ce développement en offrant une architecture et des commandes
logiques et facile à étendre. Flavio avait testé une première version plusieurs années aupa-
ravant, mais n’en avait utilisé que quelques fonctions, estimant que le framework n’était
pas assez mûr. Au moment de définir le pipeline des Fées, Flavio a contacté Damien pour
lui demander la dernière version de Kabaret, qui était en bêta privée à cette époque. En
l’utilisant pour écrire son pipeline, il a alors engagé des discussions avec le développeur
afin de l’améliorer, et le rendre plus facile à adapter à des cas non prévus. Non seule-
ment ce retour d’expérience a été précieux pour continuer le développement, mais les
Fées spéciales ont également fourni directement le code de ses améliorations au studio
Supamonks.
Ainsi, le développeur du studio original, en publiant son code source*, bénéficie des
améliorations d'autres studios. Cela demande du temps pour former ses interlocuteurs, et
fédérer une communauté de développeurs, mais in fine, d'autres personnes développent
« à sa place » (cf. section II.3.3.4).

Conclusion : le coût global des logiciels

Beaucoup d'utilisateurs parmi le public et au sein des studios ont intériorisé l'équivalence *logiciel libre* = *gratuit*, y compris au sein des Fées spéciales. Il n'est pas rare d'entendre prononcer en réponse la phrase « Le logiciel libre, c'est trop cher » par les membres de l'équipe technique, lors de réunions de projets visant à établir le *pipeline*\* de fabrication.

Cette formule n'est pas toujours vraie, mais elle est utile à considérer dans certains
contextes, particulièrement en entreprise où les budgets imposent la rentabilité écono-
mique. Ce qui est entendu par là est que, pour exécuter une tâche précise, il est parfois
économiquement plus intéressant à court terme d'utiliser un outil propriétaire. Cela dé-
pend de la récurrence de la tâche, de l'existence et de la performance d'un outil libre
conçu exprès, et du coût de développement d'un outil spécifique. En d'autres termes, il
n'est pas toujours réaliste ou possible de faire l'investissement nécessaire pour dévelop-
per ou faire développer un outil. De même, la formation à des outils nouveaux a un coût
et prend du temps, et les entreprises n'en ont pas forcément les ressources en cours de
production.
# Chapitre II.3

## Usages du libre : considérations techniques

### Introduction

Le logiciel libre a des particularités économiques et juridiques importantes pour les studios d'animation, des contraintes et des possibilités particulières. De la même façon, le logiciel libre peut offrir aux studios des façons différentes de travailler, et de développer leurs outils et leurs projets.

Nous verrons dans ce chapitre les éléments concrets qui peuvent concerner les studios d'animation lors de l'utilisation du logiciel libre : le rôle de l'innovation dans le développement logiciel, et de quelle manière elle peut pousser à l'adoption du logiciel libre ; l'importance critique des formats d'échange pour l'animation ; et les procédures types permettant de contribuer à l'élaboration des logiciels avec leurs communautés.

### II.3.1 Innovation des logiciels de création

L'innovation est au cœur du développement informatique et des industries qui utilisent des outils numériques. Les éditeurs de logiciels se livrent donc généralement une compétition pour l'innovation de haute technologie. Cette innovation a lieu à plusieurs
niveaux. Il s'agit soit d'intégrer des pratiques existantes<fnref n="1" />; soit d'intégrer des algorithmes récents, pour le rendu ou le traitement de signal; soit de créer des systèmes complètement originaux pour changer la manière de produire les images.

Dans cette compétition pour l'innovation, certains logiciels libres ne font pas exception. Ils se démarquent cependant des logiciels propriétaires à plusieurs titres. D'abord, même si les développeurs prennent de grands soins pour ne pas casser la rétro-compatibilité avec les versions précédentes, ils ont moins de difficultés à revoir complètement l'interface ou le fonctionnement. Par exemple, le logiciel Blender a publié deux versions majeures<fnref n="2" /> cassant dans une grande mesure la compatibilité avec les versions précédentes. À deux reprises en moins de dix ans, l'interface du programme a été modifiée en profondeur, ainsi qu'un grand nombre de systèmes (moteurs de rendu, graphe de dépendance, API* de scripting). Les fichiers restent globalement compatibles, mais certaines données et fonctions sont perdues. Cette politique de rupture dans les versions majeures permet d'abandonner des parties anciennes du programme, et d'ajouter des nouvelles fonctions, qui peuvent être l'occasion d'une plus grande innovation.

Parmi les nouvelles fonctions de la version 2.80, deux exemples sont particulièrement intéressants, car ils illustrent chacun dans son domaine le caractère innovant du programme, et les particularités par rapport à des modèles de développement plus conventionnels. Le premier est Eevee, un moteur de rendu (cf. section III.3.2) utilisant les technologies de rendu dit « temps réel », c'est-à-dire développées initialement pour les applications temps réel comme les jeux vidéo. Le deuxième est le *Grease Pencil*, un outil de dessin et d'animation dans l'espace 3D, existant déjà depuis 2008 et permettant d'animer depuis 2015, mais ayant fait l'objet d'une profonde rénovation pour la version 2.80.

<footnote n="1">1. Par exemple, la réalité virtuelle, qui récemment a explosé auprès du grand public et que les éditeurs de logiciels de création 3D* commencent à intégrer pour profiter de nouveaux paradigmes de création; ou bien le rendu physique réaliste (Physically-Based Rendering, PBR), apparu au début des années 2000 et rapidement adopté par tous les éditeurs.</footnote>

<footnote n="2">2. Il s'agit des versions 2.50, sortie en 2010 et 2.80, sortie en 2019.</footnote>
## Eevee

Eevee est un moteur de rendu intégré à Blender et développé spécifiquement pour lui. Il a été en partie conçu par le développeur Clément Foucault. Vers 2016, ce dernier a créé un fork* de Blender et travaillé indépendamment pour améliorer le rendu interactif dans la vue 3D (viewport). Ses vidéos de démonstration et les versions qu'il a publiées ont suscité l'enthousiasme de la communauté et des développeurs, si bien qu'au moment où la Blender Foundation a commencé à développer la nouvelle version majeure (2.80), il a été engagé pour continuer son travail au sein de la fondation. Au lieu d'améliorer simplement la prévisualisation dans le viewport, le développement a été étendu à un moteur de rendu complet, destiné à remplacer le moteur vieillissant intégré à Blender, le Blender Internal. Cela offre l'avantage de permettre à la fois une prévisualisation interactive réaliste, plus proche du rendu définitif, et des rendus en temps différé moins réalistes qu'un path tracer comme Cycles, mais beaucoup plus rapides. Le développement de ce nouveau moteur n'a donc été possible qu'à cause de l'abandon de l'ancien moteur lors du passage à la nouvelle version.

## Le Grease Pencil

Le Grease Pencil est un outil de dessin dans Blender, permettant de faire du dessin animé directement dans la vue 3D. Il tire son nom d'un outil de dessin traditionnel, utilisé notamment pour annoter les images sur pellicule. Développé initialement en 2008 pour la version 2.47 de Blender, en tant qu'outil d'annotation, il a peu à peu évolué en outil complet d'animation, en particulier sous l'influence de l'animateur espagnol Daniel Martinez Lara. Ce dernier n'est pas développeur, mais c'est un animateur et formateur qui dirige une école d'animation et il est très impliqué dans le développement de Blender en tant qu'expert. Entre 2017 et 2018, l'outil a été développé par le développeur Matias Mendiola en collaboration avec Martinez Lara au sein de l'école de ce dernier, dans le cadre de la production d'un court métrage utilisant l'outil, Hero. Il a par la suite été réintégré dans le code de Blender à l'occasion de la nouvelle version.

L'outil actuel dans Blender suscite un fort engouement du fait de la potentialité
pour des méthodes de fabrication hybrides entre le dessin animé « traditionnel » et l'animation 3D. Mais il ne faut pas oublier que cette version est l'aboutissement d'un long développement itératif, et que l'outil n'avait pas du tout été pensé pour cette application initialement.

Dans le cas de cet outil, l'innovation provient d'une combinaison de facteurs. D'abord la création d'un outil limité mais prometteur dans sa première version pour l'annotation. Ensuite, l'intuition d'un utilisateur de la capacité de l'outil à être détourné et exploité dans un but beaucoup plus intéressant, et sa volonté à voir aboutir cette intuition. Puis, la capacité qu'il a eue de faire lui-même le travail en engageant un développeur pour mettre en œuvre ses idées, avec l'aval des développeurs de Blender. Cette capacité est due à la nature open source du programme, qui lui a permis de développer un fork*, puis de réintégrer ce fork dans le code du programme.

L'innovation dans le logiciel libre n'est donc fondamentalement pas différente des autres modèles de développement, mais la prérogative n'en est pas nécessairement à l'éditeur, et de bonnes idées peuvent donc surgir de la communauté, et se voir à terme intégrées au logiciel.

## II.3.2 Interopérabilité et standardisation

On l'a vu, le pipeline* d'un film d'animation se compose de nombreuses étapes interdépendantes. Chaque étape peut être réalisée par un logiciel différent, et plusieurs logiciels sont parfois utilisés pour une même étape. Pour que ces logiciels soient compatibles, il faut que leurs créateurs tombent d'accord sur des formats et composants communs.

### II.3.2.1 Formats d'échange

Certains formats de fichiers* sont conçus pour représenter les données d'un programme donné. Ils peuvent suivre de près la structure de données et la logique internes du programme. À l'inverse, les formats dits d'échange sont spécifiquement conçus pour
transmettre les données d'un programme à l'autre selon une spécification plus générique, c'est-à-dire moins intimement liés à un programme précis<fnref n="3" />.

Certains formats d'échange vont plus loin, en étant maintenus par des organisations de normalisation, ce qui incite les développeurs à respecter un standard<fnref n="4" />, et rend donc les formats en question plus compatibles. Ce sont ces formats ouverts et standards qui sont de plus en plus adoptés par l'industrie de l'animation.

## Formats propriétaires

Parmi les formats de fichiers, qu'ils soient propres à un logiciel ou des formats d'échange, beaucoup sont dits propriétaires. Cela signifie que des dispositions légales ou techniques empêchent les développeurs de les intégrer dans leurs propres programmes, et par extension, les utilisateurs de s'en servir en dehors de l'utilisation prévue. Les dispositions qui rendent propriétaire un format peuvent être le fait que sa spécification n'a pas été divulguée, ou des brevets logiciels empêchant simplement de l'utiliser.

Si un format propriétaire est utilisé sans être documenté publiquement, il est très difficile de l'utiliser dans un autre contexte que celui prévu par l'éditeur, et donc de l'inscrire dans un écosystème logiciel plus large. Cette difficulté est d'abord technique, car si les spécifications du format ne sont pas connues, et que le code source* du programme permettant de lire et écrire ce format est fermé, la seule possibilité restant aux développeurs pour comprendre le format est de faire de la rétro-ingénierie, c'est-à-dire de

<footnote n="3">3. Un exemple parlant est celui des formats d'image. On ne pense plus guère aujourd'hui, quand on envoie une image au format JPEG, qu'il n'a pas toujours existé. C'est un format standard, universel et compris par tous les ordinateurs, navigateurs, programmes de création ou d'affichage d'image. Pourtant, son cahier des charges a un jour été conçu, les algorithmes développés et implémentés, et finalement un standard a été ratifié. En respectant strictement ce standard, les différentes technologies permettant de créer et d'afficher une image JPEG garantissent à l'utilisateur que l'image sera transmise comme prévu : sans corruption, et en respectant les couleurs définies par le créateur. Cela n'évite pas tout problème de compatibilité dans la mesure où la mise en œuvre correcte du format reste toujours à la charge des développeurs. Mais contrairement aux formats propriétaires, les développeurs ont du moins accès à des documents fiables leur permettant de le faire.</footnote>

<footnote n="4">4. J'emploie dans ce chapitre le terme « standard » plutôt que « norme », d'une part car c'est un mot fréquemment utilisé par les professionnels, par anglicisme, et ensuite parce que les formats de fichiers et processus informatiques propres à l'animation sont rarement normalisés par des organisations publiques, mais créés au sein de la communauté. Le cas du format JPEG est justement différent, car il s'agit d'une norme internationale.</footnote>
décortiquer le fonctionnement du programme sans avoir accès aux sources. Ce processus est long, complexe et incertain. De plus, il est à la limite de la légalité dans beaucoup de juridictions. Un article de l'Electronic Frontier Foundation [31] détaille les risques de poursuite encourus aux États-Unis. Pour résumer, des précautions extrêmes doivent être prises dans la méthodologie de rétro-ingénierie pour ne pas être dans l'illégalité. En Europe, la question n'est pas complètement tranchée, mais la protection des logicielles demeure très puissante<fnref n="5" />.

Ce problème des formats de fichiers propriétaires est récurrent en informatique. On peut considérer qu'il nuit à l'interopérabilité* et restreint les utilisateurs dans leur choix. De plus, c'est encore une dépendance des utilisateurs aux éditeurs, puisque ces derniers sont seuls en capacité à autoriser ou interdire l'utilisation du format, via la licence qu'ils concèdent. S'ils décident de ne plus supporter le format, celui-ci peut devenir obsolète très rapidement, sans recours pour les utilisateurs.

Avant d'aborder l'utilisation des formats ouverts, j'exposerai les problèmes observés avec le format propriétaire FBX, créé par Autodesk. Ce format très répandu permet de stocker des données 3D (maillages, armatures, animation, hiérarchies, etc.). Il s'agit d'un format d'échange utilisable dans une majorité des logiciels de création 3D*, puisque la plupart disposent de fonction d'import et d'export depuis et vers ce format. Cependant, la spécification du format n'est pas disponible publiquement. Autodesk livre des exporteurs et importeurs avec chacun de ses programmes de création (Maya, 3ds, etc.) ainsi qu'une bibliothèque* propriétaire permettant de lire le format, mais pas sa spécification.

Ainsi, si un développeur souhaite implémenter un importeur FBX dans son programme, il peut soit utiliser la bibliothèque d'Autodesk, mais ce n'est pas toujours possible légalement<fnref n="6" />, soit faire de la rétro-ingénierie pour comprendre, à partir d'exemples, comment est structuré le format. C'est le cas de Blender, pour lequel les développeurs n'ont pas le droit d'utiliser la bibliothèque officielle à cause d'une incompatibilité de

<footnote n="5">5. L'article de CIANCARINI et coll. [11] mentionne un jugement rendu en 2012 par la Cour européenne du justice, qui risque de faire précédent et a déclaré légale la rétro-ingénierie à des fins d'opérabilité. Mais il estime aussi que d'autres jugements pourraient aussi bien créer une jurisprudence différente.</footnote>

<footnote n="6">6. En particulier dans le cas de logiciels open source à fort copyleft (cf. section II.1.3.1)</footnote>
licence. Ils ont donc dû décortiquer le format FBX pour créer leurs importeur et exporteur. Il en a résulté que leur version, quoique fonctionnelle, n'est pas aussi compatible que les versions Autodesk.

## Formats ouverts

Afin de pouvoir toujours transmettre ses données d'un programme à l'autre, il est donc nécessaire de disposer de formats standards et ouverts. Comme le montrent JULLIEN et ZIMMERMANN [13], les standards informatiques sont un des deux moyens de créer une interopérabilité entre logiciels, l'autre étant l'open source, avec lequel ils sont complémentaires.

Un format ouvert<fnref n="7" /> spécifie publiquement la structure des données enregistrées dans un fichier. À partir d'une spécification ouverte, les développeurs de logiciels peuvent écrire des fonctions d'import et d'export vers ces formats. Pour être viables, ces exporteurs et importeurs doivent respecter strictement la norme, c'est-à-dire qu'un fichier écrit par un programme donné puisse être ouvert par un autre programme, et que toutes les données présentes dans le fichier soient interprétées comme prévu par la spécification, qu'il n'y ait ni perte, ni corruption de données.

L'animation est un domaine dans lequel les types de données à échanger sont nombreux, lourds et complexes<fnref n="8" />. Aussi, il est indispensable de disposer de formats standards pour l'animation 3D. À cause de cette complexité et de cette variété, il est difficile de concevoir un format qui soit adapté à tous les usages courants et à venir.

Je mentionnerai ici deux formats ouverts, utilisés en 2019 sur un grand nombre de productions de films d'animation 3D, et illustrant des points importants sur l'usage des formats ouverts pour les développeurs et les utilisateurs au sein des studios.

<footnote n="7">7. Certains formats de fichier ont d'abord été créés en tant que formats propriétaires avant d'être standardisés. C'est le cas par exemple du format de document PDF, créé par Adobe en 1993 et contrôlé par la même société jusqu'à sa normalisation en 2008. Depuis, la spécification du format est maintenue par l'Organisation internationale de normalisation (ISO).</footnote>

<footnote n="8">8. Par exemple, les données de géométrie, de relations entre les objets et de rigging, de texture, de shading, d'animation ; de simulation de fluides, de particules, de poils, de volumes ; de lumières, de caméras, etc.</footnote>
OpenEXR : spécification et implémentation

OpenEXR est un format d'image bitmap développé au départ par la société de post-production états-unienne Industrial Light & Magic (ILM). Il a été conçu pour stocker des images dans un contexte de production ou d'archivage, et non pas de diffusion <fnref n="9" />.

Concrètement, comme beaucoup de formats de fichiers, OpenEXR est composé de deux éléments fondamentaux : une spécification précise et librement accessible du format [14], et une implémentation de référence sous la forme d'une bibliothèque open source [51]. De cette manière, un développeur voulant utiliser le format peut lier directement la bibliothèque dans son programme, et pourra la mettre à jour lorsque de nouvelles versions sortiront. Il peut aussi décider de créer ses propres routines de lecture et d'écriture du format, puisque celui-ci est documenté. De fait, il existe plusieurs bibliothèques compatibles capables de lire ou d'écrire le format, certaines plus limitées que d'autres, ou destinées à d'autres usages que la bibliothèque canonique <fnref n="10" />.

La licence open source de la bibliothèque lui permet d'être incorporée dans des programmes libres ou propriétaires <fnref n="11" />. Il est cependant important de noter que certaines parties de la bibliothèque ne peuvent pas être considérées comme logiciel libre, dans la mesure où elles sont protégées par des brevets dans certains pays. Ainsi, deux algorithmes propriétaires de compression avec pertes, DWAA et DWAB, créés par le studio Dreamworks Animation, sont distribués avec OpenEXR. Ils sont très performants, mais

<footnote n="9">9. Il permet de représenter les images de manière compressée ou non, avec une précision plus grande que les formats d'image grand public et génériques tels que JPEG ou PNG. En effet, les données sont représentées sous la forme de nombres à virgule flottante d'une profondeur de 16 ou 32 bits, plutôt que des entiers. Cela signifie que des grandes valeurs peuvent être représentées avec précision, y compris des valeurs supérieures à 1 ou inférieures à 0. Le format a aussi la particularité d'être prévu pour représenter les valeurs de lumière de la scène et non celles de l'affichage, et aucune transformation n'y est donc appliquée. Plutôt que de stocker une image composée de plusieurs canaux (typiquement rouge, vert, bleu et alpha) comme la plupart des formats d'image, les fichiers OpenEXR peuvent contenir un nombre arbitraire d'images, chacune pouvant avoir plusieurs canaux. Ces différentes images constituent des passes, et ce dispositif est inestimable pour transporter efficacement les nombreuses passes nécessaires à un compositing avancé.</footnote>

<footnote>Sa spécification rend le format particulièrement adapté aux applications de compositing physique-ment correct. Un espace colorimétrique est associé au fichier pour interpréter correctement les couleurs.</footnote>

<footnote n="10">10. Par exemple, la bibliothèque tinyEXR est destinée à être légère et facile à intégrer dans un programme, en sacrifiant en échange certaines fonctionnalités avancées.</footnote>

<footnote n="11">11. OpenEXR est publié sous la licence permissive BSD 3 clauses, qui est une licence permissive. Voir section II.1.3.2.</footnote>
ne peuvent légalement être utilisés que dans la bibliothèque officielle. Cela signifie qu'un
développeur souhaitant créer sa propre implémentation en est empêché par cette restric-
tion <fnref n="12" />. Il convient donc d'être vigilant lorsqu'on utilise un format ou du code présenté
comme open source, car il ne permet pas toujours toutes les utilisations.

Alembic : un pas vers l'interopérabilité 3D

Le format ouvert Alembic <fnref n="13" /> a été initialement co-développé en 2010 par Sony Pic-
tures Imageworks, Inc. et Industrial Light & Magic. Il a depuis été implémenté dans la
plupart des logiciels de création 3D* et il est maintenu par une communauté de déve-
loppeurs, dans et en dehors des studios.

Contrairement à OpenEXR, le format Alembic est défini uniquement par son implé-
mentation de référence, et non prescrite par une spécification exacte. Une documentation
existe <fnref n="14" />, mais elle ne décrit pas le format assez précisément pour pouvoir créer une autre
implémentation. Pour cela, un développeur devra nécessairement lire le code de la bi-
bliothèque officielle, qui fait référence mais peut être amenée à changer.

Comme beaucoup de nouveaux formats — dont OpenEXR — Alembic est né d'un
besoin au sein de studios. Plutôt que d'être conçu par un éditeur de logiciel, il a évolué
en réponse aux nécessités concrètes de la production. Il peut à la fois permettre des
pipelines* nouveaux à l'intérieur d'un studio, et faciliter la collaboration de plusieurs
studios sur un même projet.

Par ailleurs, s'il a rapidement été adopté par beaucoup de logiciels au cours des années
2010, le format Alembic a aussi illustré le problème exposé à la section II.1.1.3. En effet,
dans le cas de Blender, le support du format a mis longtemps a être même envisagé par
les développeurs, qui le considéraient d'abord superflu pour la cible de ses utilisateurs
(les indépendants et les petits studios), puis non prioritaire. Le développement croissant

<footnote n="12">12. Ce cas de figure s'est produit dans le programme FFmpeg, dont l'implémentation d'OpenEXR ne permet pas de lire ni d'écrire des images utilisant les compressions DWA, en raison du brevet.</footnote>

<footnote n="13">13. Alembic est un format de cache permettant de transférer des animations de maillages, NURBS, particules, cheveux et simulations physiques d'un programme à l'autre. Il évite aux utilisateurs de se soucier des détails de hiérarchie, de rig et de skinning, ni de calcul de simulation. Son utilisation elle-même sera expliquée plus en détail dans la partie III (section III.5.2).</footnote>

<footnote n="14">14. Cette documentation est dispersée sur plusieurs sites web et semble incomplète.</footnote>
des relations entre les développeurs et les studios a permis un changement de mentalité, mais celui-ci a pris un temps de plusieurs années, au cours desquelles les utilisateurs pouvant faire usage des procédures permises par Alembic ont dû se replier vers d'autres solutions moins efficaces.

### II.3.2.2 Organismes de standardisation

Pour que les programmes utilisés dans un pipeline soient interopérables, il faut donc qu'ils intègrent des capacités d'import et d'export dans des formats standards, et qu'elles les respectent scrupuleusement, sans quoi les fichiers seraient de fait incompatibles. Il en est de même des autres composants communs aux logiciels. Deux initiatives récentes se sont lancées afin que les éditeurs et les studios puissent mettre leurs ressources en commun pour améliorer et rendre compatibles les logiciels qu'ils développent et utilisent.

#### VFX Reference Platform

La première de ces initiatives est la VFX Reference Platform. Ce groupe a été mis en place en 2014 par la Visual Effects Society<fnref n="15" /> et a pour but de définir une liste des composants (bibliothèques et formats) intégrés aux logiciels, pour améliorer leur compatibilité, particulièrement sur les systèmes Linux* dont les versions des logicielles peuvent être différentes d'une distribution à l'autre.

Cette liste, mise à jour chaque année, stipule de plus les versions à adopter. Elle recommande rarement la dernière version, son but n'étant pas d'être à la pointe, mais compatible. Même si deux logiciels de création 3D* permettent de lire et d'écrire un fichier dans un format standard, encore faut-il qu'ils s'entendent sur la version à implémenter. D'un côté, ils ont intérêt à adopter des versions récentes pour bénéficier des dernières fonctionnalités et corrections de bugs ; d'un autre côté, il peut être important de garder plus longtemps une version ancienne<fnref n="16" />. Cette liste est disponible publiquement

<footnote n="15">15. Une organisation internationale de professionnels du secteur des effets spéciaux. Cette organisation n'a pas de rôle de normalisation, mais elle regroupe des acteurs influents du milieu, et son opinion est assez bien suivi par les studios.</footnote>

<footnote n="16">16. C'est le cas du langage de programmation Python, le plus utilisé pour le scripting dans les secteurs</footnote>
sur le site de l'organisation [39].

## Academy Software Foundation

L'Academy Software Foundation est un groupe établi en 2018 par l'académie états-unienne du film et par la fondation Linux. Son but est de coordonner le développement et la maintenance de bibliothèques* open source dont l'usage est crucial pour le film. Les projets logiciels qu'elle coordonne ont d'abord été conçus par des studios<fnref n="17" />. Compte tenu du fait que ces programmes sont devenus indispensables à tout l'écosystème de l'animation et des effets spéciaux, tous les acteurs s'accordent sur l'importance de leur développement. Afin d'éviter qu'ils ne soient abandonnés faute de moyens, et pour faciliter la contribution des développeurs de toute part, cette fondation prend à sa charge une partie de la complexité de gestion de projet, notamment l'infrastructure d'hébergement et le cadre juridique.

En plus de l'académie du film et de la fondation Linux, de nombreuses entreprises privées sont impliquées, en tant que sponsors financiers ou en tant que développeurs. Parmi ces groupes se trouvent des studios, des éditeurs de logiciels, et des entreprises de technologie généralistes. Les décisions budgétaires sont votées par les membres de la fondation, qui ont donc un rôle moteur dans le développement des projets qui y sont hébergés.

## II.3.3 Contributions à un projet libre

L'activité principale d'un studio d'animation n'est généralement pas de développer des logiciels, mais de fabriquer du contenu audiovisuel, éventuellement en utilisant des logiciels. Mais une des utilisations des logiciels, dans le cadre de la R&D* est précisément de développer des processus ou du code, soit pour étendre les fonctionnalités du pro-

<footnote>de l'animation et des effets spéciaux. Alors qu'une version 3 existe depuis 2008, ces secteurs utilisent en 2019 la version 2, en raison du coût global pour mettre à jour tous les scripts et programmes existants. Devant la fin du support de Python 2 annoncée par ses développeurs, la VFX Reference Platform a à son tour annoncé l'adoption de la version 3 pour 2020.</footnote>

<footnote n="17">17. Parmi lesquels, OpenColorIO, OpenVDB, OpenEXR, OpenCue et OpenTimelineIO.</footnote>
gramme, soit pour l'intégrer dans sa chaîne de fabrication. Les studios publient parfois une partie de leurs outils, et pour un studio utilisant le logiciel libre, il est logique de le faire sous licence libre également. En effet, des logiciels publiés sous licence libre peuvent être utilisés par toute la communauté, dans un esprit de contribution : rendre à la communauté une partie de ce qu'elle a donné sous la forme des logiciels. Ces contributions peuvent être très utiles à des projets de logiciel libre, car elles proviennent d'utilisateurs expérimentés au sein des studios, et constituent donc un retour d'expérience précieux.

Il existe de multiples façons de contribuer à un projet de logiciel. D'abord, en utilisant le logiciel et en le faisant connaître, d'autres utilisateurs peuvent être amenés à l'utiliser également, et éventuellement à y contribuer.

Ensuite, les utilisateurs de logiciels open source peuvent d'une certaine manière participer à l'assurance qualité du logiciel, en rapportant aux développeurs les bugs et problèmes rencontrés et en faisant des retours sur leur utilisation.

Les projets logiciels ont toujours besoin d'autres compétences pour améliorer, non seulement le programme lui-même, c'est-à-dire le produit distribué, mais aussi le projet plus vaste, comprenant la documentation, la traduction, le design, la communauté. Ces activités sont souvent pratiquées, soit par des volontaires, soit par des salariés d'entreprises ou d'associations organisées au sein d'une communauté de développement.

Enfin, la manière la plus directe de contribuer est de développer le programme lui-même, en écrivant du code ou en résolvant des bugs. Je me concentrerai dans cette section sur ce type de contribution, en exposant les contributions que j'ai faites au logiciel Blender en tant que salarié d'un studio, en particulier à travers la publication d'add-ons*.

Après avoir évoqué les différentes manières de publier un add-on, je reviendrai sur les problématiques de publications des add-ons sous licence libre, indépendamment du logiciel lui-même, mais s'insérant dans un plus vaste écosystème communautaire. J'expliquerai ensuite le processus d'intégration du système de pantins prototypé pour le film *Dilili* dans Blender, c'est-à-dire dans la version officielle du programme, téléchargeable par tous. Enfin, j'expliquerai le processus de contribution directe au code de Blender, en
tant que mainteneur d'un add-on écrit par un programmeur indépendant, et qui n'était plus supporté depuis plusieurs années.

### II.3.3.1 Des manières de publier un add-on

Les add-ons* sont des petits programmes intégrés dans une plus grande application, utilisant son API* pour y ajouter des fonctionnalités. Il existe plusieurs moyens pour publier un add-on, et ils seront évoqués dans le contexte de l'utilisation de Blender.

#### Add-ons intégrés

Certains add-ons sont développés et maintenus par les mêmes développeurs que le programme principal. Ils sont livrés avec, et lui sont donc liés. Ainsi dans Blender, les fonctions fondamentales d'import et d'export de données vers des formats non-natifs sont contenues dans des add-ons livrés avec, et l'utilisateur peut décider de les activer quand il en a besoin.

Ces add-ons intégrés suivent le même processus de développement que le reste du programme, et les développeurs décident quels nouveaux add-ons développer, ou quels anciens add-ons plus compatibles doivent être retirés. Beaucoup d'add-ons intégrés au programme ont d'abord été développés indépendamment, par des individus ou des sociétés ayant besoin de fonctions non-prévues, et proposé ce code à l'inclusion dans le programme principal.

#### Magasins d'add-ons

Beaucoup de programmeurs créent aussi leurs propres fonctions sous la forme d'add-ons, et les publient sur des forums, des magasins en ligne moyennant paiement, ou sur leurs sites web, sans volonté que ces add-ons soient intégrés au programme principal. C'est le choix qu'a fait initialement la société en développant ses outils pour ses productions. En effet, la publication d'outils peut demander plus ou moins d'engagement de la part du développeur. Blender est utilisé par assez d'utilisateurs pour qu'il puisse exister un marché pour ces add-ons indépendants, et donc des magasins en ligne tels que
Blender Market et Gumroad. Bien que les add-ons pour Blender soient obligatoirement sous licence libre du fait de la licence copyleft GPL (cf. section II.1.3.3), un développeur peut décider de vendre son add-on, et de fait, quelques-uns d'entre eux parviennent à en tirer un profit non-négligeable. Mais dans ce cas, le fait de vendre un produit demande une maintenance et un développement réguliers, et un support aux utilisateurs devenus clients. De plus, la vente de programmes est une activité commerciale supplémentaire, qui n'est pas facile à intégrer avec la stratégie commerciale d'un studio d'animation, puisqu'elle demande des ressources substantielles, en développement et support donc, mais aussi en marketing et administration.

## Publication indépendante

Le choix restant, qui est aussi le plus courant, est de publier ses add-ons gratuitement, sur une plate-forme indépendante du site du logiciel, et selon l'habitude des programmes sous licence libre, « tels quels », c'est-à-dire sans garantie de fonctionnement ni de support.

C'est la façon la plus simple de publier du code, puisqu'il suffit de le poster sur un site, blog, forum, ou, de préférence, forge de développement afin de faciliter le développement collaboratif.

## II.3.3.2 Publication indépendante d'add-ons

### Contraintes de la publication

Un programmeur écrivant un outil pour une production précise ne travaille pas de la même manière que s'il doit publier l'outil pour un usage plus général : il doit répondre d'abord à des problématiques de production précises, dans des contraintes de temps souvent difficiles, et le résultat est donc rarement un beau script* bien documenté et dénué de bugs, mais une solution ad-hoc prévue pour le pipeline* et les problématiques du studio.

La publication de ce code demande donc un travail de nettoyage, de documentation,
de test, et il faut bien évaluer avant de le faire le gain possible, pour les utilisateurs, et pour la société. Si l'outil est trop attaché à la société, soit parce qu'il s'agit d'un processus de niche, soit parce qu'il est indissociable du pipeline, il est probable que l'outil ne soit pas utile à grand-monde.

De plus, une fois le code publié, certaines étapes sont nécessaires pour que le code soit vraiment utilisable. Il faut en écrire la documentation, afin que les fonctionnalités du programme soient correctement décrites, ou du moins, que l'utilisateur ait une idée de son intérêt. Il faut ensuite faire un minimum de maintenance pour corriger les bugs trouvés par les utilisateurs, et intégrer le code éventuellement proposé par eux.

## Construire avec la communauté

Alors, de la même manière qu'une communauté peut s'assembler autour d'un logiciel de création, un studio peut avec assez d'efforts, parvenir à fédérer autour d'un add-on* une communauté d'utilisateurs et de développeurs, qui peuvent à leur tour y contribuer.

Ils peuvent ainsi aider le studio dans le développement de ses propres outils, en l'utilisant, en rapportant des bugs ou en suggérant des fonctionnalités, voire en développant eux-mêmes des nouvelles fonctionnalités qui pourront y être intégrées directement. C'est l'argument évoqué par le développeur de jeu vidéo Jon Manning, du studio australien Secret Lab, dans une conférence à la Game Developers Conference [21]. Il explique avoir développé le système de dialogues Yarn Spinner [47] pour le jeu vidéo Night in the Woods, et avoir décidé de le rendre open source en cours de production. Les problématiques qu'il observe sont multiples. Il explique que l'intérêt pour un studio de faire cette démarche est d'avoir des utilisateurs qui peuvent utiliser, tester et rapporter des problèmes sur le programme, mais également développer directement, en proposant leurs améliorations, comme dans tout projet open source. Mais il souligne aussi l'importance de créer une communauté autour du projet, en communiquant avec les contributeurs potentiels, en les accueillant, en acceptant leurs propositions, même les plus imparfaites, et en engagant une dynamique de développement collaboratif. Il explique que la gestion d'une communauté est une activité radicalement différente du développement informatique,
mais qu'en cas de succès les bénéfices pour un projet ou une société sont plus grands que l'investissement en temps que cette gestion représente.

Je partage l'analyse de Manning, et je mettrai l'accent sur la condition de succès d'un tel projet open source, qui n'est pas seulement l'investissement des développeurs dans la communauté et de la publicité qui en est faite, mais également le potentiel du projet d'attirer les contributeurs, selon son utilité pour tous. Les sociétés doivent donc estimer l'intérêt de structurer une communauté de développement avant de se lancer dans une telle entreprise.

### II.3.3.3 Maintenance officielle d'add-ons

Une des caractéristiques des projets open source est qu'ils accueillent les contributions externes. Ce principe est plus ou moins appliqué selon les projets, en fonction du modèle de gouvernance, de l'exigence technique et des ressources du projet. Quoi qu'il en soit, les utilisateurs sont généralement encouragés à contribuer ponctuellement, puis éventuellement à se voir confier des responsabilités au sein du projet, telles que la maintenance d'une partie du code, la communication avec la communauté, etc. Cet encouragement à la contribution peut s'étendre à des développeurs dans les studios.

Ainsi, j'ai été amené à corriger des bugs sur des add-ons officiels et à ajouter des fonctionnalités<fnref n="18" /> dans le cadre de mon travail en entreprise. Ces changements n'ont d'abord pas été proposés à Blender, mais gardés au sein du studio, faute de temps pour créer un patch* nettoyé et facile à intégrer. Entre deux productions, j'ai pris le temps de proposer les patchs aux développeurs, tout en corrigeant les incompatibilités. Ils ont été acceptés et donc intégrés à Blender. Ce qui partait d'un développement à l'usage exclusif du studio a donc été logiquement reversé dans le commun.

La proposition de correctifs se fait via une forge, une interface dédiée au développement, sur le site web de Blender. Cette interface permet des discussions sur le design et

<footnote n="18">18. Par exemple, j'ai contribué à l'add-on AnimAll de Daniel Salazar, qui permet dans Blender d'animer des éléments normalement inaccessibles tels que les positions des sommets des maillages. À l'origine, pour chaque image de l'animation, l'add-on créait une clef d'animation pour tous les points en même temps, et j'ai ajouté la possibilité de ne créer la clef que pour les points sélectionnés, ce qui rend la gestion des clefs d'animation beaucoup plus claire.</footnote>
l'implémentation du code, et à l'occasion d'un patch assez conséquent sur l'add-on Ani-
mAll, le coordinateur du développement d'add-ons m'a proposé de faire officiellement la
maintenance de l'add-on concerné. J'ai accepté, sachant que l'add-on était assez mature
pour ne pas me demander un investissement de temps colossal.

Le responsable a donc engagé une procédure pour me faire devenir mainteneur. Cette
procédure consiste à faire une demande officielle sur la liste de diffusion des développeurs,
et à répondre aux questions d'un des chefs développeurs de Blender concernant ma mo-
tivation et mon expérience. La responsabilité de maintenance implique d'avoir accès au
code source*, et le développeur m'a expliqué avec bienveillance que cette responsabi-
lité était rarement confiée à des débutants n'ayant proposé que quelques contributions,
puisque des mauvaises contributions pouvaient nuire à la qualité du code. J'ai pu lui
expliquer que mon activité professionnelle m'avait conduit à développer et publier plu-
sieurs add-ons indépendants, et à implémenter la modularisation de Rigify décrite plus
bas. Il m'a confié l'accès au dépôt de code afin que je puisse y verser directement mes
contributions, sans avoir besoin à l'avenir de créer une demande sur le site web. J'ai par
la suite mis à jour, restructuré et corrigé des bugs dans plusieurs add-ons.

La responsabilisation des utilisateurs dans le développement d'un programme open
source permet dans une certaine mesure de répartir les coûts de développement, qui ne
sont alors pas assurés intégralement par un éditeur, mais engagés par des bénévoles de
la communauté, ou par des développeurs au sein de studios ou d'autres entreprises. Ces
développeurs utilisent une partie de leur temps pour contribuer au logiciel open source
qu'ils utilisent eux-mêmes. En étant responsabilisés, les utilisateurs peuvent s'impliquer
directement dans le développement, et apprendre par la même occasion les pratiques
du développement collaboratif. Une telle démarche demande des ressources de la part
de l'équipe centrale de développeurs, car l'accueil et le support des nouveaux venus, la
critique de leur code et même la modération des discussions prennent du temps. Il y a
nécessairement des problèmes relationnels à régler dans une telle collaboration, mais la
confiance accordée aux développeurs peut créer une motivation à contribuer au projet,
et à faire profiter de ses améliorations à la communauté.
### II.3.3.4 Harmonisation du code entre contributeurs

Un problème particulier peut survenir lors de la contribution décentralisée de plusieurs acteurs à un même code. En effet, dès que deux développeurs modifient en parallèle un programme, des conflits peuvent apparaître entre leurs versions, et ils devront les harmoniser s'ils veulent les intégrer dans la version principale. C'est un problème classique de développement informatique qui apparaît dans toute équipe de plus d'une personne, et des méthodologies existent pour le pallier. Mais le problème est exacerbé quand les développeurs travaillent en complète indépendance sur des branches distinctes, que l'on appelle forks*. Les studios peuvent être confrontés à ce problème quand ils forkent un programme pour répondre rapidement à des problèmes rencontrés en production, et souhaitent ensuite proposer leurs changements à la communauté, en passant par les développeurs du logiciel.

Concrètement, le problème d'un fork est qu'il est difficile à maintenir. En effet, si la version officielle est modifiée, la version dérivée devra également appliquer ces modifications pour rester compatible. Si un studio veut proposer sa version dérivée, les utilisateurs voulant l'utiliser devront la substituer à la version officielle, et ne pourront donc pas utiliser les deux versions en même temps. Pire, si plusieurs développeurs créent des forks incompatibles entre eux, l'utilisateur devra réinstaller l'add-on* à chaque fois qu'il voudra utiliser des fonctions de l'une ou l'autre version, ce qui le conduira à terme à rencontrer des problèmes d'incompatibilité insolubles.

#### Intégration des pantins dans Blender

Pour illustrer la manière dont ce problème peut se poser, et une solution adoptée pour le résoudre, j'aborderai l'exemple d'un outil de rigging développé au cours de plusieurs projets dans l'entreprise Les Fées spéciales.

Cet outil est fondé sur un add-on* existant et livré avec Blender, Rigify (cf. section III.3.1). Il a été largement modifié pour inclure les fonctionnalités nécessaires aux productions de la société. Ce faisant, l'add-on est devenu incompatible avec la version d'origine. Ce code incompatible a néanmoins été publié en cours de production, après
quelques mois de développement.

Tout comme j'ai décrit la façon dont je m'occupais de la maintenance de plusieurs
add-ons livrés avec Blender en tant que membre de la communauté, Rigify était à
l'époque maintenu par le studio italien MAD Entertainment. Cette maintenance était
relativement indépendante de la Blender Foundation, l'organisme qui coordonne le dé-
veloppement de Blender.

J'ai rencontré les mainteneurs lors de la Blender Conference en 2017, à l'occasion
d'une présentation de leurs développements sur Rigify, et d'une présentation que j'ai
donnée de la production du film *Dilili à Paris* et des outils de pantins. La discussion
qui s'est engagée lors de cette rencontre a porté sur la possibilité d'harmonisation entre
les forks existants et futurs de Rigify. Puisque les studios sont toujours amenés à créer
des fonctionnalités très différentes, il était nécessaire qu'ils puissent le faire sans créer
d'incompatibilités. Une solution pour cela était de restructurer Rigify, pour lui donner
une architecture modulaire et extensible.

Cela implique que l'utilisateur de l'add-on puisse facilement créer, distribuer et instal-
ler des modules de fonctionnalités supplémentaires, équivalents à des add-ons de l'add-on.
Par exemple, le système de création de pantins peut être réécrit pour être un module
pour Rigify plutôt qu'une modification incompatible. Ainsi, l'utilisateur peut installer
plusieurs modules, et les mélanger au sein d'un même personnage.

Difficulté du développement collaboratif

Ce travail de modularisation a demandé un temps de développement de plus d'un
an, et a été réalisé conjointement par les mainteneurs et moi, en se fondant sur des allers
et retours du code et des discussions en ligne. Si la décentralisation du développement
a des avantages sur une gouvernance centrale, elle a cependant des conséquences sur la
bonne marche du projet.

En effet, les développeurs au sein des studios travaillent en priorité sur le pipeline*
interne, et ne sont donc pas forcément disponibles pour la collaboration avec une com-
munauté open source. Cette indisponibilité a créé des tensions lors du développement,
quand les mainteneurs, prudents, ont laissé passer des mois avant de me donner les re-
tours sur mon code nécessaires à une intégration dans Blender. Ils l'ont finalement fait
après qu'un nouveau développeur les a pressés d'intégrer mes modifications, car ce retard
l'empêchait de travailler sur une autre partie du code.

Finalement, le code de modularisation a été intégré avec la version 2.80 de Blender,
et j'ai alors pu modifier le système de pantins pour qu'il soit distribué sous forme de
module. Il n'est donc pas directement intégré dans Blender, et il est toujours développé
indépendamment au sein du studio, mais il est maintenant compatible puisqu'il ne crée
pas de fork. De plus, cette modularisation donne la possibilité aux riggers-scripteurs de
tous les studios de travailler plus proprement, et de publier leurs rigs.

Conclusion

Tout comme pour ses particularités juridiques et économiques, le logiciel libre et
open source peut offrir des avantages techniques aux studios : logiciels performants,
fonctionnalités novatrices, développement rapide, support technique efficace, interopé-
rabilité et pérennité. Mais il peut aussi être source de frustrations lorsque les logiciels
sont non-conventionnels, mal supportés, mal conçus ou simplement abandonnés.

La possibilité de chacun de développer le programme en collaboration avec la com-
munauté, si elle permet des utilisations nouvelles des programmes, demande de revoir
la façon dont on considère l'outil de production, en le voyant moins comme un produit
que comme un bien commun en perpétuelle évolution. Cette évolution peut demander
une implication inhabituelle des utilisateurs, parmi lesquels les studio.
Conclusion de la deuxième partie

Cette partie a abordé concrètement la rencontre entre les logiciels libres et les studios d'animation.

Le chapitre II.1 a montré le rôle juridique du logiciel libre, fondé sur les quatre énoncés qui font partie de sa définition : utiliser, étudier, modifier et distribuer le programme sous sa forme de code source. Cette analyse a permis d'aborder les points suivants :

— l'importance pour les studios, comme pour n'importe quelle société faisant usage de logiciels, d'avoir accès au code pour se garantir la pérennité et la maîtrise de ses propres données et processus;

— les différents types de licences libres existantes, et la difficulté que représente le choix des licences logicielles pour les studios ;

— le rapport qui existe entre le mouvement du logiciel libre et celui des communs, autour des licences de libre diffusion telles que les licences Creative Commons, et en quoi le choix de ces dernières est délicat pour les studios à l'heure actuelle.

Dans le chapitre II.2 nous avons vu quelles conséquences économiques l'usage des logiciels libres pouvait avoir dans les studios :

— les modalités d'accès aux logiciels, et comment le logiciel libre n'est pas qu'une alternative gratuite aux logiciels propriétaires ;

— les raisons qui peuvent pousser les studios à écrire leurs propres programmes, et le rôle du logiciel libre dans l'accès à cette pratique ;

— les modes de financement possible du logiciel libre, autant au sein du studio qu'en-visagé dans un réseau plus large de développeurs.

Enfin, le chapitre II.3 a abordé trois facettes concrètes de l'usage des logiciels
libres :

— le rôle de l’innovation technique des logiciels libres de création, et leur place parmi les éditeurs;

— la fonction déterminante de la standardisation des programmes et formats pour les studios, et de quelle manière elle repose sur le logiciel open source;

— et enfin la manière pour les studios de contribuer eux-mêmes au développement des logiciels qu’ils utilisent, au sein des départements R&D* ou TD*, et les bénéfices que peut en tirer la communauté mondiale des utilisateurs de logiciels libres pour l’animation.
Troisième partie

Vers un pipeline libre
Introduction

L'utilisation des logiciels libres dans le secteur du cinéma d'animation est relative-
ment récente et minoritaire, mais comme dans d'autres secteurs, leur adoption tend à
s'accélérer, et de nombreux studios commencent à les considérer comme des solutions
viables.

Cette partie s'attachera à décrire l'utilisation des logiciels libres que j'ai pu observer
et développer au sein du studio Les Fées spéciales pendant ma convention Cifre, en grou-
pant ces usages par département. Selon les cas, deux approches complémentaires seront
adoptées : une description des logiciels utilisés pour résoudre un problème spécifique, et
une analyse des outils et processus développés pour les projets, et publiés sous licence
libre. Cette double approche permet d'étudier, d'une part, les qualités propres de cer-
tains programmes libres de création, et d'autre part le besoin constant de développement
au sein des studios, et les bénéfices qu'ils peuvent tirer de la mutualisation propre au
logiciel libre.
# Chapitre III.1

## Projets pour l'émergence d'un
pipeline libre

### Introduction

Cette thèse s'est déroulée en entreprise, dans le cadre d'un contrat Cifre (cf. section I.1.1). C'est principalement en travaillant en production sur les projets que j'ai pu observer les implications de l'utilisation du logiciel libre pour les studios, mais également dans une moindre mesure, pour un artiste développeur indépendant. Avant de développer les utilisations concrètes du logiciel libre en production, il faut avoir une idée des problématiques de production liées aux projets. J'exposerai donc dans ce chapitre quatre des projets sur lesquels j'ai travaillé : un long-métrage d'animation, *Dilili à Paris* (section III.1.1), une exposition et deux documentaires formant le projet *Antarctica* (section III.1.2) et une exposition permanente du musée de Lodève (section III.1.3).

### III.1.1 *Dilili à Paris*

*Dilili à Paris* est un film d'animation du réalisateur Michel Ocelot, auteur notamment de *Kirikou et la Sorcière* et d*'Azur et Asmar*. Sorti fin 2018, il raconte l'histoire de l'héroïne éponyme, petite fille kanak venue à Paris pour une exposition de zoo hu-
main, à la Belle Époque. Tout en visitant de nombreux lieux célèbres de la ville, et des
personnalités de l’époque — artistes, scientifiques, politiques — elle devra élucider de
mystérieux enlèvements de fillettes qui terrorisent la population.

Ce film a été en préparation longtemps avant sa mise en fabrication. En effet, outre l'écriture du scénario qui demande un temps long, le film a dû passer par des étapes de recherche de financement, de storyboard et d'anima-tique. Ces étapes avaient donc commencé depuis plusieurs années lorsque les Fées spéciales ont commencé leur par-ticipation, début 2016.

L'organisation de ce projet était complexe, parce qu'elle impliquait quatre équipes différentes : deux à Paris, travaillant dans les mêmes locaux, un troisième à Montpellier, plus une équipe du premier studio, à Bruxelles. Le studio parisien, Mac Guff, et son antenne belge étaient chargés de la modélisation et de l'anima-

tion des personnages principaux, du rendu et des effets spéciaux, et du compositing. Les décors ont été réalisés par une équipe engagée pour l'occasion par la société de production Nord-Ouest. Les décorateurs devaient tenir compte de la volonté de Michel Ocelot d'utiliser des photos de la ville, prises par l'auteur lui-même dans le Paris d'aujourd'hui. La majorité des décors du film a donc été retouchée pour enlever les éléments anachroniques, et retrouver une esthétique et une impression 1900. D'autres décors, comme la tour Eiffel, ont été imaginés et entièrement créés en 3D, ou dans certains cas peints sans base photographique. Les Fées spéciales, à Montpellier, ont pour leur part créé le layout et les nombreux figurants.

*Dilili à Paris* est le premier projet sur lequel ont travaillé les Fées spéciales. C'est donc pour ce film qu'a été conçu la première version du pipeline* de fabrication du studio. Dans ce contexte, j'ai travaillé sur un système d'animation 3D de personnages en papier découpé, qui sera détaillé dans la section III.3.1.

<figure><img src="image_5.png" /><figcaption>FIGURE III.1.1 – Affiche du film *Dilili à Paris*.</figcaption></figure>
Le pipeline du film a été spécialement conçu pour accommoder les échanges entre les différents sites. En particulier, le layout et l'animation des foules réalisées par les Fées devaient être utilisées par Mac Guff, et se retrouver telles quelles dans leur propre pipeline.

Des outils spécifiques ont dû être écrits, et ils seront détaillés dans le section III.5.2.

### III.1.2 Antarctica

Les Fées spéciales ont travaillé sur deux projets fondés sur une même expédition en Antarctique, organisée en 2015-2016 par le documentariste de cinéma Luc Jacquet (La Marche de l'empereur, Il était une forêt), accompagné par le photographe et plongeur Laurent Ballesta. L'expédition avait pour but d'étudier la vie présente sur le continent Antarctique, par des plongées sous-marines dans des conditions extrêmes, ainsi que des phénomènes naturels ayant lieu sur et autour du continent. De nombreuses images en ont été rapportées, et plusieurs livres et films ont été édités, ainsi qu'une exposition au musée des Confluences à Lyon en 2016.

Cette exposition est le premier projet muséographique sur lequel ait travaillé le studio Les Fées spéciales. À cette occasion, nous avons créé des films animés illustrant des phénomènes comme les courants marins et les particularités de la plongée des phoques de Weddell.

Le deuxième projet est un ensemble de deux films documentaires diffusés sur Arte début 2017. Ces films montrent des images prises lors de l'expédition, et des plans* animés les accompagnent pour contextualiser ou illustrer le propos des auteurs.

#### III.1.2.1 Exposition au musée des Confluences

Cette exposition illustre la vie sur le continent Antarctique. Surtout constituée de vidéos prises lors de l'expédition, les Fées spéciales y ont contribué en créant quatre animations diffusées sur des écrans disséminés au sein de l'exposition.

Les images prises sur place mettent en scène les animaux sous l'eau et au-dessus. Des plongeurs de l'équipe de Laurent Ballesta ont rapporté des images nouvelles d'espèces
autochtones et inconnues jusque-là : algues, étoiles de mer, poissons, crustacés, espèces non identifiées et incroyables. Deux espèces sont particulièrement traitées : le manchot empereur et le phoque de Weddell.

Le temps de production de ce projet a été court, mais la diversité des programmes l'a rendue très dense. La production muséographique, si elle utilise les mêmes techniques que celles du cinéma, s'attache moins au volume, et les éléments produits sont donc beaucoup plus différents les uns des autres. Au total, nous n'avons fabriqué que quatre plans, mais chacun était si unique qu'aucune réutilisation n'était possible.

Chacun de ces quatre plans se fonde sur une charte graphique établie par la designer graphique Marie Saby et par le directeur artistique de la société, Eric Serre. La charte se fonde sur les informations et dessins fournis par l'équipe scientifique du musée ou de l'exposition, une

bible scientifique. Bien souvent, ces informations ne sont pas suffisantes pour créer de toute pièce un plan, et il faut alors demander des données complémentaires, ou trouver une autre source.

Ces plans sont diffusés sur des écrans dans l'exposition, illustrant des phénomènes observés sur le continent, en regard avec le reste de la muséographie. Par exemple, une des premières salles de l'exposition reconstitue une pièce de la base scientifique, avec les équipements de plongée, des instruments de mesure, etc. Dans cette salle, nous avons conçu un programme montrant le trajet en avion effectué par l'équipe pour rejoindre la base.

Chaque programme devait boucler sur lui-même afin de recommencer directement après avoir terminé. Mes recherches de master sur la boucle d'animation m'ont été bien utiles pour trouver des solutions créatives à ce problème.

<figure><img src="image_6.png" /><figcaption>FIGURE III.1.2 – Affiche de l'exposition *Antarctica*.</figcaption></figure>
### III.1.2.2 Films documentaires télévisés

*Antarctica, sur les traces de l'Empereur et Les secrets des animaux des glaces* sont deux films documentaires diffusés sur Arte en 2017. Très liés à l'exposition du musée des Confluences, leurs images sont issues de la même expédition en Antarctique, et montrent la diversité biologique du continent, tout en illustrant des phénomènes climatiques mondiaux, et propres à ce continent. La majorité des films est en prise de vue réelle, y compris des séquences de plongée sous-marine le long des côtes du continent, un exploit inouï et inédit. Quelques séquences animées sont dispersées dans les films, illustrant divers phénomènes. Ce sont sur ces séquences que nous avons travaillé.

La production a été beaucoup plus longue, et plutôt plus laborieuse que pour l'exposition, en raison de la différence de contexte et d'interlocuteurs. En effet, si la personne en contact sur l'exposition était le réalisateur Luc Jacquet, chargé du commissariat d'exposition, deux personnes différentes étaient à la réalisation des films : Marianne Cramer et Jérôme Bouvier. Les deux films avaient des durées différentes (52 et 90 minutes), et racontaient des histoires différentes. Certains plans que nous avons fabriqués devaient être utilisés dans les deux films, mais les réalisateurs n'avaient pas systématiquement les mêmes visions. Le fait d'avoir deux interlocuteurs et deux validations à obtenir pour les mêmes images complique singulièrement le travail de la production.

De plus, une contrainte inédite pour nous, et qui peut sembler anecdotique mais a entraîné de lourdes conséquences, est celle du format, en 4K (Ultra HD). Bien sûr, les difficultés techniques liées aux nouveaux formats plus lourds sont loin d'être nouvelles, au point de devenir un poncif avec l'apparition régulière de nouveaux standards (numérique, HD, stéréoscopie, 4K, HDR, etc.), mais c'est la première fois que nous en étions frappés directement, ce qui nous a demandé des ressources et des compromis non anticipés.

Beaucoup de plans fabriqués pour ces deux projets, l'exposition et les films, n'ont pas présenté de particularités par rapport au sujet d'étude, mais certains, par leur caractère de visualisation scientifique, ont permis d'explorer des problématiques originales concernant l'utilisation de données scientifiques ouvertes. Je parlerai de ces problématiques dans le chapitre III.6.
III.1.3 Exposition pour le musée de Lodève

Entre août 2017 et juillet 2018, la majeure partie du temps de production de l'en-
treprise a été consacrée à son deuxième projet de grande envergure : la réalisation de
programmes audiovisuels et la conception d'objets pour le musée de Lodève, spécialisé
dans l'archéologie, la géologie, et l'œuvre du sculpteur Paul Dardé. Lodève est une pe-
tite commune d'environ 7500 habitants située dans le département de l'Hérault, à une
cinquantaine de kilomètres de Montpellier. Malgré sa petite taille, la commune possède
un musée de rayonnement national du fait de ses expositions temporaires. Fortement
ancré dans le territoire, il montre les nombreuses richesses du Lodévois environnant. Les
pièces de ses collections sont d'époques diverses : les plus anciennes, des restes fossiles
de plantes et d'animaux, ont des centaines de millions d'années, tandis qu'un vaste pan
de la collection a été fabriqué par des humains ayant vécu dans la région il y a plusieurs
millénaires, pendant la préhistoire.

Cette grande variété est propice, non seulement à l'étude, qui est le travail quotidien des scientifiques du musée, mais également à l'exposition pour le grand public. À l'occasion d'ambitieux travaux de rénovation ayant duré quatre ans, le musée a fait un appel d'offre pour concevoir une nouvelle exposition. Cela signifie non seulement restaurer le bâtiment, concevoir une nouvelle identité visuelle, de nouveaux lieux d'exposition et une nouvelle muséographie, mais également, et c'est là que nous sommes concernés, des programmes animés permettant d'illustrer, d'expliquer, de vulgariser des connaissances scientifiques au travers des pièces du musée. Les Fées spéciales ont répondu à l'appel d'offre pour la dernière période de la rénovation, alors que le gros œuvre se terminait et que les ouvriers s'activaient aux installations électriques et mobilières.

L'appel d'offre portait sur les trois domaines d'étude du musée : l'archéologie, la géologie et les beaux-arts. Ces trois domaines sont organisés dans le musée selon trois parcours, chacun dans une aile du bâtiment. Nous avons donc travaillé avec les responsables de ces départements pour concevoir les programmes. Ceux-ci sont d'une grande variété, allant de courts-métrages animés montrant la vie des habitants de la région à la préhistoire, à des pièces volumiques fabriquées selon des dessins 3D, en passant par
des schémas explicatifs sur les phénomènes géologiques, projetés sur des cartes en relief installées sur des tables dans l'exposition. La multiplicité des supports a demandé un pipeline* souple, voire laxiste, pour travailler en parallèle.

Les vidéos réalisées pour le parcours de beaux-arts n'ont pas demandé de 3D, mais seulement du montage et du motion design, aussi je n'en parlerai pas plus avant, pour me concentrer sur l'archéologie et la géologie. Je présenterai maintenant les différents programmes pertinents pour cette thèse, et exposerai dans la partie III les problématiques de ce projet et les développements nécessaires dans le pipeline pour le mener à bien.

### III.1.3.1 Archéologie : films animés

Le parcours d'archéologie de l'exposition permanente du musée, *Empreintes de l'Homme*, expose l'environnement et la vie d'hommes préhistoriques dans la région au néolithique. Chaque salle explique une technique ou une pratique particulière de ces peuples, en présentant des artefacts des collections ainsi que des courts films animés mettant en scène des personnages de l'époque.

Pour ce programme, nous avons fait neuf films animés, durant chacun entre une et quatre minutes, et utilisant la technique des pantins, déjà éprouvée sur *Dilili à Paris*. Les films sont constitués de saynètes muettes, mettant en scène des personnages du néolithique dans leurs villages, ou en dehors, dans la région. On les voit accomplir leurs activités quotidiennes (chasse, pêche, fabrication d'outils, puisage d'eau, inhumation des morts, fabrication d'un dolmen, etc.).

### III.1.3.2 Modélisation et création d'objets physiques

En plus des animations du parcours archéologique, les Fées spéciales se sont occupées de la conception numérique de pièces volumiques pour une fabrication 3D. D'autres pièces ont été conçues pour le parcours géologique, intitulé *Traces du vivant*. Une autre
entreprise, Sequoia MD<fnref n="1" />, s'est occupée de la fabrication. En effet, nous ne disposions ni des compétences, ni de l'outillage nécessaires. Nous avons cependant collaboré avec la société afin d'être certains à chaque étape que les fichiers que nous leur envoyions étaient conformes à leurs demandes, et réalisables avec leur matériel, dans les délais imposés. Nous avons donc pu étudier les contraintes de fabrication. Plusieurs pièces différentes ont ainsi fait l'objet d'une conception numérique.

Pour toutes ces pièces, nous avons utilisé Blender pour ses capacités de modélisation 3D, mais d'autres programmes ont aussi fait partie du processus de fabrication, selon les besoins. Je parlerai dans le chapitre III.7 des pièces sur lesquelles j'ai personnellement travaillé.

## Conclusion

Les projets exposés dans ce chapitre ont eu lieu sur une période de presque trois ans. C'est au cours de ces projets que j'ai exploré les possibilités et les pratiques du logiciel libre dans le pipeline de fabrication d'un studio d'animation, qui seront l'objet des chapitres suivants.

Durant cette période, j'ai également élaboré un projet personnel, qui n'est pas strictement en lien avec les studios d'animation puisqu'il avait pour objet la création d'une application interactive pour le web. Il est néanmoins éclairant pour comprendre la méthode que peuvent adopter les TDs* lors de la phase de veille pour développer des scripts* au sein des studios. Ce projet sera présenté en annexe B.

<footnote n="1">1. Cette entreprise basée dans les Yvelines est spécialisée dans l'agencement et la création numérique pour des expositions, des collectivités, et des clients privés.</footnote>
# Chapitre III.2

## Préproduction

### Introduction

Après cette présentation des projets ayant alimenté mon étude du logiciel libre en production, j'aborderai maintenant chaque département pour lequel le logiciel libre a été utilisé, ou du moins fait l'objet d'une étude. Je commencerai logiquement par les premières étapes de la chaîne, que constitue la préproduction.

La préproduction <fnref n="1" /> est une phase précédant la fabrication. Il s'agit pour partie d'un travail de production <fnref n="2" />, et pour partie d'un travail de conception artistique et de recherche technique. J'aborderai dans ce chapitre les problématiques propres à l'élaboration du storyboard, de l'animatique et du layout (cf. section I.1.2), indispensables à la bonne marche d'un projet d'animation.

### III.2.1 Storyboard et animatique

J'ai décrit ces différentes étapes dans la première partie (cf. section I.1.2.1). Parmi ces étapes préparatoires de conception et de mise en scène, la première est le storyboard. Elle

<footnote n="1">1. Il convient de lever l'ambiguïté entre les deux sens du mot « production » : les métiers de production (producteur, assistant de production, etc.) et la phase pendant laquelle le film est fabriqué. Je parlerai plutôt de fabrication dans ce dernier sens.</footnote>

<footnote n="2">2. Financement, co-production, etc.</footnote>
n'est pas aussi technique que les étapes ultérieures de fabrication, mais gagne néanmoins
à être considérée dans le cadre du pipeline* dans la mesure où ce document sera réutilisé
et transmis aux autres départements.

Pour les petits films d'animation, l'équipe réalisant le storyboard est réduite, entre
un et quelques graphistes, et la mise en scène ne demande pas de nombreuses itérations
ni une gestion rigoureuse des versions. Ces projets ne nécessitent donc généralement pas
de pipeline complexe. Les graphistes s'organisent comme ils le souhaitent, et le choix des
logiciels au regard du pipeline est moins important que sur une grosse production.

Qu'il s'agisse d'une petite ou d'une grosse production, le storyboard peut bénéficier
d'outils numériques adaptés pour faciliter sa conception et son intégration dans la chaîne
de fabrication.

### III.2.1.1 Fonctionnalités essentielles des logiciels de storyboard

L'observation de la pratique des storyboarders permet de dégager les fonctionnalités
essentielles à intégrer dans les logiciels de conception.

#### Du storyboard à la nomenclature de projet

Le storyboard est traditionnellement un document papier qui expose les indications
de mise en scène et d'autres données qui représentent l'organisation structurelle de
l'œuvre et de sa fabrication : séquences, plans*, images, raccords, etc. (cf. section I.1.2.1).
Dans l'équivalent numérique, ces indications peuvent être extraites pour former la base
de l'ensemble du pipeline.

En effet, la nomenclature de montage est un ensemble de métadonnées qui se re-
flète directement dans l'organisation informatique à la base du pipeline. L'ajout d'un
plan au storyboard influence la structure du film et donc l'organisation informatique
(arborescence de fichiers, suivi numérique de la fabrication, etc.).

De plus, les vignettes qui constituent le storyboard peuvent en être extraites et
intégrées à l'animatique. Dans ce cas, le storyboard n'est plus un document isolé, mais
bien le point de départ de la chaîne de fabrication.
Double niveau de lecture

Le storyboard permet de visualiser deux informations simultanément : la composition de l'image dans le plan et l'enchaînement des plans dans la continuité de la séquence. Dans un storyboard traditionnel, on dessine sur une bande les vignettes l'une après l'autre, et on les voit dans leur continuité, chacune entourée des plans précédent et suivant. Il s'opère donc un aller-retour entre le plan représenté par une vignette, et la séquence composée de plusieurs plans.

Le numérique permet d'afficher un dessin en plein écran pour plus de précision, mais il est important de retrouver cette possibilité de changer d'échelle de lecture, en affichant également le strip. Ce changement doit pouvoir s'opérer de manière interactive et instantanée, et le graphiste doit pouvoir passer facilement d'une vue à l'autre.

Storyboard et animatique : deux vues des mêmes informations

Puisque le storyboarder crée la mise en scène du film, il gagne à déterminer une durée approximative pour les plans avant l'étape du montage. En effet, le film se perçoit dans la durée, et le rythme est une composante essentielle de son expression. Un minutage précis participe donc à la narration.

Or, contrairement à la conception traditionnelle du storyboard, proche de la bande dessinée, les logiciels de storyboard permettent de mettre en place la durée des plans en même temps que la composition de l'image. Les storyboarders peuvent donc avec l'aide du programme concevoir l'animatique en même temps que le storyboard.

De fait, dans un programme permettant de paramétrer les durées des plans que les vignettes sont dessinées, il est facile de générer l'animatique ou le storyboard plusieurs fois en cours de production. Les deux documents n'ont pas les mêmes finalités, mais représentent tous les deux le film, l'un sous la forme de planches, l'autre sous la forme de vidéo qui constitue un montage provisionnel.
### III.2.1.2 Solutions existantes

Les logiciels de storyboard commerciaux les plus utilisés en animation en 2019, Toon-Boom Storyboard Pro et TVPaint permettent tous deux les fonctionnalités décrites précédemment.

ToonBoom Storyboard Pro n'est conçu que pour le storyboard. TVPaint est un logiciel d'animation 2D, mais intègre un module dédié au storyboard. La manière de créer un storyboard dans ces logiciels est proche de celle employée pour animer des plans, mais plus grossière puisque le minutage n'est pas à l'échelle du plan mais de la séquence, ou du film.

Pour cela, ces logiciels disposent d'une forme de timeline*, sur laquelle on organise les vignettes des plans. L'utilisateur peut dessiner chaque vignette indépendamment, l'annoter avec les dialogues, modifier la durée, ajouter du son, animer une caméra virtuelle, et faire un premier travail de montage en réordonnant les plans, tout en ayant une interface dédiée au dessin. Dans TVPaint, les plans et séquences ainsi créés pourront servir de base pour les plans du film, et une arborescence reflétant l'organisation du film pourra être générée d'après le storyboard.

### III.2.1.3 Storyboarder

Du côté des solutions libres, Storyboarder [45] est un programme open source développé depuis la fin 2016 au sein de la société de production Wonder Unit. Il est uniquement conçu pour le storyboard et l'animatique. Il peut également être intégré dans une chaîne de fabrication de film.

Dans ce programme, le processus de conception est beaucoup mieux intégré que ce que permettent les logiciels purement dédiés au dessin comme Photoshop ou même dans une certaine mesure Krita, qui permet aussi de faire de l'animation. Une première différence fondamentale se situe au niveau des métadonnées. En effet, il permet bien sûr de dessiner les vignettes du storyboard, mais également de les annoter comme décrit précédemment (action, dialogue, etc.), d'y ajouter du son, de les réordonner et de les
minuter précisément. Une seconde différence concerne les entrées/sorties : Storyboarder, puisqu'il n'est prévu que pour la création de storyboard, prévoit plusieurs manières de faire passer les données depuis et vers les autres départements.

Intégration dans le pipeline

Il est possible de construire le storyboard à partir d'un scénario rédigé dans un format spécialisé<fnref n="3" />, et ainsi obtenir la structure complète du film, déjà annotée avec les dialogues et l'action.

Ensuite, tout comme les programmes décrits plus haut, Storyboarder permet l'ex-
port vers un fichier PDF pour échanger le document, ou vers une animation, et ainsi
obtenir directement une animatique. Mais il est également possible d'exporter les images
individuellement et de les traiter dans un outil à part, soit pour générer le storyboard
avec une autre mise en page que celle proposée par l'application, soit pour en faire tout
autre chose, par exemple les importer dans un outil de suivi de production ou de gestion
d'assets.

Enfin, le format de fichier lui-même utilise JSON*, ce qui permet d'intégrer facilement Storyboarder dans un pipeline de fabrication. Par exemple, le fichier de storyboard peut être utilisé pour créer des fichiers de montage, l'arborescence des plans sur le serveur de travail, ou les informations de suivi de production (cf. section I.1.2.4).

L'intégration de ce logiciel n'a pas encore été tentée au sein des Fées spéciales, d'abord
faute de temps pour développer le pipeline, puis faute d'une œuvre d'envergure suffisante
pour susciter ce développement. Mais dans la perspective d'un pipeline entièrement
libre, ce logiciel semble la piste la plus intéressante à développer car il pourrait très
bien s'intégrer au pipeline, sans que celui-ci ne dépende d'un seul logiciel pour toute la
production comme c'est le cas avec les solutions propriétaires clef en main.

<footnote n="3">3. Storyboarder lit le format propriétaire Final Draft et le format ouvert Fountain.</footnote>
### III.2.1.4 Storymatic, une solution interne aux Fées spéciales

En 2015, Flavio Perez, directeur technique aux Fées spéciales, a créé un petit programme permettant d'assembler les vignettes d'un storyboard en strips et d'obtenir un storyboard complet et à jour à tout moment. Il présente cet outil, baptisé Storymatic, dans son mémoire de master [20].

À l'époque, deux raisons ont motivé ce développement : d'une part, il n'y avait pas de solution libre complète pour le storyboard, puisque Storyboarder n'existait pas encore. D'autre part, sur les deux projets où ce programme a été utilisé, les storyboards avaient été dessinés sur papier par le réalisateur, ce qui excluait l'utilisation d'un logiciel de dessin, et a fortiori d'un logiciel de storyboard. Il était donc nécessaire de traiter ce document pour en extraire les informations de mise en scène et les intégrer au pipeline.

#### Difficultés de création sans outil dédié

Le but de cet outil est de permettre au storyboarder de dessiner ses vignettes et de les annoter indépendamment, pour ensuite générer le storyboard. Pour expliciter l'intérêt d'un tel outil, j'exposerai d'abord le processus mis en œuvre sur une production qui n'en disposait pas<fnref n="4" /> : les animations pour le musée de Lodève (cf. section III.1.3.1).

Pour cette production, la graphiste chargée du storyboard, Léa Cluzel, a dessiné les vignettes dans le logiciel libre de peinture Krita. Elle rapporte que les storyboards ont été dessinés et assemblés vignette par vignette, et planche par planche, en ajoutant manuellement les annotations :

> « Quand je parlais d'export à la main, c'était pour la première étape de fabrication du storyboard. On créait un fichier par plan, et on exportait à la main les images (il pouvait y avoir entre 1 et 10 images par plan). Du coup les retakes* étaient pénibles car le moindre changement nous faisait faire de nombreuses manipulations : passer d'un fichier à l'autre sans arrêt, renommer le fichier si le numéro de plan avait

<footnote n="4">4. La production ayant souffert de problèmes d'organisation, Storymatic n'a pas pu être mis en place par l'équipe technique et les graphistes ont donc utilisé des méthodes plus primitives et moins automatiques.</footnote>
changé, réexporter chacune des images... et refaire les planches des storyboards,
avec la numérotation et les annotations à la main.<fnref n="5" /> »

Les vignettes des plans étaient donc, dans ce processus, organisées en fichiers, et à chaque version du storyboard, chaque fichier devait être rouvert, exporté, nommé, importé dans le fichier de planche, puis mis en page et annoté avant d'obtenir le document.

Ce processus avait aussi l'inconvénient majeur que les métadonnées associées aux plans, telles que leur numérotation et leurs durées, n'y étaient pas formellement attachedes, mais ajoutées manuellement à chaque export, en les collant sur l'image. Le logiciel Krita n'étant pas conçu pour le scénario, il était impossible de réaliser cette opération automatiquement.

## Automatisation du processus

Afin de simplifier ce processus, Storymatic permet d'assembler les vignettes de storyboard en bandes et en planches, à partir de dessins soit numérisés, soit directement issus d'un programme de dessin. En effet, une mise en page manuelle du storyboard est un processus non seulement très long, mais aussi source d'erreur, et surtout, destructif : la suppression ou l'ajout d'une vignette demande de refaire toute la mise en page, puisqu'elle dépend de l'ordre et du nombre de vignettes précédentes. Or, un storyboard est un document amené à évoluer de nombreuses fois au cours de sa conception ou au cours de la fabrication, au gré des allers et retours avec les commanditaires et interlocuteurs. Ajoutons qu'il faut que les dialogues et indications de mise en scène figurent au bon en-droit pour chaque version du storyboard. Un outil d'édition automatique devient donc vite incontournable pour simplifier la tâche des graphistes.

Dans Storymatic, le nommage des images est à la charge du graphiste, et détermine automatiquement leur ordre dans le storyboard. Le graphiste commence donc par nommer ses vignettes selon la place du plan* dans le film, par exemple S02-P08.png pour le huitième plan de la deuxième séquence. Un fichier texte à part permet de renseigner les métadonnées associées au plan, telles que dialogue, action, décor, transitions, etc.

<footnote n="5">5. Entretien avec l'auteur, 24 juin 2019.</footnote>
À partir de ces indications, le programme Storymatic crée automatiquement un fichier PDF du storyboard, imprimable et échangeable.

Cette manière de procéder a très bien fonctionné sur le long-métrage *Dilili à Paris* et pour la série animée *Bonjour le monde*. Elle est simple et demande peu de formation, seulement de la rigueur dans la création des éléments. De plus, dans la mesure où elle n'est pas spécialement attachée à un type d'œuvre particulier, comme l'est par exemple TVPaint avec l'animation 2D, elle peut être utilisée sur différents projets d'animation 2D, 3D ou hybride. Elle ne demande pas d'acquérir ou d'apprendre un programme complexe pour cette tâche techniquement assez simple, et peut facilement s'adapter à un pipeline.

## Publication hasardeuse

Ce programme a été publié par les Fées spéciales en 2016 [52]. Cependant, cette publication a souffert de deux problèmes : son rôle d'outil maison et son manque de licence.

En effet, comme souvent dans les studios d'animation, l'outil a été développé au cours de projets précis, et non pas prévu dès le départ pour une publication. Il en résulte que le logiciel n'est pas conçu pour les usages d'autres équipes. Il est mal documenté, et n'a pas été testé en dehors du studio.

Le second problème, à la fois plus grave et plus facile à résoudre, est que le logiciel est propriétaire, et donc inutilisable en l'état. En effet, son code source est accessible, mais aucune licence n'y est attachée, ce qui le met par défaut sous la protection du droit d'auteur. La publication simple ne confère pas aux utilisateurs potentiels les droits attachés au logiciel libre (cf. section II.1.1). Aucune bonne raison ne motivait ce choix de ne pas utiliser de licence, c'était un simple oubli de la part de l'auteur, dont je me suis aperçu à la rédaction de cette thèse. Mais cet oubli illustre que le choix de publication par défaut, qui est de ne pas choisir, ne permet presque aucune utilisation du programme.
### III.2.2 Layout

Le layout (cf. section I.1.2.1) est une étape cruciale dans la production d'un film d'animation 3D, puisque c'est le premier passage à la 3D à proprement parler, après l'animatique. C'est à cette étape que l'on prend une grande partie des décisions de mise en scène, et que l'on crée des scènes 3D qui se retrouveront en aval dans le pipeline*.

Comme nous l'avons vu dans la section précédente, l'architecture du projet peut déjà être envisagée ou même établie à la création du storyboard et de l'animatique. C'est cependant au layout qu'elle est le plus souvent créée. C'est là que sont fabriqués les premiers assets*, les scènes 3D, les fichiers de montage et les premiers rendus. Il faut donc que dès cette étape le pipeline soit établi, ou au moins solidement ébauché, et que les plans* de layout puissent être réutilisés. Cela implique que le programme utilisé pour mettre en place les caméras, les décors et animations provisoires, soit compatible avec les départements suivants.

L'étape du layout est différente de celle de l'animation dans la qualité des animations, et dans la finition générale des plans, mais elle utilise techniquement les mêmes outils. Il n'existe donc pas de programme spécifiquement dédié au layout, et on utilise en général le même que pour l'animation. Le logiciel de création 3D* libre le plus utilisé est Blender, y compris pour le layout. Il a toutes les fonctionnalités nécessaires pour mettre en place le layout : placement et animation de caméras, modélisation, rendu rapide (playblast).

#### III.2.2.1 Outils spécifiques pour le layout des Fées spéciales

Comme à toutes les étapes de la création 3D, des outils spécifiques doivent souvent être conçus pour traiter des problématiques propres à un studio ou à un projet précis. Pour développer la manière de fonctionner du studio concernant le développement et la publication d'outils open source, j'exposerai deux outils développés en interne pour répondre à des problèmes très spécifiques de layout, et diffusés ensuite à l'extérieur.

Il faut rappeler que le pipeline développé par la société Les Fées spéciales pour certaines de ses productions a pour particularité l'utilisation de pantins et de décors
plans* dans un espace 3D. Cela permet de bénéficier de la facilité de conception et de mise en place de la 2D, et de la puissance de mise en place de la 3D. Les décors en question sont plans, comme les décors de théâtre (figure III.2.1). Chaque niveau de décor est peint sur un calque à part dans un logiciel de dessin, et ils sont ensuite importés dans la scène 3D. Ce processus est beaucoup plus rapide que la création de décors intégralement modélisés en 3D, mais offre en contrepartie des possibilités de mise en scène bien plus limitées, puisque la caméra ne peut pas se déplacer comme bon lui semble dans la scène, mais doit rester parallèle au décor. En fait, ce procédé est directement inspiré du banc-titre et de la caméra multi-plans*. On le retrouve tel quel dans les logiciels d'animation 2D, mais on peut obtenir un effet similaire dans un espace 3D en y plaçant des plans avec des textures.

<figure><img src="image_7.png" /><figcaption>FIGURE III.2.1 – Plan du film *Dilili à Paris*. Chaque rectangle noir constitue un plan du décor.</figcaption></figure>

Du fait de la spécificité de ce pipeline, les outils exposés ne sont donc pas utiles à toutes les productions d'animation 3D, mais le processus de développement et de publication n'en est pas moins révélateur.
## Camera planes

Le premier de ces outils a été co-développé par le directeur technique Flavio Perez et moi, et baptisé *Camera planes* 6. Il a pour but de faciliter la mise en place des décors en 3D. Sans notre outil, cette mise en place serait inutilement difficile car il faudrait importer et placer les décors dans la scène 3D, pour qu'ils apparaissent non seulement à la bonne taille dans la vue de la caméra, mais que les différentes couches soient placées à la bonne distance et que les éléments animés puissent y être insérés. Sachant qu'un décor de film peut être composé de dizaines, voire de centaines de couches devant l'action (*overlay*) et derrière (*underlay*), il est infaisable de le faire de cette manière.

Pour simplifier cette mise en place, cet outil expose une interface à l'utilisateur, permettant de choisir les fichiers de décor, et de les placer automatiquement dans la pyramide formée par la vue de la caméra, dans le même ordre que les calques du logiciel de dessin. L'idée est donc de retrouver strictement la même disposition. Les plans seront ensuite espacés dans la profondeur, comme un décorateur le ferait sur une scène de théâtre.

Il est ainsi facile de séparer la conception des décors de celle de leur mise en scène dans l'espace 3D. Une fois les décors placés dans la scène, la caméra peut être animée afin d'obtenir des mouvements similaires à ceux d'une caméra multi-plans*.

## Rig de caméra 2D

Un autre outil a été créé pour faciliter la mise en scène dans un décor plan. Il s'agit d'un rig de caméra 2D, c'est-à-dire un objet permettant de manipuler la caméra de manière non seulement plus intuitive, mais également bien plus précise que celle qu'offrent par défaut les logiciels de création 3D*. En effet, les contrôles d'une caméra 3D sont logiquement adaptés à un layout en 3D : animation de la position, de l'orientation, de la focale, de la profondeur de champ, etc. Pour animer la caméra, il faut donc modifier ces paramètres un par un et les animer : les faire varier en fonction du temps. Mais pour

<footnote n="6">6. Notons ici que le nom de l'outil est à la fois en anglais, pour pouvoir plus facilement être diffusé auprès d'une communauté internationale, et peu imaginatif, témoignant du peu de soin apporté au choix du nom des outils lorsqu'on est en pleine production.</footnote>
un film dans des décors plats, ces contrôles ne sont pas intuitifs du tout : il est plus logique de décider du cadre en déplaçant les coins de la caméra, comme on le ferait en plaçant un cadre autour d'une photographie. C'est ce que permet cet outil.

Les contrôles standards de caméra sus-mentionnés suffisent pour pouvoir mettre en œuvre cette logique de cadrage différente. Ainsi, grâce à la souplesse de l'API* du programme, nous avons compensé le manque de fonctionnalité en développant un outil spécifique. Il ne modifie pas le modèle de caméra, mais crée une série de contrôles simplifiés pour l'utilisateur. C'est donc un niveau d'abstraction supplémentaire qui ne change pas le fonctionnement du programme de base, mais y ajoute une couche pour cacher une partie de sa complexité.

### III.2.2.2 Publication sous licence libre

Comme souvent, ces outils partent du constat d'une fonctionnalité manquante, et de la capacité interne de concevoir et développer cette fonctionnalité. Ces deux outils ont été publiés sous licence libre GPL (cf. section II.1.3). Ils sont donc disponibles à tous pour les utiliser et les adapter à leurs usages, et bien qu'ils soient restés assez confidentiels, sans doute par manque de communication de la part de la société, ils n'en ont pas moins reçu un bon accueil de la communauté.

Une telle publication peut soulever des questions pour les studios, dans la mesure où elle comporte des contraintes supplémentaires pour le développement des outils. Ils devront aussi être maintenus pour rester utiles à tous et ne pas devenir obsolètes. Ces problématiques sont abordées plus en détail dans la section II.3.3.2.
# Chapitre III.3

## Fabrication

### Introduction

Les différentes étapes de la fabrication (cf. section I.1.2.2) sont la suite logique du layout, et on utilise généralement les mêmes outils pour le layout et pour l'animation. C'est à ce stade que le plus gros du film est créé par les graphistes, et il est indispensable, peut-être plus encore qu'aux autres stades (cf. chapitre III.2) d'avoir des outils performants, et un pipeline* solide. Ces outils dépendent du type d'œuvre, mais pour les projets sur lesquels j'ai travaillé, les logiciels Krita et Blender ont été au cœur des processus de fabrication.

Ce chapitre explorera les processus mis en œuvre dans une production d'animation utilisant le logiciel libre, pour permettre aux graphistes de travailler efficacement. Je me concentrerai d'abord sur le rigging (cf. section I.1.2.2) et l'animation (cf. section I.1.2.2), simplement du fait que j'ai passé presque un an à développer un système de rig automatique et d'animation dans Blender, puis j'aborderai les moteurs de rendu (cf. section I.1.2.2) libres utilisés en production, et les programmes de compositing (cf. section I.1.2.3).
# III.3.1 Rigging et animation de personnages : les pantins

## III.3.1.1 Initiation et historique du projet

Le rigging et l'animation sont deux des étapes les plus complexes et les plus longues à mettre en œuvre sur une production d'animation. Le rigging, parce qu'il demande des connaissances techniques pointues, et l'animation parce qu'elle est simplement lente : les animateurs font en général entre deux et dix secondes d'animation par jour, selon le niveau de qualité et le médium*. Pour pallier en partie cette complexité, les Fées spéciales ont choisi de développer des outils permettant d'utiliser une technique d'animation particulière, celle des pantins en papier découpé, parfois appelée « cutout ». J'expliquerai les intérêts de cette technique pour une production de film, et les difficultés de mise en œuvre au sein d'un pipeline* libre où les outils disponibles ne répondaient pas à nos besoins.

Dès la création du studio Les Fées spéciales, le choix a été fait d'utiliser cette technique pour ses propres productions, et si possible pour les prestations également. La technique tire son nom du médium utilisé, développée elle aussi au cours du XXᵉ siècle, par des auteurs comme Lotte Reininger. La raison première de ce choix par la société est la collaboration, pour le premier projet du studio, avec le réalisateur Michel Ocelot, qui est adepte de la technique et l'a utilisée dès ses débuts sur des films et séries comme *Les Trois Inventeurs* et *La Princesse sensible*. Plus récemment, il l'a aussi utilisée, en version numérique, pour des longs métrages, dont *Les Contes de la nuit*.

Dans sa variante historique, la technique consiste à dessiner un personnage sur du papier, puis à en découper les parties du corps et les accessoires, qui seront articulés à l'aide de ficelles ou d'attaches parisiennes. Les personnages sont ensuite placés sur un banc-titre<fnref n="1" /> et animés image par image. Le personnage est filmé, soit à contre-jour et apparaît ainsi en silhouette noire sur blanc, soit éclairée du dessus, laissant apparaître

<footnote n="1">1. Appareil permettant de filmer l'animation image par image, consistant en une table lumineuse filmée par une caméra mobile accrochée au-dessus.</footnote>
les détails, les ombres et la texture du papier.

Tout comme dans les autres techniques de l'animation, l'outil numérique remplace rapidement les objets physiques pour faciliter la création et l'animation. En utilisant l'ordinateur, on peut accélérer et automatiser beaucoup d'étapes, tout en conservant la même latitude expressive et les mêmes principes d'animation que sur papier.

Sur le film *Dilili à Paris*, l'animation principale des protagonistes du film était faite en 3D, mais l'auteur souhaitait faire apparaître des foules de personnages dans certaines séquences* pour donner de la vie à l'environnement du film. La création en 3D de certaines de figurants satisfaisant les ambitions artistiques du réalisateur aurait été bien trop chère pour le budget du film. Il a donc été décidé de reprendre la technique des pantins utilisée par Michel Ocelot sur ses projets précédents. C'est en partie pour cette raison que les Fées spéciales ont été contactées : pour pouvoir prendre en charge le travail de conception et d'animation des pantins, ainsi que le layout.

La production du long-métrage *Dilili à Paris* a été donc été l'occasion de développer des outils spécifiques pour l'animation de pantins. Il existait déjà des solutions, mais elles ne pouvaient pas être intégrées au pipeline de fabrication 3D du film (cf. section III.3.1.3).

## Inspirations

Lors du précédent long-métrage de Michel Ocelot, *Les Contes de la nuit*, dont l'esthétique reprenait celle des films en papier découpé mais dont la fabrication était numérique, un système de création de personnages assisté avait été conçu par l'animateur Jean-Claude Charles. Il permettait de découper et rigger les personnages rapidement, ce qui est crucial pour une œuvre mettant en scène de nombreux personnages. Cet outil fonctionnait dans le logiciel utilisé pour l'animation de ce film, Autodesk Maya (figure III.3.1).

Pour la fabrication de *Dilili*, les Fées spéciales avaient pris la décision dès la création d'utiliser le logiciel de création 3D* Blender. Il était donc impossible, même dans l'hypothèse où les outils Maya avaient été disponibles, de les utiliser directement dans notre chaîne de fabrication fondée sur Blender, les API* de Blender et de Maya étant tout à
<figure><img src="image_8.png" /><figcaption>FIGURE III.3.1 – Interface développée dans Maya pour *Les Contes de la nuit*.</figcaption></figure>

fait incompatibles. Il fallait donc écrire de nouveaux outils répondant à un cahier des
charges similaire. Pour nous aider, Jean-Claude, qui a aussi travaillé sur *Dilili* en tant
que premier assistant réalisateur, a transmis au début de la fabrication (mars 2016) un
ensemble de vidéos illustrant le fonctionnement du système de rigging automatique, et
les fonctionnalités d'animation des pantins eux-mêmes (figure III.3.1). N'ayant que peu
d'expérience d'animation, ces vidéos ont été une inspiration précieuse pour la conception
et le développement de ce qui allait devenir mon outil de pantins. De même, j'ai analysé
des rigs de pantins existants, comme celui de Pepper, utilisant le dessin d'un person-
nage de bande dessinée créé par David Revoy<fnref n="2" />, et riggé par l'animateur et rigger russe
Nikolai Mamashev. Une autre inspiration a été le travail de rig mené sur le personnage
de Tomoe Gozen et son cheval, dessinés par mon collègue Eric Serre et riggés par le
graphiste Philippe Giffard. Tomoe, riggée entièrement à la main, est dotée de systèmes

<footnote n="2">2. Cette bande dessinée en ligne est une des rares à être diffusée sous une licence de libre diffusion (Creative Commons Attribution 4.0, cf. section II.1.4), permettant ainsi à n'importe quel créateur d'utiliser les personnages ou même directement les textes et images pour créer des œuvres dérivées.</footnote>
très proches de ce que je souhaitais obtenir avec l'auto-rig.

### III.3.1.2 Contraintes

La création d'un système d'auto-rig n'est pas triviale, et il faut tenir compte avant de commencer des contraintes du projet et de la structure, concernant les possibilités artistiques, techniques, budgétaires, et de production.

<figure><img src="image_9.png" /><figcaption>FIGURE III.3.2 – Concept art de Michel Ocelot, avant le début de la fabrication.</figcaption></figure>

#### Délais de fabrication

Le premier critère du système était que les pantins soient rapides à fabriquer. En réalisant des prototypes de rigs, j'ai estimé le temps de fabrication d'un pantin sans outil d'automatisation à une semaine, d'un bout à l'autre, dessin exclus. Il faut garder à l'esprit que des centaines de personnages devaient habiter les scènes du film, et que pour
la plupart, ils étaient équipés de rigs similaires, mais à chaque fois légèrement différents. Il était donc impératif d'automatiser la création. C'est un cas où l'automatisation ne permet pas seulement de faire gagner un peu de temps et d'efficacité à l'équipe de graphistes, mais, simplement, de terminer le film.

Une autre contrainte importante était celle du calendrier. En effet, j'ai commencé à travailler sur ce projet dès mon arrivée dans la structure, et la fabrication du film a démarré aussitôt. Je n'avais que très peu de battement pour arriver à un programme fonctionnel. Les premiers pantins du film ont donc été riggés par moi et d'autres graphistes, « à la main », sans automatisation du processus, en parallèle de la conception du prototype de rig complet, puis du développement des outils de rigging.

## Fidélité du design

Une des demandes artistiques principales était la fidélité du personnage au design original décidé par l'auteur. En effet, ce dernier souhaitait retrouver tels quels dans le film les personnages qu'il avait dessinés (figures III.3.2 et III.3.3). Cela signifie que le processus de fabrication des pantins devait s'appuyer sur les images numériques envoyées par Michel Ocelot, et qu'un contrôle rigoureux de la fidélité au dessin original soit opéré à chaque étape<fnref n="3" />.

Les pantins sont considérés comme des figurants. À ce titre, ils apparaissent en général en arrière-plan et sont cadrés plus large que les personnages principaux. Ils sont moins détaillés, et ne doivent pas offrir des possibilités d'animation aussi complètes que leurs homologues 3D. Néanmoins, ils doivent avoir une gamme de mouvements suffisant à donner l'illusion de leur présence parisienne, à leur offrir une individualité, en un mot à proprement les animer. Techniquement, plusieurs besoins ont émergé de mon étude des rigs de pantins de Jean-Claude, et de conversations avec l'animateur des pantins, Léo Silly-Pelissier.

<footnote n="3">3. Voir aussi l'annexe C et le point de vue d'un artiste sur la polyvalence artistique de la technique des pantins.</footnote>
<figure><img src="image_10.png" /><figcaption>FIGURE III.3.3 – Une image du layout correspondant au concept précédent.</figcaption></figure>

## Systèmes d'animation

Les rigs devaient être dotés de contrôleurs (figure III.3.4) relativement standards : membres en FK et IK* avec bascule ; *foot roll* ; plusieurs articulations dans le torse ; tête et membres détachables pour bouger le point d'articulation ; membres étirables pour donner l'illusion d'un dessin en raccourci ; variations colorées des éléments (vissages, habillements) pour augmenter la variété d'un personnage sans le redessiner et rigger ; variations animables pour différents éléments (par exemple, animation de main pour effectuer une action, ou animation des yeux pour le clignement). Les personnages devaient de plus pouvoir se retourner, c'est-à-dire être tournés, soit vers la droite, soit vers la gauche. Il devait être facile d'intégrer des accessoires à un personnage donné, comme cannes, bouquets, parapluies, chapeaux, volets de jupes, landaus, etc. Et bien sûr, il n'y avait pas deux morphologies identiques dans les dessins de Michel Ocelot.

Les rigs de pantins numériques peuvent être conçus pour permettre d'animer les personnages de manière fine, avec des déformations pour créer l'illusion de rotation ou de raccourci. Dans la mesure où les pantins du film étaient des figurants assez peu détaillés, que le style d'animation souhaité par le réalisateur ne requiérait pas ce type
<figure><img src="image_11.png" /><figcaption>FIGURE III.3.4 – Rig de personnage pantin dans *Dilili à Paris*. Les formes géométriques sont les contrôleurs accessibles aux animateurs, et la majeure partie de la complexité du rig est cachée.</figcaption></figure>

de contrôles, et que leur mise en œuvre aurait complexifié le travail des riggers comme des animateurs, je n'ai pas créé de système de déformation pour les pantins de ce film.

Outre les considérations de rig et d'animation, des contraintes de pipeline propres à la production sont apparues. En effet, comme expliqué dans la présentation du projet (section III.1.1), le layout et l'animation des foules étaient faits par les Fées spéciales, puis exploités par le studio Mac Guff. Je reviendrai plus en détail sur ces questions dans le section III.5.2, mais il faut retenir pour le moment qu'elles ont imposé des contraintes supplémentaires pour le système de pantins.
Modèle : Réf Couleur
S12-Aristide Bruant

Validé le : 16 septembre 2016

Nord-Ouest films, Studio O

Dili à
PARIS

<figure><img src="image_12.png" /></figure>

FIGURE III.3.5 – Aristide Bruant dessiné par Michel Ocelot. Ici, la couleur du personnage est également fournie, mais beaucoup de pantins ont été colorisés par l'équipe pantins des Fées spéciale. On voit en haut à gauche le cartouche de Michel Ocelot, et à gauche la toise permettant de dessiner les personnages à l'échelle.
## Passage du dessin à d'animation

Concernant la manière de créer un personnage, il fallait d'abord créer une passerelle entre le logiciel de dessin (Photoshop ou Krita) et le logiciel d'animation 3D (Blender). Chaque membre 4 étant dessiné sur un calque à part (figures III.3.5 et III.3.6), ce dessin et sa décomposition en calques devaient se retrouver à l'identique dans Blender. Les points d'articulations devaient aussi pouvoir être placés dans le logiciel de dessin pour permettre à l'équipe Pantins de concevoir la dynamique du personnage en même temps qu'elle le dessinait.

Une fois le dessin du pantin correctement importé dans la scène Blender, il fallait que la création du rig soit simple et prévisible. Dans l'idéal, le personnage aurait été riggé à l'appui d'un seul bouton, mais un tel système aurait requis, soit trop de contraintes sur le rig, soit d'être beaucoup trop avancé pour être mis en œuvre. Le système que j'ai conçu est donc plutôt un assistant au rig qu'un autorig complètement autonome. Néanmoins, il réduit considérablement les étapes de création et assure une cohérence entre les différents pantins, grâce à une nomenclature standard des membres.

### III.3.1.3 Solutions existantes

Après plusieurs semaines d'étude et de prototypage des systèmes de rig, les contraintes n'étaient pas formalisées dans un cahier des charges technique, mais elles étaient assez clairement définies pour que j'engage le développement d'outils. J'ai commencé par rechercher des outils existants pour créer des pantins. Il existe de nombreux logiciels propriétaires, et quelques logiciels libres. Je n'en ferai pas ici une liste exhaustive, mais j'en mentionnerai deux qui ont été considérés, et les raisons qui m'ont poussé à développer un nouveau système.

D'abord, j'avais connaissance depuis quelques années de DUIK, un plug-in* de pantins pour Adobe After Effects dont l'efficacité a été démontrée par son utilisation sur de

<footnote n="4">4. On entendra par « membre » un élément mobile du rig, correspondant à un calque dans le logiciel de dessin, à une plaque en 3D, et à un os dans le rig. Ainsi, un avant-bras peut être membre, tout comme un orteil, une jupe ou un parapluie.</footnote>
nombreuses séries animées et autres œuvres<sup>5</sup>. Je l'avais vu à l'œuvre lors de la fabrication d'un court-métrage d'Eric Serre, *Herakles, aux origines de la Crau*, en 2014. Il avait servi à rigger tous les personnages, y compris des chevaux. Ce programme, malgré sa grande qualité et bien qu'il soit libre<sup>6</sup> et développé en France par la SCOP Rainbox, a cependant été éliminé, pour des raisons de licence et d'utilisation. En effet, si le plug-in est lui-même libre, il demande à être exécuté dans un environnement non-libre, dans After Effects sous Windows ou Mac OS, or les Fées spéciales utilisent GNU/Linux*. De plus, le pipeline* requérant d'être en 3D et fondé sur Blender pour pouvoir être transmis à Mac Guff, une solution After Effects ne convenait pas.

Dans Blender, l'add-on* COA Tools (Cutout Animation Tools) [44], développé par Andreas Esau, existait et répondait à certaines contraintes de la production. C'est un outil permettant d'accélérer la création de rigs, en fournissant par exemple des solutions pour découper les plaques, dessiner rapidement le squelette et opérer le parentage et le skinning* plus facilement qu'avec les fonctions standards de Blender. Il offre également un système d'échange avec les applications de dessin Adobe Photoshop et The GIMP pour pouvoir échanger les calques entre le logiciel de dessin et le logiciel de création 3D*, ainsi que leur position et leur nomenclature. Cependant, cet add-on, très utile pour des graphistes seuls et expérimentés, n'était pas adapté à l'échelle de la production (pour rappel, des centaines de personnages similaires), et à l'équipe de rig, dont nous savions qu'elle serait en partie débutante et pour laquelle le processus devrait être simplifié au maximum. De plus, il ne permet pas de développer un rig qui ait à la fois des contrôles avancés, et soit facilement reproductible.

### III.3.1.4 Développement de l'outil de rig de pantins

Même s'il existait des solutions répondant à certains de mes critères, aucune n'était entièrement satisfaisante. Il fallait donc, soit partir de zéro et concevoir une solution originale, soit modifier une solution existante. Connaissant un système de rig modulaire

<footnote n="5">5. L'entretien présenté en annexe C présente un autre point de vue sur la facilité d'utilisation de DUIK.</footnote>

<footnote n="6">6. Il est disponible sous licence GNU GPL, cf section II.1.3.1.</footnote>
intégré à Blender, j'ai choisi la deuxième solution.

J'ai utilisé et détourné l'add-on Rigify pour créer le système de génération de rigs. Le système d'autorig est composé de plusieurs sous-systèmes permettant la fabrication des pantins, de leur découpage à leur rendu. Je décrirai maintenant le fonctionnement de ces sous-systèmes.

## Dessin des plaques

Comme expliqué en introduction de ce chapitre, l'intérêt artistique de cette technique est de retrouver à l'identique le dessin de concept dans le personnage animé définitif. Pour cela, le dessinateur peut utiliser des outils physiques traditionnels, auquel cas le dessin sera numérisé avant d'être retraité numériquement, ou directement un logiciel de dessin. Dans tous les cas, le concepteur n'est pas nécessairement l'animateur, ni le rigger du personnage. Ainsi, il n'est pas nécessaire d'avoir de quelconques connaissances techniques pour que son personnage se retrouve à l'identique dans le film. Pour *Dilili* par exemple, l'auteur Michel Ocelot a dessiné la quasi-totalité des figurants, sans jamais utiliser Blender.

Entre le dessin du personnage, sur papier ou numérique, et le début du rig dans Blender, une étape intermédiaire dans un logiciel de dessin est nécessaire. Les pantins étant animés, les différentes parties de leurs corps doivent nécessairement bouger l'une par rapport à l'autre. Il faut donc les « découper » en éléments, qui seront reliés entre eux au moment du rig. Dans la technique traditionnelle, cette découpe est littérale : on coupe chaque partie du corps avec des ciseaux, et on les attache ensemble avec de la ficelle ou des attaches parisiennes. Dans la version numérique, on part du dessin et, pour chaque partie, on la sélectionne et on la place dans un calque à part en prenant soin que les zones d'articulations soient couvertes par les deux parties. Par exemple, au niveau du genou, où la cuisse et la jambe se rejoignent, on trace un cercle, et on découpe autour sur les deux parties.

Sur *Dilili*, les dessins étaient fournis au trait, c'est-à-dire sans couleur. Ils étaient donc d'abord colorisés dans Krita avant d'être découpés. Pour le système d'autorig, j'ai
<figure><img src="image_13.png" /><figcaption>FIGURE III.3.6 – Vue éclatée d'Aristide Bruant, découpé par l'équipe pantins.</figcaption></figure>
conçu un modèle de fichier contenant déjà tous les calques vides, correctement nommés et organisés selon une nomenclature figée. L'équipe des pantins pouvait donc copier chaque partie du dessin original, et la coller dans le calque correspondant. Cette nomenclature standardisée, en contraignant les graphistes à une forme toujours identique, a plusieurs avantages. Elle leur évite de devoir organiser et nommer tous les calques pour chaque pantin. Elle permet aussi, dans le logiciel de 3D, d'identifier automatiquement les calques pour les parenter correctement, comme nous le verrons plus loin.

Dans les cas où plusieurs parties du corps se superposent, par exemple si la main est dessinée le long du corps, il faut faire en sorte qu'elle ne se retrouve que dans le calque correspondant, et donc effacer la main du calque du torse.

## Import des plaques dans le logiciel de création 3D

Une fois le pantin dessiné et découpé, chaque partie du corps indépendante se trouve dans un calque dans le fichier de dessin. Avant de pouvoir commencer le rig dans Blender, il faut pouvoir l'y importer. Cette partie du processus a été assez rapide à mettre en œuvre, car elle s'appuie sur un add-on* existant. Développé par Jasper van Nieuwenhuizen [55], un importeur de fichiers Photoshop permet d'utiliser ce format et de retrouver dans la scène 3D les calques, avec leur ordre, leur hiérarchie (groupes), et leur position. Certaines informations, comme les modes de fusion et options de calques sont perdues, mais les données de pixel sont suffisantes pour notre besoin.

L'add-on* est publié par son auteur sous licence GPLv2. J'ai donc pu y apporter les modifications nécessaires pour l'usage du projet (correction de bugs, préréglages, et différentes options concernant la nomenclature et la création des matériaux). Ces modifications ont depuis été réintégrées par l'auteur dans le code principal.

Il est à noter que le format utilisé est celui de Photoshop (PSD), mais que les pantins sont découpés sous Krita. En effet, quoi que le format PSD ne soit pas normalisé, une spécification assez précise a été publiée par Adobe [59], et les développeurs de Krita l'ont implémentée dans leur logiciel. Il est donc utilisé dans la chaîne de fabrication plutôt que le format natif de Krita, simplement à cause de l'outil d'import de pantins dans Blender.
Ce type de fichier est complexe, et du fait de la disponibilité de la spécification du format PSD, des bibliothèques* Python sont disponibles pour le lire et l'écrire. C'est sur une de ces bibliothèques que s'appuie l'add-on de Jasper 7. Un analyseur des fichiers Krita pour Python aurait été trop coûteux à mettre en œuvre à l'époque. Depuis, Krita intègre la possibilité de scripter le programme et une solution d'échange direct Krita-Blender est envisagée, mais n'a pas encore été développée, le bénéfice étant trop mineur par rapport au temps de développement.

## Rigify

Rigify est un système d'auto-rig modulaire et extensible. C'est un add-on* officiel, c'est-à-dire maintenu par les développeurs de Blender, et distribué avec. Il est utilisé pour créer rapidement des personnages 3D. On construit un rig à partir de « briques » ayant chacune un jeu de fonctionnalités propres. Par exemple, on peut ajouter dans son rig un module *torse*, des modules *bras*, des *jambes*, etc.

La création d'un rig avec Rigify se fait en deux étapes. Les différents composants sont positionnés de façon à correspondre à la morphologie du personnage, puis le rig est « généré », c'est-à-dire que les mécanismes et contrôleurs sont créés par le programme d'après cette morphologie (figure III.3.7). L'intérêt est de séparer la forme du personnage de ses fonctionnalités. Par exemple, on pourra créer le rig de deux personnages ayant des mécanismes identiques, mais des morphologies très différentes. Ou bien, on pourra ajouter facilement des membres supplémentaires au personnage, sans devoir rigger ces membres individuellement. Un rig pouvant être constitué de centaines d'éléments longues (os, contraintes, *drivers*) devant correspondre à une nomenclature rigoureuse, et chacun de ces éléments prenant un temps non négligeable à mettre en place, on voit la rapidité et la flexibilité que peut offrir un tel système.

Les possibilités de l'add-on correspondaient assez bien aux contraintes de *Dilili*, mais le système n'était pas du tout conçu pour des personnages de type pantin. Quoique flexible pour faire des personnages 3D, Rigify ne permet pas par défaut de créer n'importe

<footnote n="7">7. La bibliothèque Python utilisée est psd-tools [57].</footnote>
<figure><img src="image_14.png" /><figcaption>FIGURE III.3.7 – Squelette généré par l’add-on Rigify. À gauche, le squelette de base, avec 29 os. À droite, le squelette généré automatiquement, avec 217 os et des centaines de contraintes et de drivers.</figcaption></figure>

quel rig, la génération des personnages étant prévue en dur dans le code, c'est-à-dire impossible à modifier pour l'utilisateur lambda. Pour ajouter des fonctionnalités, il fallait modifier l'add-on. Aussi, j'ai dû étudier le code pour déterminer comment y ajouter des modules supplémentaires, qui utiliseraient les mêmes principes, sans nécessairement être compatibles avec le système de base, car les deux utilisations diffèrent radicalement.

En tant que système modulaire, Rigify est constitué de trois types de scripts* fondamentaux :

- le système de génération, qui constitue le cœur du programme,

- les différents modules de génération automatique, ou «rigs» <fnref n="8" />,

- des modèles de personnages prédéfinis constitués de «rigs» : les «metarigs».

Mon idée était de garder le cœur tel qu'il existait (en corrigeant et signalant éventuellement les bugs découverts), et d'ajouter des modules de «rigs» et de «metarigs» adaptés

<footnote n="8">8. Terminologie de Rigify. Les mots propres à cet outil et dont la définition diffère de l'habitude seront par la suite entourés de «guillemets simples».</footnote>
aux besoins de *Dilili*. Ainsi, ma version exploiterait les fonctions de génération, en proposant des modèles de personnages très différents. Cette version n'est que partiellement compatible avec l'add-on original, car les nouveaux types de <rigs> ne peuvent pas être mélangés avec les types originaux au sein d'un même personnage.

Ordre des plaques dans l'espace

<figure><img src="image_15.png" /><figcaption>FIGURE III.3.8 – Si l'ordre des plaques dans la profondeur n'est pas défini, il apparaît des conflits.</figcaption></figure>

Par défaut dans Rigify, les os sont positionnés dans l'espace, avec une position et une orientation en trois dimensions. À l'inverse, les pantins, héritage du papier découpé, ne se déplacent qu'en plan, dans deux dimensions. En théorie, retirer une dimension simplifie la conception d'un personnage, puisque les membres ne peuvent plus tourner que selon un seul axe. Dans la pratique, d'autres considérations apparaissent. Lorsqu'on découpe des morceaux de papier et qu'on les lie ensemble, on décide nécessairement lequel passe devant l'autre. On peut aussi changer en cours d'animation. Par exemple, si un personnage danse la gigue, un pied restera au sol et l'autre passera alternative-

ment devant et derrière la jambe fixe. Or, dans un rig en 2D, tous les os sont dans le même plan. Il faut donc pouvoir donner au moteur de rendu des instructions pour dessiner les membres dans le bon ordre, sans quoi on peut se retrouver avec un personnage de profil ayant le cou devant la tête, ou les deux bras devant le torse, dans une interprétation cubiste de la perspective, en plus d'erreurs graphiques (figure III.3.8).

Ce problème est résolu facilement dans les logiciels de dessin 2D, grâce aux calques.
Les calques forment une pile, et sont dessinés l'un après l'autre du bas au haut de la pile, comme des feuilles transparentes empilées sur une table lumineuse (d'où le nom approprié de calques). C'est le cas par exemple dans DUIK, où on peut décider de l'ordre des plaques en réordonnant les calques.

Dans un espace 3D comme celui de Blender en revanche, toutes les plaques sont par défaut dans le même plan. Cela crée des conflits d'affichage, le moteur de rendu ne sachant pas distinguer ce qui vient devant. Il faut donc légèrement décaler ces plaques dans la profondeur. Le premier instinct est de prendre chacun des objets-plaques, et de les décaler jusqu'à ce qu'ils soient tous sur un plan différent, dans le bon ordre. Seulement, cette approche pose rapidement problème dès que l'on veut que le pantin se retourne dans l'autre sens. Si l'on fait faire demi-tour au pantin, l'ordre des plaques est inversé; des plaques qui devaient être derrière se retrouvent devant, et inversement. Les membres eux-mêmes sont inversés : le bras qui était devant se retrouve derrière.

Il faut donc trouver une solution plus évoluée pour résoudre ce problème. Celle que j'ai mise en œuvre consiste à ce que ce

décalage se fasse à l'intérieur du rig, avant le parentage de la plaque à l'os, mais après les mécanismes qui donnent à l'os sa position. J'ai donc décidé de décaler dans la profondeur les os de déformation. Une interface permet au rigger de choisir l'ordre des membres et

<figure><img src="image_16.png" /><figcaption>FIGURE III.3.9 – Espacement exagéré des plaques dans un pantin. Les os sont éloignés les uns des autres, et les plaques qui leur sont parentées paraissent donc dans le bon ordre.</figcaption></figure>
des plaques (figure III.3.9). Cet ordre est stocké dans une structure de donnée définie
exprès, et les plaques sont ensuite décalées à l'aide de *drivers* mus par cette structure
de données. D'une certaine manière, ce système assez complexe permet d'émuler dans
Blender un système de calques propre aux logiciels de dessin, pour obtenir une interface
intuitive, mais assez flexible pour que l'équipe pantin puisse changer l'ordre comme bon
lui semble.

Parentage automatique

La notion de parentage, rapidement évoquée précédemment, désigne un lien qui unit
deux entités dans une scène 3D (objets, os). C'est une relation dans une direction, où une
entité enfant suit les transformations de son parent. Géométriquement, un parentage se
fait en multipliant la matrice du parent par la matrice locale de l'enfant, pour obtenir la
transformation définitive. Ce principe est omniprésent en 3D pour créer une hiérarchie
dans une scène ou au sein d'un ensemble d'objets, comme un personnage.

Dans l'animation 3D, les personnages sont généralement déformables, et sont liés à
leur squelette grâce à un système de skinning*. Dans le cas des pantins, la technique
traditionnelle du papier découpé et articulé ne demande pas de déformation des membres.
Le skinning n'est pas strictement nécessaire et un parentage simple peut suffire. Pour se
faire, on dessine les articulations de manière à ce que les deux parties se superposent.
Par exemple, on découpe le membre inférieur en deux : la cuisse et la jambe, qui se
superposent au niveau du genou pour former un raccord invisible lors de la rotation.

Si toute la fabrication avait été faite dans un même programme (Blender), il aurait
été envisageable de créer des déformations de plaques avec un système de skinning*,
mais plusieurs obstacles ont empêché de le faire sur *Dilili*.

D'abord, s'il est relativement aisé de faire passer des transformations simples de Blen-
der à Maya, les déformations étaient beaucoup plus complexes à transférer au début de
2016, c'est-à-dire à un moment où le format Alembic n'était pas encore intégré à Blen-
der. Je décrirai les problématiques d'échange dans la section III.5.2, mais pour l'heure il
faut savoir que les animations de personnages 3D layout sont justement exportées avec
des caches. On aurait pu utiliser un tel système pour les pantins, ce qui aurait donné
la possibilité de déformer les membres. Mais les opérations de génération, d'export, de
conversion de ces caches sont très coûteuses, et leur poids non négligeable, ce qui était
un élément à considérer pour choisir comment échanger les données entre plusieurs sites.

Ensuite, le processus de skinning est long, difficile à maîtriser, et demandait des
recherches supplémentaires pour permettre la déformation de plaques. Le processus est
aussi difficile à automatiser, car des tests et retouches doivent être effectuées pour obtenir
un skinning correct, ou alors développer des algorithmes spécifiques, ce pour quoi je
n'avais ni les compétences, ni le temps.

Enfin, comme dit précédemment, le réalisateur souhaitait une esthétique proche des
pantins découpés, ce que permettait très bien de se contenter d'un parentage simple.
Nous avons donc décidé, sauf rares exceptions « hors pipe[line]<fnref n="9" /> » de nous contenter de
plaques indéformables.

L'opération de parentage incluse avec Blender assez simple, mais elle doit être répétée
des dizaines de fois pour chaque personnage, pour les centaines de personnages du film.
Pour faciliter ce travail, un outil spécifique a été conçu. Sachant que la nomenclature
des os et plaques des pantins serait toujours similaire, il était logique de construire des
modèles, à la fois dans Krita pour le découpage, et dans Blender pour le rigging. Dans
Krita, un fichier contenant une hiérarchie de calques est établi, permettant de dessiner
les membres d'une manière unifiée, à la fois dans le nommage des calques et dans l'ordre
des plaques (cf. section III.3.1.4). Du côté de Blender, l'utilisation des modèles de rigs
garantit une nomenclature standard — sauf modification par les graphistes.

Variations d'animation

Les dessins des pantins sont statiques. Contrairement à l'animation 3D ou au dessin
animé, où la forme peut changer à chaque image, on ne peut pas faire prendre n'importe
quelle position aux plaques. Par exemple, si la main a été dessinée ouverte, on pourra la
bouger en déplaçant le bras, mais il est impossible de la faire se fermer.

<footnote n="9">9. C'est-à-dire imprévues dans le système automatique, et à la charge des graphistes.</footnote>
Il a donc fallu trouver un moyen de permettre à une plaque donnée (par exemple, la main ou l'œil) de pouvoir prendre en cours d'animation plusieurs apparences différentes. Si on fait l'analogie avec l'animation *stop motion*, les mouvements généraux du corps correspondent au rigging, et les variations correspondent aux différentes parties interchangeables donnant une gamme de formes. On s'en sert pour faire cligner les yeux des personnages, ou pour la synchronisation labiale.

Dans Blender, ces variations prennent la forme de multiples plaques superposées et parentées au même os. Ainsi, si la main de notre personnage doit avoir trois positions différentes, mettons : ouverte, fermée et pouce tendu, chacune de ces positions est dessinée dans Krita. Au moment de l'import, le pantin se retrouve avec trois mains superposées. Un script* spécialisé permet de considérer ces trois mains comme des variations d'un même membre, et de n'en afficher qu'une à la fois. Les autres sont cachées automatiquement. Cela implique, d'une part, que ce système de variations soit exposé à l'animateur à travers une interface simple et claire, et d'autre part que la gestion de l'affichage des différentes plaques soit automatique.

J'ai implémenté ce système avec un système de *drivers* sur la visibilité des plaques. Lorsqu'on sélectionne le contrôleur de la main, une propriété s'affiche dans l'interface, qui peut prendre une valeur parmi le nombre de variations (dans notre exemple, 0, 1 ou 2). Lorsqu'on change cette valeur, la visibilité des plaques est mise à jour par le driver. Si l'animateur souhaite sélectionner la main fermée, dont l'indice est 1, il met la propriété à 1 et a l'illusion que la main a instantanément changé de forme.

L'intérêt de ce processus est qu'un nombre arbitraire de variations peut être ajouté, et que leur animation est aisée. Pour faire un clignement d'œil, il faut dessiner autant de positions intermédiaires que nécessaire et les parenter en utilisant le système de variations. Au moment de l'animation, il suffira de placer des clefs d'animation entre la première et la dernière position et le rig chargera automatiquement les plaques intermédiaires aux images correspondantes.
<figure><img src="image_17.png" /><figcaption>FIGURE III.3.10 – Comparaison de l'interface d'édition des variations colorées. À gauche, l'interface native de Blender, dans laquelle il faut créer pour chaque plaque les nœuds du matériau. À droite, l'interface simplifiée.</figcaption></figure>

Variations colorées

L'autre type de variation avait un but tout différent. Les rues de Paris dans le film devaient fourmiller de vie et montrer des personnages portant des robes de mille couleurs, littéralement. Pour éviter de dessiner autant de personnages différents, certains sont réutilisés plusieurs fois dans le film en changeant la couleur des vêtements. Pour ce faire, j'ai créé une interface rapide à utiliser (figure III.3.10), permettant de changer quelques réglages de couleur sur l'ensemble du pantin ou sur certaines parties seulement. L'interface consiste en un panneau exposant quelques réglages standard (teinte, valeur, saturation; gamma; courbe d'ajustement; recoloration). Ces réglages peuvent être modifiés pendant l'animation. L'approche (shading nodal) proposée par Blender pour réaliser ce type d'opérations offre une grande liberté, mais elle est beaucoup trop complexe et lente pour être mise en œuvre sur un grand nombre d'objets. Cette nouvelle interface, en sacrifiant toute la flexibilité du système de base pour se concentrer sur quelques réglages, s'appuie sur les capacités de Blender, et rend l'opération très simple
et presque instantanée.

### III.3.1.5 Publication libre

Des outils tels que ceux décrits ici sont fréquemment développés au cours d'une production précise pour alléger le poids d'opérations spécifiques. Leur développement est toujours complexe, car il faut trouver un équilibre entre un développement dans l'urgence, permettant de répondre aux impératifs du projet, et une élaboration plus réfléchie, permettant une réutilisation pour des projets aux contraintes différentes.

En publiant les outils sous licence logiciel libre, il est également possible de considérer leur utilisation par d'autres studios<fnref n="10" />, et donc de les rendre accessibles, documentés, supportés et génériques. À la fin de la production de *Dilili à Paris*, certains outils ont été directement publiés sous licence GPL (voir section II.1.3). Plutôt qu'une solution clef en main, chaque outil est utilisable indépendamment.

En revanche, pour l'outil d'autorig fondé sur Rigify, la publication a aussi eu lieu à l'issue de la production, mais de manière insatisfaisante, car il répondait à des contraintes de production précises et n'avait pas été rendu assez générique et facile à utiliser pour d'autres structures. Un travail ultérieur de publication a donc été entrepris. Il est détaillé dans la section II.3.3.4.

### III.3.2 Rendu

Le rendu (cf. section I.1.2.2) est une étape indispensable, puisque c'est à travers elle que sont générées les images qui figureront dans le film, ou du moins un matériau de base, qui sera corrigé, retouché et amélioré au compositing.

Les logiciels de création 3D* livrent en général un ou plusieurs moteurs de rendu intégrés, permettant de paramétrer et de lancer un rendu directement depuis l'interface du programme. Il existe également des moteurs séparés, dont l'exécution est indépendante.

<footnote n="10">10. De manière générale, une utilisation publique, qu'il s'agisse de studios ou d'artistes indépendants. Voir l'exemple de l'annexe C.</footnote>
Dans ce cas, une intégration peut être fournie pour, là aussi, lancer le rendu depuis le programme de création, ou pour exporter les données dans un format reconnu par le moteur.

### III.3.2.1 Types de moteurs existants

Plusieurs moteurs de rendu sous licences libres existent. On peut les répartir dans plusieurs catégories. La première est dédiée à la recherche sur les algorithmes de rendu. Parmi cette catégorie, on trouve Mitsuba et PBRT, qui est en fait un ouvrage pédagogique sur la conception de ce type de programmes, ainsi que l'implémentation d'un moteur en langage C++. Ces moteurs, quoique sérieux, ne sont pas conçus pour une utilisation en production pour de l'animation, et je n'en parlerai pas plus avant. La deuxième catégorie est celle des moteurs expérimentaux ou jouets, que leurs auteurs publient sous licence libre, mais sans réel support ou développement adaptés à une utilisation en production. Je n'en parlerai donc pas non plus. La troisième et dernière catégorie est au contraire celle des moteurs conçus pour la production, intégrés ou non aux logiciels de création.

### III.3.2.2 Moteurs utilisés par les Fées Spéciales

Parmi les nombreux moteurs de cette dernière catégorie, je me concentrerai sur ceux qui ont été utilisés dans les productions de la société où j'ai travaillé. Trois moteurs ont été utilisés, selon les besoins des productions, en particulier selon le style de rendu recherché. Ils sont tous les trois développés par les développeurs de Blender et intégrés à ce logiciel.

Il y a plusieurs raisons pour les avoir choisis. D'abord, c'est le choix par défaut. De la même manière que les utilisateurs de Maya ont longtemps utilisé Mental Ray car celui-ci était livré avec celui-là, les utilisateurs de Blender apprennent généralement les moteurs de rendu livrés avec, en même temps que l'utilisation de Blender lui-même. De plus, le fait que les moteurs soient développés par la même équipe garantit une com-
patibilité immédiate : dans le cas contraire, l'utilisation d'un moteur externe demande
le développement et la maintenance d'une passerelle entre le programme de création et
le moteur de rendu. Cette passerelle peut être faite par les développeurs du moteur, ou
au sein des studios. Par exemple, les développeurs du moteur AppleSeed fournissent des
add-ons* pour plusieurs logiciels de création. Certains moteurs comme Guerilla Render
(non-libre) choisissent de fonder le pipeline* de rendu sur des formats d'échange stan-
dard (Alembic). Cette option ne fonctionne donc que dans la mesure où ces formats sont
très bien supportés par le programme de création, ce qui n'était pas le cas de Blender
jusqu'à récemment.

Cycles : rendu réaliste

On peut distinguer grossièrement deux types de rendu dans les productions d'ani-
mation : photoréaliste et non-photoréaliste (cf. section I.1.2.2). Ces étiquettes sont mal
définies, mais elles sont utiles pour classer rapidement les moteurs. Dans ceux que nous
avons utilisés, le premier, Cycles, permet un rendu photoréaliste, mais lent. Il a par
exemple été utilisé par le studio Tangent Animation pour le long-métrage *Next Gen*,
sorti en 2018 et présentant des environnements stylisés, mais un rendu réaliste.

Cycles est un path tracer, une technique permettant d'obtenir un rendu d'un grand
réalisme, au prix de longs temps de calcul. La puissance de calcul atteinte par les or-
dinateurs au cours de la décennie 2010 a permis de rendre viable cette technique en
production. Du fait de sa nature parallélisable, elle peut notamment utiliser le rendu sur
carte graphique (GPU), qui la rend plus accessible, y compris aux petits studios et aux
indépendants.

Cycles est en développement actif par les développeurs de Blender, et a par exemple récemment intégré une option efficace de débruitage et la possibilité de paramétrer des AOV<fnref n="11" />.

<footnote n="11">11. Les *Arbitrary Output Variables* ou variables de sortie arbitraires permettent de rendre plusieurs shaders définis par l'utilisateur pour chaque image, pour les utiliser au compositing. Elles offrent une bien plus grande souplesse de travail, et de meilleures performances. La plupart des moteurs proposent cette possibilité depuis longtemps, mais je cite cet exemple pour montrer que le moteur évolue aujourd'hui à un rythme rapide.</footnote>
Les deux autres moteurs qui ont été utilisés sont Blender Internal et Eevee. Ils permettent tous deux, moyennant des efforts de la part des graphistes, d'obtenir des images assez réalistes, mais ils sont aussi mieux adaptés pour du rendu non-photoréaliste : ils sont plus rapides et offrent des possibilités de shading assez avancées.

## Eevee

Eevee a été utilisé pour un projet plus récent utilisant le Grease Pencil (cf. section II.3.1), du fait de son intégration avec la dernière version de Blender. Là aussi, l'utilisation était basique, d'une petite partie seulement de ses capacités. Le développement de ce nouveau moteur en 2018-2019 a été beaucoup attendu par la communauté d'utilisateurs, car il utilise les technologies issues du rendu temps réel des jeux vidéo pour créer des images de haute qualité, en un temps bien plus faible que les moteurs réalistes fondés sur le ray tracing (comme Cycles). Ces développements sont abordés dans la section II.3.1.

Eevee ne permet pas d'obtenir un résultat aussi photoréaliste qu'un path tracer, mais peut déjà être utilisé dans beaucoup de cas, y compris pour des projets relativement réalistes. Il peut aussi parfaitement servir pour faire des rendus rapides, mais donnant une idée assez fidèle du rendu définitif, au layout par exemple.

## Blender Internal

Blender Internal est un moteur de rendu ancien qui n'est plus supporté aujourd'hui car il a été remplacé dans la dernière version de Blender par Eevee. Il a été utilisé pour prévisualiser les séquences* layout de *Dilili*, et pour les animations du musée de Lodève. Dans ces projets, les besoins de rendu étaient assez simples, et il fallait principalement que les dessins et couleurs des décors et des personnages se retrouvent fidèlement dans le rendu.

Le fait que plusieurs moteurs de rendu de haute qualité soient disponibles et en développement actif ne laisse pas d'inquiétude sur la capacité des studios à les utiliser pour
calculer les images de leurs films. Bien qu'en 2019, certaines fonctionnalités importantes manquent aux moteurs de Blender <fnref n="12" />, ils sont déjà entièrement valables et assez stables et rapides pour les besoins modérés des Fées spéciales, et pour les besoins moins modérés d'un film comme *Next Gen*, ou des films de la Blender Foundation comme *Agent 327* et *Spring*.

### III.3.3 Compositing

Le compositing (cf. section I.1.2.3) est l'étape qui suit directement le rendu. Elle utilise les images générées par le moteur de rendu, les combine, les assemble, les retouche pour obtenir l'image finale. Les programmes doivent être capables d'une excellente gestion de la couleur, avoir de bonnes performances pour traiter rapidement de nombreuses images avec des effets parfois complexes et avoir un retour visuel aussi immédiat que possible. Ils doivent aussi, peut-être encore plus que les autres programmes de la chaîne de fabrication, être très stables, car il s'agit de la dernière étape de la chaîne de fabrication à proprement parler, et que les compositeurs doivent donc souvent travailler vite et efficacement pour compenser les retards accumulés en cours de production.

#### III.3.3.1 Logiciels prédominants

Il existe deux approches complémentaires du compositing : le compositing par couches, et le compositing nodal. Le représentant le plus répandu de la première catégorie est Adobe After Effects. Il est dédié à la fois au compositing pour l'animation et les effets spéciaux, et au motion design. Il est utilisé par une majorité des studios de graphisme. Son approche du compositing est unique, et permet une grande efficacité pour certaines tâches. Il n'existe pas aujourd'hui d'équivalent libre à After Effects.

L'autre approche du compositing, le compositing nodal, permet de visualiser le processus dans l'interface par des boîtes (les nœuds), et par des fils qui relient ces boîtes.

<footnote n="12">12. Par exemple, la gestion des layers et passes et les overrides par layer sont des fonctionnalités attendues depuis longtemps.</footnote>
Les nœuds sont des opérateurs de base (combiner des images, ajouter un filtre, modifier la couleur, etc.), et les images passent d'un nœud à l'autre via les fils. Ce type de représentation des données est très populaire, et la majorité des programmes de compositing l'utilisent en raison de son caractère intuitif, et de la facilité à réutiliser des opérations de base ou des combinaisons complexes d'un plan* à l'autre. Parmi les nombreux programmes de compositing nodal, le plus répandu actuellement est Nuke.

After Effects n'est pas prévu pour les mêmes utilisations que les logiciels de composi-
ting nodal, et malgré ses limitations (voir la note de bas de page de la section II.1.1.3), il
rend relativement simples certaines opérations qui seraient complexes avec des logiciels
comme Nuke.

### III.3.3.2 Natron

Plusieurs logiciels libres permettent de faire du compositing nodal. Initialement,
l'équipe des Fées spéciales a décidé, dans la logique d'utilisation et de développement de
logiciel libre, d'utiliser le logiciel Natron.

Il a été développé en France entre 2013 et 2017 par Alexandre Gauthier et Frédéric Devernay, avec un financement public de l'INRIA. Il s'agit en fait d'un clone de Nuke. Natron a depuis le départ copié l'interface devenue standard de Nuke, en s'appuyant sur un moteur nouveau et libre. L'idée derrière cette copie de l'interface<fnref n="13" /> était de faciliter l'adoption de Natron en fournissant aux utilisateurs une interface déjà connue. S'il manque beaucoup de fonctions avancées à Natron, il offre toutes les fonctionnalités de base d'un logiciel de compositing : gestion et conversion des formats d'image et vidéo ; gestion des espaces colorimétriques ; combinaison de passes, filtres, rotoscopie.

Nous avons donc utilisé Natron sur plusieurs productions, et n'avons pas eu de pro-
blème particulier avant de commencer les films sur l'Antarctique (cf. section III.1.2.2),
qui étaient en 4K (Ultra HD), une dimension d'image encore très lourde pour les ordina-

<footnote n="13">13. Il semble qu'une telle copie ne constitue pas une contrefaçon du moment que le but n'est pas de se faire passer pour le programme d'origine, mais d'utiliser son mode de fonctionnement pour être plus intuitif pour les utilisateurs. Dans certains pays dont la France ne fait pas partie, des éléments d'interface peuvent également être protégés par des brevets.</footnote>
teurs de 2016. Certains plans demandaient un compositing complexe, avec de nombreuses
passes. Nous n'avons pas pu savoir précisément pourquoi, mais Natron a montré ses li-
mites dans ces cas, et plantait systématiquement lors des rendus nocturnes des plans
composités dans la journée. Il va sans dire qu'il fallait relancer les rendus ratés, ce qui
ralentit forcément la production, puisque des humains doivent intervenir pour surveiller
les rendus, et que les images qui n'avaient pas été calculées une nuit mobilisaient des
ordinateurs dans la journée, ralentissant les performances et donc la productivité. De
plus, le programme n'était déjà plus vraiment supporté à l'époque. Le constat de ces
problèmes a poussé le chef compositeur à utiliser en urgence un programme qu'il connais-
sait bien, BlackMagic Fusion. Ce dernier est gratuit, mais non-libre. Il a été capable de
refaire le compositing dans ce programme et de rendre les images dans les temps.

Nous avons ensuite utilisé ce même programme sur plusieurs projets, toujours sous la
direction du chef compositeur. C'était une bonne décision pour la production, mais le fait
de ne pas avoir pu utiliser de programme libre pour des questions de stabilité a entraîné
des questionnements. Le développement de Natron, qui s'est arrêté peu après, en 2017,
avait stagné depuis un certain temps, et seules étaient publiées des corrections de bugs
majeurs. Il n'y a pas eu, dans les derniers temps, d'amélioration de performance et de
stabilité, ni d'ajout de fonctionnalités. En effet, la subvention de l'INRIA étant arrivée
à terme, les développeurs ont tenté de trouver un modèle économique en vendant du
support pour le programme, mais l'adoption n'était pas suffisante et, comme l'expliquent
les développeurs dans une interview [60], aucun nouveau développeur n'a été attiré vers
le projet, si bien qu'une fois les deux développeurs originaux partis pour d'autres projets,
personne n'en a fait la maintenance en 2019. Sans support, son utilisation serait téméraire
en production. On peut en conclure que le développement de logiciels libres ne demande
pas seulement des compétences solides de développement informatique, mais également
de la gestion d'équipe, de la communication, et même du marketing. Les projets qui
« réussissent », c'est-à-dire qui au minimum continuent d'être développés dans le temps,
sont ceux qui ont su fédérer une communauté, ou trouver un modèle économique pour
financer le développement. Cette question est abordée dans le chapitre chapitre II.2.
### III.3.3.3 Blender

Un autre programme libre permettant de faire du compositing nodal est, encore une fois, Blender. En effet, il existe depuis 2006 un module de compositing qui a été utilisé et développé pour les films de la Blender Foundation. Il permet lui aussi de réaliser les opérations de compositing de base, mais à la fois son interface, ses performances<fnref n="14" />, et son extensibilité sont critiquées.

En effet, beaucoup de logiciels spécialisés comme Nuke et Natron permettent d'utiliser de puissants plug-ins*, libres ou commerciaux, grâce à la bibliothèque* open source OpenFX. Ces plug-ins peuvent être intégrés dans plusieurs logiciels de compositing pour combler certains manques de fonctionnalités, et sont ainsi portables : même en changeant de programme, l'utilisateur peut continuer à utiliser les plug-ins. Ce système n'est pas intégré dans Blender, et la seule manière d'y ajouter des fonctions est de modifier un code source* à l'architecture compliquée. Cela pose des problèmes de maintenance si les changements ne sont pas acceptés par les développeurs dans le programme.

<footnote n="14">14. Par exemple, il est impossible en 2019 de calculer en une fois la séquence entière, et de la lire depuis un cache. Les images sont donc systématiquement recalculées lors de la lecture, même si elles n'ont pas changé. Le système ne prévoit pas non plus de versions proxy en plus basse résolution pour accélérer le rendu.</footnote>
# Chapitre III.4

## Post-production

### Introduction

La post-production intervient comme son nom l'indique après la fabrication et comprend plusieurs étapes permettant de finaliser l'œuvre animée. On fait parfois entrer le compositing dans la post-production. Il est indéniablement possible pour un studio en 2019 de faire certaines étapes en utilisant des logiciels libres.

Je me concentrerai donc dans ce chapitre sur l'étude de deux questions rarement considérées : d'abord, les lecteurs de vidéos spécialisés pour l'animation. Ensuite, les formats de fichiers demandés par les clients en vue de leur diffusion.

### III.4.1 Validation des images

En cours de production, il est nécessaire de regarder sans cesse les images fabriquées pour repérer les problèmes techniques et artistiques, les faire valider, ou simplement les voir dans le contexte de la séquence*. Pour faire ces examens, souvent appelés *reviews*, il faut un lecteur de séquences d'images et de vidéos.
Besoins spécifiques d'un lecteur vidéo pour l'animation

Un lecteur multimédia grand public comme VLC n'est pas adapté à cette application. En effet, il faut pouvoir charger des séquences d'images dans des formats de production, faire des allers et retours dans la vidéo de manière instantanée, défiler image par image, regarder plusieurs plans* à la suite, comparer des versions, examiner les passes dans des séquences d'images multi-passes comme OpenEXR, ou les couches (rouge, vert, bleu, alpha). Certains programmes permettent également de faire des annotations sur les vidéos, pour donner des retakes* aux graphistes. De plus, il est utile de pouvoir scripter le programme pour lancer automatiquement des séquences avec des paramètres complexes comme les numéros de plans, les variations à afficher, le mode d'affichage, etc. Il faut que le programme soit intégré au pipeline*, pour pouvoir communiquer par exemple avec le production manager, enregistrer les informations d'annotations, etc.

Si des lecteurs libres pour l'animation existent, comme DJV View, et si des palliatifs peuvent être envisagés, par exemple en écrivant un add-on* pour Blender, il existe un manque de ce côté, peut-être en raison du faible nombre d'utilisateurs experts ayant besoin des fonctions décrites, par rapport à la majorité des utilisateurs de logiciels libres.

### III.4.1.1 Développement d'une solution maison fondée sur des programmes libres

Dès le début de la production du premier projet de la société, le film *Dilili à Paris*, nous avons eu besoin d'un lecteur vidéo adapté. Nous n'avions pas tous les besoins énoncé plus haut, mais il nous fallait au minimum la capacité de regarder des séquences entières, et de comparer plusieurs versions, ce que n'offrait aucun lecteur libre par défaut. Pendant plusieurs mois, nous avons pour cela utilisé un script* écrit par Flavio Perez. Il s'appuyait sur des logiciels libres, disponibles dans notre distribution de GNU/Linux*<fnref n="1" />. Son utilisation nous permettait, en entrant une ligne de commande de la forme `play N` de jouer la séquence N. Le programme était chargé d'aller chercher dans l'arborescence

<footnote n="1">1. En particulier, l'outil en ligne de commande 'melt' fondé sur le framework MLT [58].</footnote>
de fichiers, les séquences vidéo correspondant aux plans*, et à les jouer dans l'ordre, en offrant à l'utilisateur la possibilité de passer d'un plan à l'autre par un raccourci clavier. Ce programme était donc très pauvre en fonctionnalités comparé à d'autres lecteurs : il n'y avait pas d'interface graphique, pas de timeline*, pas d'options de comparaison de version ou d'annotation, etc.

## Extensibilité

De plus, il fallait continuer à le développer, pour ainsi dire à le bricoler, à chaque fois qu'un nouveau besoin se faisait sentir. Par exemple, une étape primordiale lors de l'étape d'export vers Maya était de contrôler que le rendu issu de Blender et celui issu de Maya étaient identiques, et qu'aucune erreur de transformation, de couleur ou d'animation ne s'était introduite lors de l'import. De la même manière que pour la lecture consécutive, nous avons écrit un programme qui utilise la bibliothèque* FFmpeg pour générer une visualisation de la différence entre deux séquences vidéo. Une fois habitué à lire l'image résultante, cette méthode était relativement efficace : ce qui n'avait pas changé apparaissait en gris, le reste prenant une autre valeur ou couleur.

Afin d'obtenir ce qu'un lecteur vidéo avancé permet de faire en temps réel en une simple ligne de commande, ou en un clic si le lecteur est intégré au logiciel de suivi de production, il nous a fallu écrire un script qui transcode la vidéo plusieurs fois, la traite, l'enregistre de nouveau, puis ouvrir la séquence résultante manuellement. Malgré la satisfaction d'avoir écrit nous-mêmes ces outils, cela représentait à chaque fois un temps précieux.

En l'absence d'un lecteur libre intégrant toutes ces fonctions, ou des ressources nécessaires pour écrire notre propre lecteur, nous avons encore une fois acheté des licences du lecteur propriétaire RV, qui fait ce qu'on attend d'un lecteur de séquence en production.
## III.4.2 Livraison des masters

La dernière étape d'un projet audiovisuel est la livraison du master, les formats et supports qui seront diffusés et conservés par le client. Ces masters sont créés à partir des fichiers de montage du projet, en les exportant dans un format spécifié à l'avance par le client ou le diffuseur. Ce dernier précise généralement les demandes techniques concernant le format de conteneur, les codecs audio et vidéo, et leurs paramètres.

Lors de la livraison du projet Lodève (cf. section III.1.3), qui était un appel d'offre publique, les formats choisis étaient précisés dans le cahier technique des clauses particulières, transmis avant l'appel d'offre et stipulant les détails de mise en œuvre de l'exposition. Le document stipulait que les masters vidéo devraient être livrés soit au format MPEG2, soit non-compressés. Les sons seraient « au standard vidéo [...] ou MP3 ». Sachant qu'il n'existe pas qu'un standard en matière de vidéo, le document était plutôt vague. De plus, il restait suffisamment évasif pour que le choix évolue au cours du projet.

Ainsi, rien n'était véritablement demandé. Nous avons donc traité directement avec la société chargée de la prestation vidéo : matériel de diffusion, installation, programmation des serveurs de diffusion, etc. afin de choisir un format adapté au matériel. La question est épineuse, car le matériel en question accepte plusieurs formats, et en recommande même quelques-uns. Il n'y avait donc pas une réponse unique. Le technicien nous recommandait le codec H.264. Ce format est pratiquement le choix par défaut tant il est omniprésent en 2017. Quoique très polyvalent et efficace, il n'est pas clairement libre, pour deux raisons.

### Protection par les brevets logiciels

D'abord, sa spécification est en partie établie par un consortium d'entreprises qui ont pour but l'exploitation commerciale de cette technologie, et en contrôlent l'accès grâce à des brevets logiciels. Ces brevets logiciels n'ont pas cours en France, mais il n'en reste pas moins que le codec n'est pas libre dans toutes les juridictions, ce qui peut le rendre impropre à la diffusion dans certains pays.

Les droits d'utilisation de ces brevets concernent en principe tout utilisateur, que ce
soient les fabricants de matériel implémentant la technologie, ou les utilisateurs finaux.
Il semble [69] que la redevance ne soit pas réclamée pour les vidéos diffusées gratuite-
ment sur Internet, et il est peu probable qu’un procès ait lieu, simplement parce qu’un
prestataire a encodé une vidéo sans payer de droits.

Choix de l'implémentation

De plus, il existe plusieurs implémentations d'encodeurs et de décodeurs, certains
propriétaires et d'autres libres. Même si le format n'était pas protégé par des brevets,
il faudrait être vigilant sur le programme choisi pour encoder la vidéo. L'encodeur x264
est libre et fournit donc une solution à ce problème précis. Néanmoins, la question est
trouble, et nous aurions aimé pouvoir utiliser un format standard et libre, sans ambiguïté.

Cela nous a été impossible. En effet, nous avons obtenu un prêt de matériel afin
de tester nos vidéos encodées en conditions réelles. Nous avons essayé plusieurs codecs,
plusieurs conteneurs, et de très nombreux réglages afin d'obtenir un résultat visuelle-
ment fidèle (compression imperceptible), et une lecture fluide (rapidité de lecture du
fichier sur le disque, et vitesse de décodage), mais une combinaison de conteneur et de
codec libres telle que ogg + theora n'était simplement pas supportée, ce que confirme
la documentation de l'appareil. Nous avons donc utilisé le codec h.264.

Cette concession est faite presque universellement par les studios dans la livraison
pour certains médias de diffusion, sans même que la question ne se pose. Il a été inté-
ressant, justement, de la poser, et de constater que d'une part la réponse est inattendue
(l'utilisation de certains formats propriétaires est en principe illégale sans paiement d'une
redevance), et que d'autre part il est dans certains cas impossible de faire autrement.
# Chapitre III.5

## Outils transversaux

### Introduction

Le pipeline* (cf. section I.1.2), même s'il est difficile à définir précisément, est indé-
niablement important pour la fabrication au sein des studios d'animation. La troisième
partie de cette thèse s'est attachée jusque-là à décrire les possibilités d'utilisation et de
développement du libre dans chaque partie de la chaîne de fabrication. Ce chapitre pren-
dra une approche différente, en abordant les éléments du pipeline communs à toutes les
étapes. Le pipeline est ici compris dans son sens le plus technique, c'est-à-dire la struc-
ture invisible qui permet de fluidifier la fabrication, les échanges de données entre les
départements, et une vision plus globale et transversale de la fabrication, plutôt qu'une
étape précise.

J'aborderai dans ce chapitre deux domaines qui n'interviennent pas directement dans
le graphisme et les opérations réalisées par chaque département, mais qui sont néanmoins
indispensables. Le premier est le suivi de production et la gestion d'assets, pour lesquelles
il existe des logiciels libres performants, testés avec succès en production dans la société
Les Fées spéciales. Le deuxième domaine d'intérêt concerne les échanges de données entre
plusieurs programmes, et d'un studio à l'autre, et les développements nécessaires pour
pallier les manques des formats d'échange et de leur implémentation dans les logiciels
de création. Je me concentrerai en particulier sur l'exemple du film *Dilili à Paris* (cf.
section III.1.1).

### III.5.1 Logiciels de gestion de production et d'assets

Comme expliqué dans la section I.1.2.4, il est nécessaire pour une production d'animation de suivre efficacement les éléments en cours de fabrication ou de validation, les différentes versions et variations de ces éléments, les tâches terminées ou restant à faire et les graphistes auxquels elles sont attribuées, le calendrier et le budget de fabrication. Ces suivis sont effectués à travers deux types d'outils complémentaires, les logiciels de suivi de production et de gestion d'assets*.

Dans un article [29] publié par le groupe Le Pipeline<fnref n="1" />, le TD* Christophe Archambault développe le rôle de ces outils pour les studios, et en donne une liste succincte mais instructive. Parmi eux, il existe plusieurs solutions libres pour le suivi de production et la gestion d'assets. Je parlerai ici de deux logiciels libres, tous deux utilisés en production par les Fées spéciales, et au développement desquels la société a contribué.

#### III.5.1.1 Suivi de production : CGWire

Les logiciels de suivi de production permettent de faire l'interface entre les graphistes, qui fabriquent le film, leurs chefs d'équipe, et les chargés de production, qui s'assurent de la bonne avancée du projet. Il faut que le logiciel facilite la communication, en présentant les informations relatives au projet de manière claire et logique, et en permettant une saisie facile de ces informations, par les graphistes et les chargés de production.

#### Financement du développement

Sur ses premiers projets, la société Les Fées spéciales a développé un prototype d'outil interne, Criquet<fnref n="2" />. Il avait vocation à être développé plus avant, pour en faire une

<footnote n="1">1. Ce groupe de travail français est composé de professionnels du secteur de l'animation, travaillant dans des studios au poste de TD.</footnote>

<footnote n="2">2. Ce logiciel, utilisé pour le suivi de la fabrication de *Dilili à Paris* au sein des Fées spéciales, est détaillé par son auteur, Flavio Perez, dans [20].</footnote>
solution générique de suivi de fabrication, et diffusée sous licence libre. Une aide financière au développement avait été obtenue auprès du CNC*. En 2017, Les Fées spéciales ont eu connaissance du développement de CGWire, un logiciel aux fonctionnalités équivalentes développé dans la société du même nom par Frank Rousseau. La société a donc décidé d'adopter ce programme pour ses productions, et d'affecter le fonds d'aide au développement à son développement.

Il a été mis en production pour la première fois sur le projet Lodève, alors que le programme était encore jeune, et qu'il y manquait de nombreuses fonctionnalités, développées depuis avec le financement des Fées spéciales et d'autres studios. Le processus de développement du programme est décrit dans la section II.2.3.

## Fonctionnalités

Concrètement, CGWire est composé de plusieurs modules interconnectés. Zou, le serveur organisant la base de données et contrôlé par une API*; Gazu, un client Python pour les développeurs; et Kitsu, un client Web pour les graphistes et les chargés de production. Il offre les fonctionnalités attendues d'un tel logiciel : les graphistes peuvent voir un tableau récapitulatif des tâches qui leur sont assignées, et saisir pour chaque tâche le statut en cours et le temps qui y a été consacré. Ils peuvent ajouter des commentaires et envoyer la dernière version de la vidéo du plan*. Les chargés de production, de leur côté, suivent l'avancée des graphistes sur l'ensemble de leurs tâches, et leur assignent des tâches au fur et à mesure. Lors des réunions de validation avec les clients, les chargés de production peuvent préparer les plans à montrer, et les annoter des retakes* des clients, pour que les graphistes sachent ce qu'ils auront à changer.

Les fonctionnalités décrites sont donc standard pour un logiciel de suivi. Il est intéressant de noter qu'en raison du mode de financement du développement du programme, ces fonctionnalités sont développées au fur et à mesure que les utilisateurs, au sein des studios, en font la demande auprès de CGWire, et certains studios financent les heures de développement et ont donc la priorité pour la mise en œuvre de fonctions répondant à leurs besoins. Le programme étant open source, tous les utilisateurs bénéficieront de
ces améliorations en installant la version suivante.

## Licence et conditions d'accès

CGWire est proposé par son éditeur selon plusieurs modalités différentes, utilisant toutes le même code source*<fnref n="3" />. Le client peut d'abord souscrire à un abonnement, avec un hébergement sur les serveurs de CGWire<fnref n="4" />. Le client n'a pas besoin de s'occuper de l'installation et de la maintenance du programme et de la base de données. En contrepartie, il ne peut pas directement modifier ou étendre le code du programme, ni avoir le contrôle de ses données. Une autre possibilité, puisque le code est open source, est d'installer le programme sur sa propre instance, par exemple dans les locaux de l'entreprise. CGWire peut également facturer une assistance pour installer et faire le support du programme chez le client. Le logiciel est donc destiné aux équipes assez réduites, les petites et moyennes entreprises, voire les écoles d'animation.

Il est intéressant de comparer ces différentes modalités d'accès à celles du logiciel le plus utilisé en 2019 pour le suivi de production, Shotgun, édité par Autodesk. En effet, une production suivie avec Shotgun s'appuie également sur une base de données contenant les informations de suivi. Cette base de données est hébergée sur des serveurs distants appartenant à la société Amazon, et la licence utilisateur standard ne prévoit pas qu'un studio puisse héberger ou sauvegarder lui-même ses propres données. Le studio dépend donc de la disponibilité constante et à long terme de l'outil pour son activité.

### III.5.1.2 Gestion d'assets : Kabaret

Les gestionnaires d'assets sont des programmes complexes qui doivent pouvoir s'adapter à l'organisation d'un studio et des différents projets au sein de ce studio. Il existe

<footnote n="3">3. Certains développeurs de logiciels libres, comme par exemple le logiciel de dépôt de code et de développement collaboratif GitLab créent plusieurs versions, une version libre, et une version propriétaire commerciale, qui offre des fonctionnalités supplémentaires et dont les développements sont généralement reversés dans la version libre quelque temps après la version propriétaire.</footnote>

<footnote n="4">4. Ce modèle commercial est celui du *Software as a Service*, où le client loue un service au prestataire, qui héberge le logiciel et les données sur son propre serveur, en offrant une interface web pour s'y connecter.</footnote>
des solutions commerciales<fnref n="5" /> mais la plupart des studios qui travaillent sur des projets d'envergure développent leur propre outil interne.

## Approche modulaire pour les TD

Kabaret [43] est un framework* de gestion d'assets écrit par Damien Coureau au sein du studio Supamonks. Plutôt qu'une solution imposant une manière de faire ou une organisation précise, il permet de faciliter pour le TD* la tâche de décrire l'organisation de son studio, à travers l'implémentation de *flows* (cf. section I.1.2) : le workflow et le dataflow. Cela signifie que les TD peuvent utiliser Kabaret pour décrire n'importe quel pipeline*, et ne sont pas obligés de se plier à une façon de faire imposée par le logiciel. En contrepartie, ils doivent nécessairement faire du développement supplémentaire, car Kabaret n'est pas une solution clef en main. Cette approche est logique, du fait des spécificités de chaque production, y compris au sein d'un même studio.

Un grand nombre de variables est à prendre en compte lors de la conception du *flow*, et un pipeline devra nécessairement être adapté ce qui proscrit l'usage d'une solution toute faite. Parmi ces variables, on peut citer :

- le type d'œuvre (court ou long métrage, série, œuvre multimédia);

- le format (résolution d'image, durée, nombre d'épisodes);

- la technique (dessin animé, image de synthèse 3D);

- l'importance pour la production de chaque département (animation, effets spéciaux, compositing, etc.);

- les programmes utilisés;

- les données reçues des clients ou des collaborateurs extérieurs.

## Intégration dans les logiciels de création 3D

Le pipeline doit être solidement conçu par les TD, et facile à manipuler pour les graphistes. Par exemple, lorsqu'un opérateur crée une version d'un plan* sur lequel il

<footnote n="5">5. Par exemple, Autodesk édite également Tank, un logiciel de gestion d'asset censé être utilisé avec Shotgun, et intégré avec lui et les logiciels de création 3D*.</footnote>
travaille, il faut qu'il puisse renseigner facilement les informations de publication. Comme
la plupart des logiciels de gestion d'assets, Kabaret est écrit en Python avec Qt pour
l'interface, et il est donc relativement facile à intégrer dans beaucoup de logiciels de
création 3D<fnref n="6" />. Ainsi, le graphiste a moins d'étapes à réaliser pour publier son travail, et
la publication est une étape logique et intégrée à son processus de travail.

Kabaret est publié sous licence LGPL, une licence copyleft faible (cf. section II.1.3.1).
Il peut donc être inclus dans une application propriétaire sans que celle-ci ne devienne
copyleft. En revanche, toute modification de la bibliothèque elle-même doit être redis-
tribuée sous la même licence LGPL.

### III.5.2 Communication avec d'autres studios

Un critère important dans le choix d'un logiciel par un studio est sa capacité à s'intégrer avec d'autres logiciels, et éventuellement avec le pipeline* d'un autre studio, qui peut être complètement différent. Pour cela, il est parfois possible, lorsque les deux studios anticipent suffisamment, de se mettre d'accord en amont pour utiliser les mêmes solutions techniques. Mais cette solution est parfois impossible, notamment si le pipeline d'un des studios repose sur l'utilisation d'un logiciel particulier. Dans ce cas, il faut utiliser des formats d'échange, et développer des passerelles, c'est-à-dire des moyens de faire passer les données et métadonnées d'un studio à l'autre, en respectant leurs nomenclatures et processus de fabrication respectifs. Cette section abordera l'exemple concret du film *Dilili à Paris* (cf. section III.1.1).

#### Contraintes de projet : un pipeline complexe

Comme nous l'avons vu, la première tâche du studio sur ce film était le layout (cf. section III.2.2). Le pipeline* de fabrication du film était complexe, et faisait intervenir plusieurs studios utilisant des programmes différents. Les Fées spéciales travaillaient sur Blender, tandis que Mac Guff Ligne travaillait sur Maya. Je montrerai dans cette section

<footnote n="6">6. Blender est une exception majeure, voir section II.1.1.3.</footnote>
les développements qui ont dû être réalisés pour pouvoir échanger les données avec ce studio, en me concentrant sur le layout. Si le film avait été réalisé en 2019 plutôt que 2016, les solutions choisies auraient été différentes, car les programmes ont évolué entre temps. Néanmoins, les principes exposés gardent leur valeur générale, car il est toujours nécessaire de développer des passerelles dans une production.

Pour pouvoir collaborer avec le réalisateur Michel Ocelot et les équipes de Mac Guff, il a fallu, avant même le début de la production, communiquer avec le directeur technique du projet au sein de ce studio, Malek Touzani, pour établir un cahier des charges des formats d'échanges. Il fallait que nous puissions créer des fichiers contenant les indications nécessaires, et qu'ils soient capables de les traiter pour les intégrer à leur pipeline.

Les éléments à fournir étaient les suivants :

- caméras, dont :

- transformations,

- focale,

- animation;

- décors;

- personnages et accessoires animés;

- groupes contenant et séparant ces différents objets;

- bande-son;

- une nomenclature et des réglages particuliers pour les scènes.

## Transmission des données à l'autre studio

Afin que chacun de ces éléments soit transmis exactement selon leur forme validée par l'auteur, nous disposions de plusieurs possibilités. Nous aurions pu convenir d'un format d'échange standard, que nous exporterions et que Mac Guff importerait. Cette solution s'est avérée impossible à mettre en œuvre, car aucun format permettant de contenir fidèlement toutes ces données n'était disponible pour Blender. Le format d'échange Alembic, sorti en 2011 et largement adopté par l'industrie, était en cours d'intégration dans Blen-
der, et donc inutilisable. Or, c'est le seul format qui aurait pu éventuellement permettre de transmettre facilement et correctement l'animation. Mais il était trop tôt et nous ne pouvions nous appuyer sur ce format.

Le processus le plus viable pour nous prémunir de pertes de données était donc d'envoyer directement des fichiers au format Maya, utilisé dans le pipeline de Mac Guff. Cela implique évidemment de disposer au minimum d'une licence de ce logiciel non-libre. C'était le cas puisque le directeur technique des Fées spéciales, Flavio Perez, disposait d'une licence personnelle vieille de plusieurs versions mais encore compatible. L'intérêt de ce processus était de contrôler l'échange en s'assurant que toutes les données soient présentes à l'envoi. Cependant, le problème demeurait entier de les passer de Blender à Maya. Pour cela, nous aurions pu concevoir un format propriétaire unique à cette production, ainsi qu'un exporteur Blender et un importeur Maya. Une telle solution est irréaliste et surdimensionnée, sachant qu'il existe déjà des formats plus ou moins bien implémentés, mais offrant de nombreuses capacités. Ainsi, le format propriétaire FBX (cf. section II.3.2.1), maintenu par Autodesk, est vieillissant mais encore reconnu dans le jeu vidéo et l'animation. Il est mal documenté, instable, implémenté différemment dans tous les programmes, mais il a le mérite de convoyer facilement un minimum d'informations, notamment les hiérarchies d'objets, les maillages, les armatures, les animations, les matériaux. Le format a fait l'objet d'une rétro-ingénierie par les développeurs de Blender, qui fournit donc un exporteur.

Les personnages ont été modélisés à cette étape dans une version « RLO » (Rough LayOut), c'est-à-dire layout approximatif. Ce ne sont pas les modèles définitifs qui seront présents dans le film, mais des versions simplifiées, ayant juste assez de détail pour donner une idée juste de leurs taille et corpulence, de leur silhouette. De la même manière, ils sont riggés et animés relativement grossièrement.

### III.5.2.1 Format maison

Dès les premiers essais d'export, nous avons constaté que le format FBX était malgré tout insuffisant pour notre usage. En effet, outre certains bugs connus et faciles à corriger
faisant que les transformations étaient corrompues, l'animation squelettique (déformation du maillage) n'était pas supportée, ni certains réglages de caméra, les groupes, les séquences audio, l'animation de visibilité. Les clefs d'animation telles qu'exportées par Blender étaient également corrompues.

Au lieu de chercher à corriger un exporteur complexe vers un format non standard, nous avons estimé préférable de l'utiliser tel quel, mais de pallier ses manques en l'encapsulant dans un export maison. Cela signifie que notre exporteur préparait la scène, puis appelait l'exporteur FBX une fois par groupe d'objets (Layout, Pantins, Décors, Caméra, etc.). Chaque groupe se retrouvait donc dans son propre fichier FBX. Afin de coordonner ces différents fichiers, nous avons également utilisé des fichiers simples fondés sur JSON*, stockant des liens vers les FBX, le fichier audio, et différents réglages supplémentaires. Un exemple d'un tel fichier est présent en annexe A.

Cet arrangement permet non seulement de séparer les objets par groupes logiques, mais encore d'affecter à chacun de ces groupes des propriétés différentes. Par exemple, les décors ne nécessitent pas d'être animés, à l'inverse de la caméra. Les personnages 3D doivent conserver leurs animation et déformation, mais leur couleur est accessoire et donc pas exportée, contrairement aux décors. Ces différents réglages pouvaient être définis dans le format JSON pour chaque groupe. Des réglages supplémentaires étaient également écrits dans ce fichier, comme les images d'entrée et sortie du plan*, la résolution, l'animation de certains paramètres de caméra non supportés par FBX, etc.

### III.5.2.2 Export de la déformation

En s'appuyant sur le format FBX, nous connaissions d'emblée une limitation propre à ce format : l'incapacité à stocker les informations de déformation. Le rig des personnages ayant été fait dans Blender, il était aventureux de souhaiter exporter une animation squelettique (fondée sur un système d'armature) d'un programme à l'autre, en retrouvant *exactement* les déformations. Le plus simple dans ce contexte est d'employer un système de cache*. Une fois ce cache* réappliqué, l'animation peut être lue depuis le fichier, au lieu d'être calculée à partir de l'armature. Cette dernière peut donc à la
limite être supprimée. C'est une solution qui est souvent employée, entre deux étapes de production, pour garantir que l'animation ne soit pas corrompue ou modifiée. Par exemple, on emploiera ce système entre l'animation et le lighting, afin que les artistes éclairagistes n'aient pas à se soucier de questions de rig ou d'animation, mais puissent se concentrer sur leur tâche. Ce principe convenait parfaitement à notre situation, puisqu'il nous évitait de lutter pour rendre compatibles deux systèmes de conception très différentes : les rigs de Blender et de Maya.

Blender fournit dans un add-on* la capacité d'exporter un cache au format PC2, que Maya est de son côté capable de lire, en le convertissant dans son propre format MC (Maya Cache). Cette opération de conversion est incluse dans le script* d'import, pour que l'importeur Maya s'en occupe tout seul.

### III.5.2.3 Import dans Maya

Une fois les données de layout correctement exportées dans les différents formats, une procédure d'import doit être mise en œuvre dans Maya pour retrouver la scène à l'identique. On pourrait croire que cette étape serait triviale, comme l'import des fichiers FBX, mais en réalité des particularités du système d'import de Maya forcent à intervenir après l'export pour faire des corrections. Par exemple, les noms des objets étaient souvent corrompus. Les chemins des fichiers de textures devaient systématiquement être retouchés pour être reconnus par Maya. Les rotations étaient également tellement corrompues que nous avons décidé de les réappliquer systématiquement en écrasant la hiérarchie d'objets, pour ne plus se soucier des questions de parentage.

Plusieurs autres manipulations avaient lieu au moment de l'import, la plupart permettant de réappliquer les réglages propres aux différents groupes (Layout, Décors, etc.) exposés plus haut. Le fait d'automatiser cette étape permettait d'en profiter pour conformer les fichiers aux desiderata de Mac Guff en matières de nomenclature, de réglages de rendu, de résolution et de *framerate*, de format de rendu, d'unités, etc.

Une fois la scène correctement importée et vérifiée, il ne restait plus qu'à envoyer sur le serveur FTP de Mac Guff les dossiers Maya zippés, et à leur transmettre la liste des
plans* concernés. De leur côté, la production pouvait donc faire le suivi des échanges,
et la technique nous donner d'éventuelles retouches à faire sur les scènes.