18 juin 2012

Petit détour par le pipeline de production

bodyZBrush02.png[1] Non, il ne s'agit pas d'écrire un article parlant de pétrole ou de gaz. Je souhaite juste, par cet article, revenir à l'une des source de ma passion dévorante pour le développement : les jeux vidéo.

Mais plutôt que de vous parler de programmation, je vais vous parler d'autre chose, moins connu - mais certainement plus important. Aujourd'hui, je vais vous parler de ce qu'on appelle dans le jargon pas si obscure du développement des jeux un pipeline de production, c'est à dire une suite d'outil permettant la création, la mise au point, et l'intégration de données (et de code, même si je vais sciemment laisser ce point de coté) dans un jeu vidéo.

Et vous allez voir, ce n'est pas nécessairement simple.

Note

[1] Image (c) 3D Training Academy

Et les données furent

Un jeu vidéo, comme tout autre programme, transforme une série de données stockées dans une forme spécifique vers une autre forme, paramétrée par ce qu'on appelle les entrées (entrées utilisateurs standard : clavier, souris, pad, caméra et autres capteurs ; mais aussi entrées en provenance du réseau). Ce qui fait la beauté graphique d'un jeu vidéo, ce n'est pas son moteur de rendu - c'est l'ensemble des données à traiter dont il dispose. Plus les données en entrée sont précises et bien réalisées, plus le rendu sera précis et agréable à l'oeil.

Ces données d'entrée sont de type très différents. Pour un jeu 3D de niveau commercial (autrement appelé jeu AAA, qu'on prononce triple A), on a :

  • des modèles 3D.
  • des textures - de plusieurs types.
  • des animations prédéfinies.
  • des procédures d'animation, permettant de générer un grand nombre d'animations différentes. Ces procédures peuvent exister sous forme de code intégré au jeu, ou sous forme de scripts réalisés par les animateurs.
  • des effets graphiques - encore une fois, ces effets peuvent être directement intégré dans le jeu sous forme de code ou exister sous forme de scripts.
  • des sons (musiques, voix, ...)
  • des scripts ayant traits au gameplay
  • des paramètres - permettant d'affiner la qualité graphique du rendu en fonction de telle ou telle configuration hardware

Il est évident qu'en termes de quantité, les données graphiques représentent la grande majorité des instances de données. C'est principalement vrai dans les jeux dont le graphisme est très fouillé (par exemple, le jeu Rage d'id Software nécessite près d'un Teraoctet de données non compressées, principalement à cause de la technologie utilisée. cf. cet article). Je vais donc me limiter pour l'instant à la partie graphique d'un jeu[1] - mais une analyse similaire peut être faite pour n'importe quel type de données intégrées dans le jeu final.

Dans le jargon propre au développement des jeux vidéo, on désigne les fichiers contenant des données sous le nom anglophone d'asset. Un texture est un asset, de même qu'un modèle, un shader, un ficher son, une musique, etc. Je vais utiliser ce terme très régulièrement par la suite - vous êtes prévenus.

Du bon choix des outils

Modélisation et animation

La modélisation (création des objets en 3D dans un logiciel spécialisé) est une partie très, très importante du pipeline de production d'un jeu vidéo.

Les développeurs indépendants ont tendance à utiliser des outils peu coûteux, en essayant de maximiser le rapport qualité/prix. A ce jeu là, il est évident qu'un outil comme Blender 3D (gratuit, disponible sous licence libre) est difficilement à battre. Il s'impose d'ailleurs petit à petit dans le domaine des jeux vidéo amateur, et s'intègre dans celui des développeurs indépendants. Il existe d'autres outils de modélisation gratuits de très bonne qualité, tels que Wings 3D (basé sur un principe de modélisation par subdivision).

