04 mar. 2013

Pipeline de production : modélisation et animation 3D

3dsmax-logo.jpg

J'ai déjà abordé il y a quelques mois la notion de pipeline de production de jeux vidéo. Dans ce billet, je souhaite faire un arrêt plus long sur l'un des points déjà traité dans ce billet : la problématique liée à la modélisation 3D. Il y a une bonne raison à cela : le nombre d'artistes dans une équipe professionnelle ne cesse de grandir, et les nouvelles consoles qui vont débarquer d'ici la fin de l'année vont nécessiter des ressources supplémentaires de ce coté.

Avant de continuer, et dans un soucis de transparence, certains des liens présents dans cet article sont sponsorisés[1]. Ces liens sont affichés de cette manière : lien vers le site example.com. Comme vous pourrez vous en apercevoir en lisant ce billet, ça ne me fera pas changer de ton ni devenir dithyrambique.

Note

[1] deux raisons pour cela : d'abord, être contacté par un sponsor pour insérer dans un article des liens qui sont en rapport avec le sujet de l'article lui même, j'appelle ça de la chance. Ensuite, la migration vers mon nouvel hébergeur est un peu coûteuse - c'est donc un moyen efficace de limiter la facture.

Un rappel des faits

Dans le billet précédent (voir l'introduction) j'ai cité un nombre relativement important d'outils utilisés pour la modélisation 3D et l'animation. S'il est évident que certaines solutions peu onéreuses commence à bien s'implanter (notamment chez les développeurs indépendants), il n'en reste pas moins que le marché est principalement concentré entre les mains des vendeurs de solutions propriétaires - et pour cause : les logiciels propriétaires ont encore bien souvent une qualité et un ensemble de fonctionnalités bien supérieurs à leurs cousins Open Source (au premier rang desquels on place bien évidemment Blender). Ne me faites pas dire ce que je n'ai pas dit : les solutions Open Source offre un niveau de qualité exceptionnel - mais il faut être honnête : elles restent en retard par rapport aux ténors du marché.

Dans le but d'étudier plus finement les solutions mises en place par les studios de jeux vidéo, j'ai décidé de me focalisé sur l'un des logiciels de modélisation 3d les plus utilisé sur le marché.

Un petit rappel historique

Les données concernant l'histoire de ce grand ancien viennent principalement d'une série d'interview réalisées par le site web maxunderground. D'autres informations proviennent de l'article wikipedia concernant le logiciel.

3ds Max est le descendant de 3d Studio, un produit créé au tout début des années 90 par une équipe de développement nommée Yost Group (fondée par Gary Yost[1]) et déjà distribué par Autodesk. Ce produit, rétrospectivement nommé 3DS/DOS/r1 fonctionnait sous MS-DOS et a été développé par deux personnes. A l'origine, 3d Studio était vu par Autodesk plus comme un projet de recherche que comme un véritable logiciel dont il fallait développer la distribution. Devant le succès de cette plateforme logicielle, d'autres versions ont été développées - jusqu'à la version 3DS/DOS/r4 en 1994[2]. Parallèlement, la même année, un groupe de 4 personnes travaillait sur ce qui allait devenir 3ds max. Une nouvelle architecture logicielle fut mise en place pour dépasser les limites de MS-DOS[3], la nouvelle version étant destinée aux stations Windows NT (32 bits, multitâche préemptif).

L'un des points les plus importants de ce logiciel est le plugin Biped - permettant la création de pseudo-modèle d'animation. Le système Biped rend l'animation d'un personnage beaucoup plus facile à mettre en oeuvre - plutôt que de représenter un squelette sous la forme traditionnelle (un ensemble de vecteurs et de jointures fonctionnant comme des rotules mécaniques), le biped montre le squelette sous la forme de boites reliées entres elles par des articulations - une version extrêmement simplifiée du modèle 3d considéré. La mise au point de l'animation n'a plus à se faire en conjonction avec le modèle : il suffit de créer le biped et de l'animer indépendamment. Le temps gagné est double : d'abord, le travail est plus intuitif. Ensuite, l'animation et la modélisation peuvent être réalisés en parallèle par deux experts différents.

L'autre point fort du logiciel est son interface unifiée : les plugins et le système coeur sont intégrés dans la même interface, ce qui permet à l'utilisateur de perdre moins de temps à naviguer dans les différentes options proposées. Au final, le gain de temps est appréciable et peut être directement dédié à la modélisation ou l'animation elle même.

3ds max Release 1 a été démontré au Siggraph'95 et a littéralement écrasé la concurrence (à l'époque, principalement Alias Wavefront, qui venait d'être racheté par Microsoft). Le logiciel est sorti en avril 1996. On suivi d'autres versions - quasiment une par an - ainsi que différents changements de nom (de 3ds max, on est passé à 3ds Max, puis Autodesk 3ds Max). Aujourd'hui, le cycle de développement de ce logiciel est stable : il en sort une version par an ; chaque version affiche son lot de nouveautés. Les métiers sont adressés par cycles - architecture, entertainment, CAD[4]

Avec le temps, Autodesk a lentement cannibalisé ses concurrents les plus sérieux, jusqu'à absorber certains d'entre eux (Maya, Softimage). Aujourd'hui, Autodesk 3ds Max est l'une des solutions les plus utilisées dans le domaine des jeux video.

Le pipeline 3ds Max

Lorsqu'on parle d'intégration dans un pipeline de production, on parle en fait de deux choses différentes :

  1. l'intégration du pipeline dans un outil
  2. l'intégration d'un outil dans le pipeline

Les deux visions peuvent être utilisées en conjonction - et dans la plupart des cas, elles le sont : le premier point permet la construction statique de l'image disque finale, généralement sur un serveur dédié ; le second point, lui est utilisé principalement en cours de développement par toute l'équipe.

3ds Max est clairement orienté pour intégrer un pipeline externe - il est plus complexe (mais pas impossible) de l'intégrer lui dans un pipeline[5]. Pour ce faire, Autodesk fournit une API complète, permettant de développer n'importe quel type de plugins.

  • gestion de nouveaux formats de fichiers
  • intégration avec un système de gestion de versions
  • intégration d'un moteur de jeux complet
  • ...

Un plugin 3ds Max peut aller jusqu'à proposer de nouvelles fonctionnalités - tout en gardant une interface connue, puisque le SDK propose tout ce qu'il faut pour s'interfacer avec le coeur du programme, et notamment avec son système d'interface utilisateur. C'est d'ailleurs ainsi que sont développé la plupart des fonctionnalités nouvelles de 3ds max :

  • les différents moteurs de rendu (Mental Ray, iray, quicksilver...)
  • la gestion des matériaux - dont les textures procédurales Substance
  • l'intégration d'autres solutions Autodesk pour, par exemple, créer un personnage en 3d ou l'animer (sur ce sujet spécifique, on a déjà parlé du système biped).

Les différents niveaux d"intégration

Soyons fous : vous avez décidé d'acheter 10 licences de Autodesk 3ds Max, et vous souhaitez maintenant intégrer ce logiciel dans votre solution. Comme dit précédemment, même si ce n'est pas la seule l'option la plus simple va consister à intégrer votre solution dans 3ds Max. Votre travail peut se faire à plusieurs niveaux.

Scripts et plugins,

Il existe deux méthodes principales d'extension dans 3ds Max : un langage de script nommé MAXScript, et un SDK de développement de plugins.

MAXScript est plus que probablement puissant, et donne accès à la quasi-totalité de la plateforme. Arrivé à ce point, je pourrais dire "c'est votre solution de choix, vous allez vois, vous allez adorer". Sauf que non. Du point de vue d'un programmeur, MAXScript est à l'intelligence ce que la roue est à la tour Eiffel : ça n'a aucun rapport. J'ai bien essayé de comprendre la logique interne de ce langage, au point de douter qu'il en soit doté. L'aide est d'ailleurs assez explicite sur ce point[6] :

The layout rules for MAXScript code are unlike those of most programming languages.

En Français pour les non-anglophones :

Les règles de présentation du code MAXScript sont différentes de la plupart des autres langages de programmation.

Oui, merci, j'avais vu. Si je prends quelques exemples concrets :

a + b * c / d - e + f * g / h

a + b * c / d - e + f * g / h

a + b * c / d - e + f * g / h

Les deux premiers exemples sont corrects, et sont strictement équivalentes. Le troisième exemple ne fonctionne pas (erreur d'interprétation). La cause ? A défaut d'avoir un caractère de fin d'instruction (comme le ; en C), MAXScript parcoure la ligne qu'il lit jusqu'à la fin. Si la ligne est valide, alors il considère que la fin de l'instruction se trouve à la fin de la ligne (ce n'est pas illogique). Si en revanche il trouve en dernière position un token qui lui dit qu'il doit continuer l'analyse syntaxique, alors il continue à la ligne suivante. Dans le premier cas, pas de problème : l'expression est analysée jusqu'en fin de ligne. Dans le second cas, la fin de la première ligne est un opérateur, donc MAXScript essaie d'y rajouter la ligne suivante - ce qu'il arrive à faire. Dans le troisième et dernier cas, l'expression sur la ligne 1 est correcte, donc MAXScript la considère comme complète. Lorsqu'il essaie de parser la seconde ligne, il s'apperçoit que celle-ci est incorrecte.

On peut mieux faire...

Même s'il est puissant, la syntaxe générale du langage est assez affreuse. Je ne saurais trop conseiller aux personnes responsables de son développement de proposer une version améliorée, et correctement pensée - même les utilisateurs de 3ds Max préfèrent passer par un plugin tierce leur proposant un langage de script alternatif - python. Mais une telle solution n'est pas encore intégrée au coeur du logiciel, ce qui ne nous laisse qu'une autre possibilité : la création de plugins via les SDK C++ ou .Net.

Ce SDK est devenu, avec le temps, extrêmement complet. Il permet de s'interfacer avec toutes les possibilités offertes par le système : import/export de fichiers, système de rendu... En fait, un plugin 3ds Max peut être arbitrairement complexe, jusqu'à intégrer complètement un logiciel tiers : l'API Win32 est entièrement accessible - un pont a même été créé pour accéder à DirectX9 depuis 3ds Max. Certains exemples montrent même comment transformer 3ds Max en serveur COM ou comment l'interfacer avec un système de calcul distribué. Pour plus d'information, je vous conseille de vous référer à la documentation du SDK.

Dans les sous-chapitres suivants, je vais aborder certaines des fonctionnalités de ce SDK. Ne vous attendez pas à y trouver du code cependant - ce n'est pas le but de l'article (son but étant plus de vous présenter les différentes options qui s'offrent à vous pour intégrer 3ds Max dans votre pipeline - ou l'inverse, selon le cas considéré).

J'importe, j'exporte

Les plugins parmi les plus simples à développer consistent à réaliser l'import ou l'export de modèles 3D - complet avec leurs matériaux et leurs animations le cas échéant. Un tel plugin peut vous permettre de travailler avec un format de fichier autrement non géré par 3ds Max - qu'il soit imposé par une société tierce, ou tout simplement développé en interne pour coller au mieux à vos besoins[7].

Un peu plus complexe - tout en restant dans un cas simple : l'intégration avec un système de contrôle de version. Cette solution offre de nombreux avantages par rapport à un plugin d'import/export simple :

  • elle vous permet de centraliser vos assets dans un dépôt (local ou distant)
  • elle vous offre la possibilité de jouer avec les différentes version de vos assets
  • sur un dépôt centralisé, le partage du travail de vos collaborateurs est immédiatement partagé.

Le principe est similaire à la commande "Open from Vault" (elle même extensible via l'API proposée par le SDK) présente dans les versions récentes de 3ds Max, mais le but est ici de proposer un service similaire pour les types de fichiers autres que les types de fichiers supportés par 3ds Max. Histoire d'être complet sur le sujet, Vous pouvez vous inspirer de P4GT, qui ajoute un menu "Perforce" dans les outils dans lesquels il s'intègre (y compris Autodesk 3ds Max, jusqu'à la version 2012[8]). A noter que le SDK permet d'accéder aux menus standards de 3ds Max (y compris le ruban). Une bonne connaissance de l'API Win32 est ensuite requise si vous voulez modifier son comportement (par exemple faire en sorte que l'utilisation de la commande Open pointe vers la fonction correspondante dans votre plugin ; ce n'est pas nécessairement un bon conseil, mais sachez que c'est possible).

Si c'est possible, je vous conseille de stocker les modèles 3D sous une forme textuelle (en utilisant par exemple le format Collada). Cela vous permettra de mieux contrôler les fichiers eux-même et de pouvoir avoir un aperçu des différences entre deux modèles 3D en comparant les versions correspondante. Si les modèles sont stockés dans un format binaire, il consommeront un espace disque beaucoup plus important au final - et les différentes versions ne pourront pas être comparées l'une à l'autre de manière efficace.

Un point important : 3ds Max vous permet de créer des plugins d'import/export, mais ces plugins sont censés se limiter à l'importation et l'exportation de la géométrie - cela vous intéressera peut-être de gérer aussi les matériaux dont dépendent vos modèles 3D. Encore une fois, le SDK du logiciel vous permet de le faire, en s'interfaçant avec le système de gestion des matériaux (c'est notamment ce que fait le plugin Sharder FX). Pour ce qui est de la gestion avancée de ces matériaux, et notamment ce qui concerne les shaders, le SDK offre la possibilité de s'interfacer directement avec DirectX 9. Ce n'est certes pas suffisant à l'heure actuelle, mais les interfaces proposées peuvent être un point d'entrée intéressant.

Modifiers et consorts

L'un des intérêt de 3ds Max est la notion de modifiers. Ces modifiers sont des entités qui modifient le comportement du logiciel en ajoutant des fonctionnalités ou en modifiant un traitement standard. L'un des attraits de ces modifiers du point de vue de l'intégration dans un pipeline, c'est la possibilité d'ajouter et/ou de traiter des données liées au modèle dans l'interface de 3ds Max.

Il existe plusieurs types de modifiers :

  • modifier d'objets
    • modifier simple
    • modifier de géométrie
    • modifier de matériaux
    • modifier de sélection
    • modifier de topologie
    • modifier d'objet complet
  • modifier d'édition
  • modifier de l'espace-monde (WSM, pour world-space modifier)

Encore une fois, le SDK permet de créer de nouveaux modifier ainsi que l'interface utilisateur permettant leur manipulation. Dans le cadre de l'intégration dans votre pipeline, cette fonctionnalité offerte vous permet par exemple d'associer des méta-données à vos modèles 3D - par exemple des paramètres qui sont partagés avec votre moteur de jeux. Cela peut autoriser un artiste à contrôler lui-même des paramètres qui, autrement, ne seraient accessible que par l'API proposée par le moteur de jeu (et donc sous la responsabilité du développeur).

Les possibilités offertes en terme d'interface utilisateur ne sont limités que par Windows : il est tout à fait possible de créer ses propres contrôles intégrés dans un onglet du ruban de 3ds Max ou dans une page rollup.

Intégration du moteur graphique

La modélisation et le contrôle de vos modèles 3D sont deux points très importants pour votre pipeline et il est évident que l'intégration de ces deux parties est prioritaire. Il est une fonctionnalité supplémentaire qui, bien qu’optionnelle à ce stade, peut véritablement se révéler très utile : l'intégration du système de rendu complet de votre moteur de jeu dans 3ds Max.

Un moteur de jeu gère généralement plusieurs type d'informations - modèles 3D, sons et musique, modèle physique, IA, etc. Certaines de ces informations ne sont pas très utiles aux artistes graphiques, mais il en est une qui est importante : le sous-système graphique. Ce sous-système graphique permet de tester le rendu du modèle 3D dans le jeu, ainsi que son animation. Le fait que l'artiste soit capable de contrôler ses créations dans le jeu (ou dans un bac à sable) est très important, car cela lui permet de détecter au plus tôt des erreurs qui, sinon, peuvent n'être découverte que nettement plus tard dans le cycle de développement.

L'interface entre le moteur de jeu et 3ds Max est nécessairement un peu tendue. Dans sa version 2013, 3ds Max ne supporte que DirectX 9 - il faut donc tricher un peu si vous utilisez une autre API. Par contre, 3ds Max permet de créer des fenêtres indépendantes de complexité arbitraire - il est probable que l'une de ces fenêtres peut servir à contenir un renderer OpenGL ou DirectX 10/11. Vous pouvez aussi instancier un programme tiers, qui va communiquer ensuite avec 3ds Max pour récupérer les informations dont vous avez besoin.

En conclusion : aller plus loin

En guise de conclusion, je vais vous décrire une hypothétique solution d'intégration à un pipeline de production. Sachez que cette solution est en quelque sorte une solution idéale - mais coûteuse à mettre en place, principalement à cause du temps de développement nécessaire. Ceci étant dit, elle peut être modularisée pour être développée petit à petit.

  • Serveur distant - serveur de données centralisé : les données du jeu sont stockées sur un serveur dédié, avec pour seule interface un daemon (ou un service sous Windows) acceptant des connexions des différents utilisateurs. Ce serveur gère les versions des fichiers. Sur requête, un utilisateur peut demander la dernière version d'un fichier, ou une version antérieure. De la même manière, il peut demander la création ou la mise à jour d'un asset particulier. Un asset peut avoir deux états : publié (et donc rendu accessibles aux autres développeurs et artistes) ou non publié (inutilisable dans le moteur). Les données graphiques sont stockées sous une forme binaire (images, vidéos...) ou textuelle lorsque c'est possible (modèles 3D, description de matériaux, shaders...).
  • Client 3ds Max - Plugin de gestion des ressources : coté client, un plugin permet de s'interfacer avec le serveur de données. Il donne à l'artiste une vision user-friendly du dépot, et lui permet d'accéder aux différents objets qui y sont stockés. Le plugin permet le chargement et l'enregistrement de toutes les données liées à un modèle de manière intuitive.
  • Client 3ds Max - serveur de données décentralisé : ce plugin offre la même interface que le serveur centralisé, mais ne traite que les données qui sont chargées dans 3ds Max à un instant donné. Ces données ne sont visibles que localement. Ce serveur sert aussi de proxy pour accéder aux données stockées sur le serveur centralisé. Ce serveur local est intégré à un plugin 3ds Max afin qu'il puisse avoir accès aux données en cours d'utilisation de manière efficace.
  • Client 3ds Max - Plugin de rendu : le moteur de jeu est intégré dans le plugin. Une vue spécifique est donnée à l'utilisateur pour qu'il puisse tester son modèle, ses matériaux, ses animations... dans le contexte du moteur de jeu. Le plugin s'interface avec le serveur de données décentralisé pour accédé aux assets en cours de modification.
  • Moteur de jeu : la version de développement du moteur de jeu (elle peut être implémentée sous la forme d'un éditeur spécialisé) charge ses données via le serveur de données décentralisé s'il est instancié, ou via le serveur de données centralisé dans le cas contraire. Cela permet d'intégrer dans le jeu les dernières version des différents assets publiés[9]. Un mode de fonctionnement spécial permet l'édition des paramètres et options liés à un modèle disponible via le serveur de données décentralisé, voire de lancer/mettre en avant plan un outil graphique si nécessaire (Photoshop...) - par exemple pour modifier une texture ou les propriétés d'un matériau.
  • Serveur de build - toolchain de conversion : des outils spécifiques sont utilisés pour transformer les assets bruts publiés dans un format de données exploitable par le jeu final. En plus de la transformation, la toolchain peut aussi tester la validité des modèles, voire signer les fichiers générés ou les crypter.

Pourquoi cette architecture ? Tout simplement parce que c'est une des plus flexibles. Elle met 3ds Max au centre du travail de l'artiste, tout en lui simplifiant le travail en collaboration avec les développeurs et les autres artistes. De plus, les besoins de votre entreprise peuvent évoluer - et vous pouvez un jour décider d'utiliser une solution autre que 3ds Max. Si vous avez plusieurs équipes travaillant sur plusieurs jeux, vos environnements de développement peuvent être hétérogène, voire liés à une plateforme particulière. Les modules principaux de cette architecture (serveur centralisé, une part importante du serveur décentralisé, le moteur de jeu étendu, la toolchain de conversion) ne dépendent pas de l'outil de création de contenu digital que vous utilisez. Je vous engage à vous référer à cet article concernant la solution mise en place à Ubisoft Quebec.

Notes

[1] le Yost Group actuel n'est pas lié à Gary Yost ; c'est un groupe de recherche sur la spectrométrie de masse fondée par le professeur Rick Yost, de l'université de Floride.

[2] le succès a été tel que le format de fichier utilisé par 3DS/DOS a été pendant longtemps une standard de facto dans la scène démo. On trouve encore aujourd'hui de nombreuses librairies proposant la lecture et/ou l'écriture de ce format de fichier, pourtant antique et manquant de nombreuses fonctionnalités modernes

[3] qui, je le rappelle, était un pseudo-OS 16 bits, sans notion de partage de tâches

[4] chaque version apporte son lot de nouveautés pour chacun de ces domaines, mais les releases "spécialisées" ont tendance à proposer plus de nouveautés ciblées que les autres. D'après l'analyse que je fait des fonctionnalités nouvelles proposées, il semblerait que la version 2013 soit une version orientée "entertainment".

[5] la limitation principale étant le format de fichier natif .max

[6] je fais exprès de prendre la phrase hors contexte - c'est un procédé cruel, mais comme la phrase m'amuse... :)

[7] par exemple pour prendre en compte les spécifications hardware de votre plateforme cible ; j'ai vu le cas sur Playstation 1 : le format de fichier utilisé spécifique pour la plateforme proposait un nombre de vertex (x,y,z,u,v) divisible par 3 et paddé, car on lisait ainsi 64 bytes par 64 bytes à partir du lecteur optique et les performances étaient du coup optimales.

[8] au moment de la publication de cette article. Si vous lisez ces lignes en 2015, il y a fort à parier que la situation aura évolué d'ici là

[9] une latence est introduite dans le chargement des assets ; il faut prendre en compte ce point et architecturer le chargement autour de cette contrainte

Ajouter un commentaire

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

Fil des commentaires de ce billet