Au niveau des logiciels propriétaires payants, la palme du "mais que faites vous ?" revient bien évidemment à Autodesk, qui, avec le temps, a développé et/ou racheté plusieurs logiciels de modélisation 3D régulièrement utilisés dans le domaine des jeux vidéo. A l'heure actuelle, ils proposent :

  • 3ds Max, principalement vendu comme logiciel de modélisation ;
  • Maya, markétté comme un logiciel d'animation ;
  • Softimage XSI, vendu comme un logiciel de création d'effets ;

Qu'on ne s'y trompe pas : ce sont bien 3 logiciels de modélisation, chacun avec ses forces, ses faiblesses.

Ces trois logiciels ont pendant longtemps été des concurrents directs dans l'industrie des jeux vidéo. Aujourd'hui, ils travaillent ensemble - sans offrir les mêmes fonctionnalités. On peut imaginer que lorsque les interfaces seront communes et que les fonctionnalités seront semblables, alors cette division un peu étrange disparaîtra, ne laissant plus qu'un seul de ces outils en vie

Outre le mastodonte Autodesk, on note quand même la présence de challengers de taille respectable :

  • Lightwave de NewTek, qui reste très utilisé dans le milieu de la production cinématographique, mais qui continue d'avoir des adeptes dans le monde des jeux vidéo.
  • Zbrush de Pixologic ; ses orientations "sculpture virtuelle" et "modélisation organique" en fait un atout de choix dès lors qu'il faut modéliser des créatures ou des personnages. Pixologic propose aussi le léger Sculptris, dans la même veine, mais qui a l'avantage d'être gratuit.
  • Modo, de Luxology. Luxology a été créé par d'anciens de NewTek. Après plusieurs années de développement, ils ont pu démontré Modo, qui a depuis été intégré dans le pipeline de nombreux studios (cf. cet article sur Wikipedia.

La plupart des outils de modélisation 3D assez avancés sont aussi capable de gérer un ou plusieurs systèmes d'animation. C'est en particulier le cas de toux ceux que j'ai cité plus haut. Le besoin le plus fréquemment exprimé est l'animation de créatures ou de personnages. Pour cela, certains outils se distinguent quand même de la concurrence ; ainsi, la gestion des bipèdes et (plus récemment) des squelettes de tout type dans 3ds Max est remarquable - non seulement de simplicité, mais aussi de puissance. Ce système, partie intégrante du plugin/outil MotionBuilder, simplifie très nettement la création et l'édition d'animations dans le cadre même de l'outil de modélisation.

biped du modèle Darrt, par Evan Smith

Sans entrer dans les détails, il y a animation et animation. Selon la portée du produit, sa complexité, le degré de réalisme demandé, plusieurs technologies peuvent être mise en oeuvre. Ces technologies vont du travail purement manuel à l'intégration d'animations capturées (via un système de motion capture). Si on souhaite utiliser cette dernière, il faudra que le logiciel utilise supporte non seulement les formats de fichiers en entrée, mais aussi les besoins liés à ce type de fichiers : squelette particuliers, outils spécifiques de repositionnement, etc. Car il n'est pas rare de devoir éditer un ensemble de frames en motion capture pour corriger l'animation ou l'adapter à un autre modèle 3D - les mouvements naturels changent avec la longueur des jambes, celles du torse ou des bras, etc.

Outre les logiciels de création assistée cité ci-dessus, il existe aussi des outils plus spécialisés, généralement composés de deux parties (un logiciel d'aide à la création et une librairie (middleware) d'exploitation) permettant la fabrication plus ou moins automatisée de certains assets.

Bien évidemment, on parle là de génération procédurale de contenu. Pour ce qui est de la prégénration de modèles, deux domaines particuliers sont généralement visés : la modélisation de territoires et de terrains (avec des outils comme Terragen de Planetside, Bryce de DAZ3D[2] ou Vue d'Esprit de E-on-software) et la modélisation de personnages et créatures (avec le gratuit/open source MakeHuman, ou encore DAZStudio de DAZ3D). Ces deux logiciels sont les héritiers en droite ligne du célèbre et très puissant Poser 3D de Smith Micro.

survivor3.jpg

Dans un premier temps, on va se rappeler que la définition procédurale temps-réelle n'en est plus à ses balbutiements. Aujourd'hui, grâce à des outils comme SpeedTree for Games[3], on peut retrouver dans les jeux actuels une flore entièrement générée de manière procédurale. C'est en fait l'un des domaines de recherche les plus anciens de la génération procédurale - les ''l-systems'' basée sur les théories de Lindenmayer et al. Les travaux de ce chercheur ont bien entendu ouvert la voie à de nombreuses autres applications, souvent centrées autour de la modélisation de la nature, mais pas uniquement. Ainsi, des outils comme le défunt Urban PAD (Gamr7), City Engine (ESRI, anciennement Procedural Inc.)[4] ou Suicidator City Generator sont tous basés sur le principe des l-systems, adaptés pour la modélisation en 3D de villes entières.

La génération procédurale d'animations a elle aussi bien progressé ces dernières années. Certains jeux intègrent leur propre solution (par exemple Spore, d'Electronic Arts ; c'est probablement l'un des exemples les plus connus, du à la notoriété de l'auteur du système d'animation : Chris Hecker est aussi l'homme qui popularisa les techniques de rendu de textures lors des tout débuts de la 3d interactive), d'autres font appels à des solutions telle que Endorphin de NaturalMotion, de plus en plus courant. Bien entendu, l'animation procédurale ne s'arrête pas à l'animation des corps ; la face des avatars est elle aussi traitée en profondeur avec EMotion FX (Mystic GD), FaceFX (OC-3) ou encore le récent et (osons le mot) révolutionnaire Speech Graphic. Ce dernier est capable d'effectuer automatiquement la synchronisation des lèvres avec un fichier son, sans aucune intervention humaine (si ce n'est la modélisation, qui doit obéir à certains prérequis, et l'enregistrement du son). Pour exemple,

Ce qui est intéressant, c'est de voir à quel point ces outils s'intègrent dans le pipeline de production classique : en fait, la plupart sont disponibles sous la forme de plugins pour l'un des grand modeleurs 3D du marché (3ds Max, Maya, ...). Il existe même certains plugins, plus limités en fonctionnalité, pour Blender (Suicidator City Generator étant un exemple connu).

Création de textures.

Une fois qu'on a notre modèle animé, il faut l'habiller. Un modèle de couleur uniforme n'aura que peu d'intérêt pour le joueur - il s'attendra plutôt à une foultitude de détails visuels même si, soyons honnêtes, ces détails ne sont pas là pour être vu, mais bien pour être là (dans le sens où ils ne sont pas admiré pendant des heures par les joueurs mais que leur absence serait par contre visible).

Création de la map UV (unwrapping)

La création de textures à appliquer sur les modèles 3D se fait en deux étapes. La première étape consiste à effectuer la projection du modèle 3D vers une image en deux dimensions - c'est une opération qu'on appelle unwrapping, ou création de la mal U/V (U et V font référence aux deux vecteurs orthogonaux formant la base de l'espace mathématique contenant la texture ; l'origine de cet espace est généralement un coin de la texture). La plupart des outils de modélisation professionnelles proposent leurs solutions - mais comme souvent, les perles sont à aller chercher chez les éditeurs tiers proposant des solutions innovantes basées sur les recherches les plus récentes. Le but de l'unwrapping est de créer une carte (map) qui une fois appliquée sur le modèle 3D minimise les distorsions de la texture. Cela se fait en s'assurant que les triangles présents sur la texture sont les plus proches possibles des triangles du modèles (angles et aire), tout en essayant de maximiser la zone utile de la texture et de minimiser le nombre de zones distinctes dans la texture.

L'exemple ci-dessous présente une texture très réussie de la tête de ce Superman. Il a été réalisé en 2010 par Steve Fabok dont le blog regorge de jolies choses.

SupermanHEadTextureMap.jpg

SuperFaceUVs.jpg

Il y a encore quelques années, unwrapper un modèle 3D, c'était ça. Pour ceux qui n'auraient pas le courage de cliquer sur le lien, l'auteur présente l'unwrap d'un modèle relativement simple, en 152 étapes (j'avoue : j'ai choisi l'article. Le nombre d'étapes est presque parodique. Mais en réalité, avant l'avènement d'outils spécialisés, les artistes ont utilisé des techniques similaires). Nul besoin de vous dire à quel point un tel travail est consommateur en temps. Si consommateur que l'industrie a été obligée de réagir, et on a vu apparaître des solutions spécialisées - qui sont peu à peu intégrées dans les outils de modélisation 3D. Cependant, ces outils sont quand même très en retard par rapport à ce qui se fait de mieux sur le marché (ainsi, très peu de choses sont automatisées dans 3DS Max.

Au niveau des outils gratuits - voire libres - on note la percée de RoadKill, basé sur un algorithme nommé ABF++ dont la première version a été publiée en 2001. Le logiciel lui-même ne semble plus être développé, mais il reste reconnu comme étant l'une des meilleures alternatives aux logiciels propriétaires. Son concepteur est un artiste professionnel (oui, les artistes peuvent coder), Francis David O'Brien aui possède une longue expérience dans l'industrie du jeux vidéo. Les outils intégrés dans les dernières versions de Blender se basent sur le même algorithme et proposent en plus un système de découpage simplifié, permettant à l'artiste de sélectionner les lignes selon lesquelles le modèle 3D sera découpé (voir cette page de présentation).

Du coté des outils propriétaires, on note que Unfold3D semble avoir fait son chemin. Le logiciel a récemment abandonné ABF++ pour utiliser un algorithme plus récent nommé ISOMAP. Le résultat est meilleur, dans le sens où la distorsion des triangle est réduite. Le logiciel offre en outre certaines fonctionnalités très intéressantes, comme la gestion de la densité des textures (permettant à l'artiste de choisir quelle sont les zones qui seront le plus détaillées) ou un rendu visuel des zones fortement distordues (qui tendent vers le rouge dans la capture ci-dessous provenant de l'ancienne version du logiciel).

Old_Unfold_Monster.jpg

Pixologic (éditeur du logiciel de modélisation ZBrush) a de son coté développé UVMaster. Ce plugin (gratuit) pour ZBrush propose une interface presque simpliste pour les artistes : le travail consiste à peindre directement sur le modèle pour que l'algorithme sous-jacent détermine de manière automatique certaines des caractéristiques de la map finale (par exemple, quelles sont les zones qui ne doivent pas être coupée ? quelles sont les zones où j'ai besoin de beaucoup de détails ? etc).

Cependant, l'un des standards sur le marché est (et ce depuis déjà quelques temps) le plugin Unwrella pour 3DS Max et Maya. Cet outil est entièrement automatique, tout en permettant un contrôle fin sur le résultat final (notamment, comme dans les solutions concurrentes, en permettant à l'artiste de placer les arrêtes là où il souhaite les voir), et en limitant au maximum les distorsions sur les textures obtenues. Unwrella lute dans la même classe que UVMaster - mais sa disponibilité sur les plateformes phares du marché (3DS Max et Maya) en font un atout de poids pour sa réussite. Le prix reste tout à fait acceptable (environ 150€ par licence pour un outil permettant de créer une texture en un click et une dizaine de secondes).

unwrella_home_01_xxl.jpg

Création graphique de la texture

Outre la création de la map U/V, si on souhaite un jour voire apparaître des motifs sur le modèle, il est nécessaire de créer une texture.

Il a y dix ans, une texture était quelque chose de simple : c'était une image qu'on s'efforçait de coller sur le modèle selon les informations disponibles dans la map U/V. Les techniques ont évolué - notamment grâce aux évolutions des cartes graphiques, et notamment à l'introduction de shaders programmables. Aujourd'hui, une texture est beaucoup plus complexe, et se compose généralement de plusieurs plans :

  • diffuse color: le graphisme en couleur de la texture
  • normal map: chaque pixel de ce plan particulier est en fait un vecteur normalisé représentant le vecteur normal à ce pixel particulier. On reconnait généralement ces textures à leur couleur dominante (bleu/violet). Voir aussi l'article correspondant sur Wikipedia.

nlinsample.jjpg.jpg

  • specular map: chaque pixel de cette image renseigne sur la façon dont la lumière est réfléchie à ce point.
  • height map : chaque pixel de ce plan de la texture représente une différence d'élévation par rapport à la surface du modèle 3D. On utilise par exemple cette map en conjonction avec la technique du displacement mapping ou avec des techniques moins lourdes (mais moins réalistes) telle que le parallax occlusion mapping
  • ambiant occlusion map : chaque pixel de ce plan représente la quantité de lumière reçue par l'éclairage ambiant (la lumière venant du ciel ; c'est une approximation qui considère que le monde autour de l'objet réfléchi la lumière plus ou moins fortement). On remarque ainsi que certaines zones du modèle 3D, uniquement dépendantes de la géométrie, sont en moyenne moins éclairées que d'autres. Cet article présente une façon d'obtenir ce type de map directement depuis le modèle 3D dans le logiciel Autodesk Mudbox).

comp_ao_map2.png

D'autres plans de la texture peuvent être ajoutées pour représenter les caractéristiques physiques de chaque point du modèle 3D. On peut ainsi imaginer une map gérant les caractéristiques physique des matériaux représentés (cuir, peau, ...). Tout ce qui est fonction de la position d'un point sur le modèle 3D peut être stocké dans une texture.

Ce n'est pas l'artiste qui fixe les types de textures à utiliser : c'est le programmeur. Car chacun de ces plans particulier nécessite du code spécifique - sans ce code, il est inutile de créer la texture correspondante - sans compter que le programmeur peut demander d'autres types de textures pour remplir des fonctions particulières.

Tout logiciel de dessin peut permettre de créer la texture diffuse. Bien évidemment, on préférera un logiciel qui permette la superposition de la map U/V, de manière à savoir où l'on dessine exactement. Logiquement, le ténor du marché se taille la part du lion dans ce secteur : Photoshop est très largement utilisé dans l'industrie, en particulier pour ses capacités d'édition bitmap inégalée à présent[5]. De nombreux plugins ont été développés pour générer des normal map à partir d'images existante ou à partir de height map.

Pour créer tout ce qui est normal map et height map, on utilise fréquement deux modèles 3D : le premier, en très haute résolution, est très détaillé (il peut contenir par exemple 100,000 à 200,000 polygones). Le second est le modèle qu'on va au final utiliser dans le jeu. Il est créé avec la même pose mais est beaucoup moins détaillé (on va viser entre 2 et 8,000 polygones). La height map est la différence entre ces deux modèles, ramenés à la même échelle.

Il existe des logiciels spécialisés dans la création assistée de textures à partir d'une image. On peut citer par exemple PhotoSculpt qui vous promet de réaliser toutes vos maps en quelques minutes, ou bien son concurrent plus professionnel B2M d'Allegorithmics[6]. B2M fait partie de l'écosystème Substance et a l'avantage de pouvoir s'intégrer directement dans le modeleur 3D utilisé - un gain non négligeable pour les professionnels du secteur.

Ces différents outils partent du principe qu'on va générer une texture soit en la dessinant, soit en utilisant une autre texture déjà existante. Mais il existe bien d'autres outils permettant de créer des textures, et en particulier des outils de génération procédurale des textures.

  • Substance Designer, d'Allegorithmics : en appliquant sur une description vectorielle des formes générales de la texture des modificateurs permettant de jouer avec les couleurs, les formes, etc., on peut créer une infinité de variations autour de la même texture. Ce logiciel peut s'utiliser seul, pour générer des textures sous la forme de bitmap, mais sa véritable puissance est liée à l'utilisation d'un middleware séparé à intégrer dans le moteur du jeu. Ce middleware est capable de rejouer en temps réel les définitions de textures créées avec Substance Designer pour en recréer les textures directement sur le GPU. Ainsi, pas besoin de distribuer des textures volumineuses : un simple fichier de quelques Kb suffit à recréer une texture très détaillée.
  • Filterforge part d'un principe similaire mais s'arrête à la génération de la texture. Le logiciel existe en version standalone ou sous forme de plugins Photoshop. Outre la possibilité de créer des textures à partir de rien, Filterforme permet aussi d'appliquer des effets intéressants sur des photos ou images existantes. Le logiciel donne en outre l'accès à une librairie assez gigantesque d'effets spécifiques créés par des des utilisateurs. L'exemple suivant est une application du filtre ''Chinese Ceramics'' de l'utilisateur Squideey.

9935.jpg

  • werkkzeug3, du groupe de démo Farbrausch (Wz3) est lui aussi assez similaire dans on principe, bien qu'il présente une interface graphique très différente où les modificateurs sont disposé sous la form de piles plutôt que présentés sous la formes de boites. werkkzeug3 a été pendant un temps un outils commercial destinés aux professionnels, mais ses performances commerciales ont été décevantes. En 2011, Farbrausch a placé tous ses outils sous une License de type BSD, en prévenant tout de même que les sources étaient livrés en l'état, et n'avait pas été nettoyés. L'arbre git contient même le code source de la 4ème itération du logicielle, qui n'a été utilisée qu'en interne par le groupe de démo allemand. A noter que Wz3 et Wz4 proposent d'autres fonctions, principalement orientées vers l'utilisation du framework de Farbrausch.

121.jpg

Ces trois logiciels utilisent un principe de fonctionnement similaires. A partir d'une source (vectorielle ou non), on applique une série de transformation touchant à la géométrie, aux formes ou aux couleurs des pixels de la source. Si la source est vectorielle, alors ces transformations sont indépendantes de la résolution (il est donc possible de créer de textures très haute résolution tout en conservant une finesse au pixel près).

Intégration dans le moteur de jeu

C'est probablement la partie la plus délicate du pipeline de production. Le moteur de jeu doit permettre le test des nouveaux assets de manière simple, et ce pour plusieurs raison :

  • vérification en cours de développement: on souhaite vérifier simplement que l'asset en question s'intègre bien dans le jeu.
  • mise au point: une vérification dans le jeu peut permettre de déceler des problèmes qui ne sont pas visibles dans l'outil utilisé, et donc de les corriger rapidement.

Cette intégration dans le moteur du jeu peut prendre plusieurs formes :

  • rechargement des assets dans le jeu ; sans quitter le jeu, on permet le rechargement dynamique de certains assets (à la demande du développeur, ou bien de manière automatique). C'est la technique la plus simple, et elle permet déjà de bien simplifier le développement - dès lors que le jeu peut être "mis en pause" d'une manière ou d'une autre, afin d'arrêter la simulation et de garder le jeu en tâche de fond pendant le développement des assets. C'est aussi la technique la moins coûteuse et la moins risquée par rapport aux deux autres techniques présentées ci-dessous - parce que le code est relativement simple à mettre en oeuvre.
  • intégration du moteur dans l'outil utilisé ; cette technique se retrouve assez fréquemment dans l'industrie du jeu vidéo. Il s'agit de développer un plugin pour l'outil en utilisant le même code que celui du moteur du jeu, de manière à pouvoir manipuler l'objet dans le jeu directement sans avoir à lancer celui-ci. Généralement, on met au point une scène représentative du jeu, qui est chargée et affichée avec le plugin. Le problème principal ici est que toute modification du moteur du jeu entraîne une modification du plugin. Un autre problème est que le changement d'outil impose le re-développement d'un plugin spécifique. D'un autre coté, l'avantage principale est que la solution est relativement légère et finalement "peu" coûteuse par rapport à la solution qui suit.
  • passerelle entre l'outil et le jeu ; du code spécifique, ajouté au jeu, se combine avec un plugin spécifique pour permettre le chargement - et le rechargement en cas de modification dans l'outil - de l'asset en cours de développement. Idem, certaines propriétés de l'asset peuvent être directement éditée dans le jeu, et les modifications ainsi apportées sont directement appliquée dans l'outil de développement. Cette solution est coûteuse et difficile à mettre en place, mais offre l'énorme avantage de pouvoir tester les assets en situation réelle. Bien évidemment, cela nécessite un développement lourd coté moteur ainsi que la mise au point d'un protocole pour transmettre les données de l'outil vers le jeu (et vise versa). Parmi les fonctions à prévoir :
    • replay et playback d'une partie du jeu définie ;
    • import et export des données en provenance (et en direction) de l'outil sélectionné ;
    • modification d'une partie des données dans l'environnement du jeu.

Bien évidemment, ces trois techniques sont complémentaires. On peut par exemple utiliser la première technique pour recharger les modifications effectuées par d'autres personnes et stockées dans un gestionnaire de versions. La seconde technique est utilisée pour effectuer des cycles rapides de prototypage. Enfin, la troisième de ces techniques est mise en place pour faire une mise au point fine des assets réalisés (à noter que cette technique etait utilisée par Ubisoft Quebec en 2008 ; il est fort probable, vu l'investissement, qu'elle soit toujours utilisée de nos jours ; cf. mon compte rendu de conférence sur le sujet).

Création du produit final

L'intégration s'est passée comme un charme ; mais l'asset n'a toujours pas sa forme finale, compressée et optimisée.

C'est le rôle de la dernière étape du pipeline. Régulièrement, un ensemble d'outils (complètement intégrés à la chaîne de construction) prend les dernières versions non compressées des différents assets, effectuent des vérifications supplémentaires[7] et les compile de manière à obtenir des versions optimisées pour une plateforme spécifique.

En intégrant la chaîne de construction dans un système d'intégration continue, on peut savoir quelle modification pose problème, qui l'a effectué, et prévenir cette personne directement.

Le mot-clef important dans cette partie est la notion de plateforme spécifique. Certains formats de stockage pour certains assets particuliers peuvent nécessiter des adaptations en fonction des plateformes[8]. Outre les classiques problèmes d'optimisation, on peut aussi devoir prendre en compte des problèmes liés à l'architecture matérielle (par exemple, l'endianness du processeur). Du coup, il est utile de prévoir des petits outils capables d'adapter les fichiers générés en fonctions de la cible souhaitée.

Coût final (et conclusion)

Vous le voyez, développer un jeu (ou un moteur de jeux vidéo), ce n'est pas seulement écrire quelques milliers de ligne de code. C'est aussi prévoir, acheter ou implémenter les outils nécessaires à la création et à la maintenance des assets. Bien évidemment, les besoins vont varier du tout au tout selon la taille des équipes concernées et leur organisation. Par exemple, une entreprise fonctionnant un mode client fournisseur (l'équipe de production fais ses demandes aux équipes artistiques, qui fait son travail, puis livre une solution finale) n'aura pas nécessairement besoin d'un haut niveau d'intégration des outils ; idem pour une société passant par des prestataires externes pour créer une partie des assets (de nombreuses entreprises proposent ce type de service) ; une équipe de 4 personnes pourra certainement se satisfaire d'un pipeline moins complexe, mais aussi beaucoup moins cher.

Le fait est que plus le pipeline de production est complet et efficace, plus il coûte cher à développer, à mettre en place et à maintenir. Bien évidemment, il permet aussi de réaliser des économies - notamment sur le temps de développement effectif. Le calcul auquel il faut se livrer est simple : est-ce que le coût de mon pipeline est amorti sur la période de développement choisie ? Dans le cas de grosses sociétés telle qu'Ubisoft, la période de développement est par définition infinie - tant qu'il y a des jeux à faire, le pipeline vit. Mais pour une équipe d'indépendants travaillant sur un jeu pour mobile, les coûts de mise en place d'un pipeline complet sont prohibitifs.

Prenons un exemple un peu idéal, pas vraiment représentatif - mais qui vous donnera quand même une bonne idée de la problématique. En admettant que, par jour, sur 20 artistes (musiciens, graphistes, ...), chacun économise 30 minutes de travail improductif, et que mon développement va durer 2 ans, le calcul est simple[9] : il ne faut pas que mon pipeline me coûte plus de 170,000€ sur la même période de deux ans. Ce coût maximum est composés :

  • des coûts de licence pour les logiciels utilisés
  • des coûts liés au développement supplémentaires accompagnant la mise en place
  • des coûts liés à la maintenance du pipeline (correction de bugs, améliorations, nouvelles fonctionnalités, suivi,...)

A 170,000€, et en supposant que j'ai près de 100,000€ de licences (rappel: 3DS Max 2013 débute à 3,900€ HT), il ne me reste que 70,000€ à dépenser en développement - soit environ 250 jours-homme (un peu plus d'un an-homme) à répartir sur les deux ans. En doublant le nombre d'artiste, je vois que je peux me payer le luxe d'avoir une personne à temps complet pour travailler sur la problématique du pipeline. Économiquement, on voit vite qu'un ensemble de studios comme Ubisoft (6700 employés) a tout intérêt à avoir une équipe complète pour gérer cette problématique : les économies réalisées sur les développements sont alors substantielles.

Notes

[1] et encore, je ne vais même pas tout traiter...

[2] accéssoirement, je signale que la suite DAZ3D, contenant tous les programmes 3D de DAZ, l'éditeur de Bryce, est gratuite pour une temps limité

[3] anciennement SpeeTree RT

[4] la version présentée par ESRI est semble-t-il essentiellement destinée à des applications qui ne sont pas des jeux vidéo ; mais l'ADN de City Engine est définitivement enraciné dans cette industrie

[5] Même s'il est impressionnant dans sa version 2.8, The Gimp n'est pas encore un rival de Photoshop, quoi qu'on en dise

[6] Allegorithmics et l'éditeur de PhotoSculpt sont deux sociétés françaises, au cas où cette précision peut vous aider à faire un choix

[7] c'est nécessaire, car certains artéfacts ne sont pas visibles à l'oeil nu ; par exemple, deux vertices qui devraient être superposés ne le sont pas, etc.

[8] j'ai moi-même vérifier ce point il y a fort longtemps, lors de mon permier stage ; je travaillait alors dans l'équipe outil d'un studio de développement parisien aujourd'hui disparu. Notre développement ciblait deux plateformes : PC (à l'époque, Windows 95 + DirectX 5) et la première Playstation. Nous nous étions rendu compte que sur PS1 la lecture et l'interprétation des modèles 3D contenus sur le CD était plus rapide en lisant un nombre particulier P de float d'un coup, plutôt que de les lire un par un où tous en une seule fois. Du coup, le format de fichier 3D a été adapté pour stocker un nombre de float toujours multiple de P.

[9] on suppose qu'une journée (de 8 heures) a un coût total d'environ 250€ par salarié ; ça prends en compte le salaire chargé (50,000€ brut chargé par an), l'espace occupé au sol (9m2 x 900€/m2/an), le matériel renouvelé régulièrement ou loué (1,500€/an), la part administrative correspondante au fait que le salarié existe (salaire des administratifs / nombre de salariés), etc.

Ajouter un commentaire

Les commentaires peuvent être formatés en utilisant une syntaxe wiki simplifiée.

Fil des commentaires de ce billet