Introduction
C’est en plein mois d’août lors de la désormais traditionnelle QuakeCon que John Carmack a présenté le prochain projet d’id Software : Rage. Si peu de choses sont connues sur le jeu qui semble particulièrement peu avancé dans son développement, le directeur technique d’id Software a profité de sa présentation pour donner quelques détails sur le moteur 3D qui animera le jeu. Finis les Doom et autres Quake engines, le nouveau moteur s’appelle id Tech 5 et la firme texane a au passage rebaptisé tous ses précédents moteurs selon cette nomenclature : id Tech 2 pour le moteur de Quake 2, id Tech 3 pour le moteur de Quake III et enfin id Tech 4 pour le moteur de Doom III (et ses mises à jour, notamment celle utilisée par Quake Wars).
Maintenant que nous avons eu un peu de temps pour assimiler toutes les informations révélées lors de cette QuakeCon nous avons pensé qu’un petit bilan de toute la technologie qui se cache derrière id Tech 5 ne serait pas superflu.
Rage, le jeu
Avant de nous pencher sur la technologie réservons quand même ce paragraphe à la présentation du premier jeu sensé l’illustrer : Rage. Rage a la lourde tâche d’être la première nouvelle licence venant d’id Software depuis plus de dix ans, époque à laquelle Quake est sorti. Et le moins que l’on puisse dire c’est que ce fut douloureux pour la firme texane. En effet, on sait déjà qu’après Quake III id Software a pendant un moment travaillé sur un nouveau jeu baptisé Quest avant que le projet ne soit abandonné, la firme (enfin essentiellement John Carmack) préférant se consacrer à Doom III.
Et l’histoire se répète : en 2004 Doom III vient tout juste de sortir, Carmack commence à travailler sur la technologie de son prochain moteur pendant que le reste de l’équipe est occupé par le portage Xbox. Le jeu basé sur cette technologie est alors appelé Darkness, pendant un an id Software travaille sur ce projet avant de décider dans un éclair de lucidité qu’un nouveau FPS se passant encore dans des couloirs sombres était peut être un peu redondant. La firme entre alors dans une phase de brainstorming au cours de laquelle plusieurs idées sont lancées et notamment celle de pouvoir utiliser des véhicules pour se déplacer dans des paysages post apocalyptiques immenses. Rage était né.
Pas de panique toutefois, id Software n’abandonne pas complètement sa formule classique, on retrouve donc des passages avec des flingues et une vue à la première personne. Le jeu prend peu à peu forme autour d’un univers ouvert dans lequel vous pourrez accomplir des missions comme bon vous semble, au milieu desquelles se déroulent des courses de buggys. L’argent que vous gagnerez dans ces courses pourra être réinvesti dans des boutiques pour acheter des armes ou améliorer votre véhicule.
Inutile de s’attarder plus longuement sur le jeu vu ce qu’id Software a révélé jusqu’ici, si vous souhaitez vous faire votre propre idée n’hésitez pas à vous rendre chez nos collègues de JeuxVideoPC.com pour télécharger la vidéo du trailer si ce n’est déjà fait.
id Tech 5, la technologie
Intéressons nous maintenant au tout dernier moteur de John Carmack, mais pour commencer en douceur avant de parler de MegaTexture, virtualisation, shaders et autres Shadow Maps, attardons nous quelques instants sur le nom de ce moteur : id Tech 5. En effet il marque un changement de politique chez id Software peut être plus profond que ce que l’on peut penser au premier abord. Jusqu’ici tous les moteurs maisons de la firme texane étaient baptisés en fonction du premier jeu à les avoir utilisé. Pourquoi donc ne pas avoir baptisé ce moteur Rage Engine ? Parce que cela posait plusieurs problèmes. Tout d’abord RAGE est le nom du moteur de Rockstar (Rockstar Advanced Game Engine), et comme si cette raison n’était déjà pas assez rédhibitoire il faut aussi ajouter que ce n’était sans doute pas judicieux d’un point de vue marketing.
En effet appeler des moteurs Doom III ou Quake III Engine ne posait aucun souci vu la célébrité de ces licences et le fait qu’elles étaient intimement liées à id Software. Mais Rage comme nous l’avons vu peut faire référence à beaucoup de sociétés dans le monde du jeu vidéo : on a déjà cité l’exemple de Rockstar mais il y a aussi une ancienne société appelée Rage Software célèbre pour ses benchmarks jeux Incoming ou Expandable.
Rage Engine étant donc hors de question comment appeler ce moteur ? Le choix s’est donc porté sur id Tech 5 qui a le mérite d’être clair : il s’agit de la cinquième génération de la technologie d’id. Cette numérotation rend aussi les choses plus explicites pour les futurs acheteurs potentiels : il est désormais évident de déterminer la dernière version des moteurs id Software, comme chez leur concurrent direct Epic.
La concurrence
Puisque nous évoquons le sujet, parlons justement d’Epic dont la montée en puissance de ces dernières années a semble-t-il influencé id. Il faut dire que Tim Sweeney et sa bande ont parfaitement su gérer les choses, ils sont arrivés exactement au bon moment, juste avant la nouvelle génération de consoles, avec la bonne technologie (orientée Shader Model 3.0) et surtout le bon discours. En effet en 2004 lorsqu’Epic fait sa première démonstration tous les éditeurs ont les yeux rivés sur les Xbox 360 et PS3 dont l’arrivée approche et effraie aussi. On ne parle que d’une explosion du budget des jeux et d’une complexité de programmation accrue à cause des architectures multi-cores.
Et voila que déboule Epic avec un moteur qui semble résoudre d’un coup de baguette magique tous ces problèmes. Et ils n’économisent pas leurs efforts : en 2005 ils sont partout, pour présenter Gears of War sur Xbox 360 ou encore faire une démonstration d’Unreal Tournament sur PS3 qui tourne déjà étonnamment bien en exploitant pourtant uniquement le PPU. En face de ça id Software ne peut pas lutter : le moteur de Doom III qui vient de sortir ne connaît pas le même succès. Arrivé entre deux générations il est trop lourd pour la Xbox et pas adapté aux nouvelles consoles vu qu’il n’est pas threadé et utilise peu les shaders. De plus ses outils semblent archaïques comparés à ceux de l’Unreal Engine.
L’Unreal Engine connaît donc un engouement sans précédent et en l’absence de concurrence digne de ce nom s’impose comme LE standard de fait auprès de la plupart des éditeurs, mêmes les plus improbables comme Sega, EA (pourtant propriétaire de Criterion et de ce fait du moteur Renderware) et même Square Enix ! La plupart des studios vont cependant vite redescendre sur terre : le moteur est loin d’être aussi magique que Mark Rein ou Tim Sweeney le laissaient entendre. En particulier malgré les efforts du marketing pour vanter ses capacités multi-plateformes, l’Unreal Engine 3 est avant tout un moteur qui a été conçu avec le PC à l’esprit et le passage sur console n’est pas aussi aisé que prévu. Ainsi Epic tarde à fournir le renderer multithreadé, Gemini, indispensable pour tirer profit des dernières consoles et de leurs processeurs multi-cores.
De plus malgré la démonstration encourageante en 2005 le moteur a des problèmes à être adapté à la PS3 et à son architecture particulière. La plupart des studios multi-plateformes sont donc contraints de repousser la version PS3 de leurs jeux. Face à cette situation Sony est même contraint de dépêcher une équipe dans les locaux d’Epic afin de les aider à exploiter au mieux le Cell. Enfin dernièrement la firme a bénéficié d’une publicité dont elle se serait bien passée : déçu par le moteur et considérant que les promesses initiales n’avaient pas été respectées, Silicon Knight s’est engagé dans une procédure judiciaire contre Epic.
Des objectifs ambitieux
Pendant ce temps id Software travaillait en silence. Conscients des carences du moteur de Doom III mais aussi des limites de l’Unreal Engine 3, ils ont conçus id Tech 5 autour de plusieurs points essentiels. Le premier concerne la portabilité. A l’inverse des moteurs précédents d’id Software ou d’Epic, id Tech 5 a été conçu dés l’origine pour tourner sur PC/Mac mais aussi sur la PS3 ou la Xbox 360. Les GPU de ces deux consoles rendant les choses plus aisées puisqu’il s’agit essentiellement de dérivés d’architectures PC. L’objectif était donc de pouvoir faire tourner le jeu dès les premiers pas du développement sur l’ensemble des plateformes, pas question de finir la version PC et ensuite de devoir tout reprendre pour essayer d’adapter ça aux consoles de dernière génération. Pour parvenir à un tel résultat id Software s’est donné les moyens en embauchant notamment Jon Olick, un ancien de chez Naughty Dog. Spécialiste du Cell, Olick a en particulier travaillé sur un ensemble de bibliothèques destinées à faciliter le développement PS3 et regroupé sous le nom de Edge Toolkit.
Le deuxième point primordial qui a influencé le design concerne le frame rate : id Tech 5 est conçu pour pouvoir assurer un frame rate de 60 images par seconde sur toutes les plates-formes alors que jusqu’ici id Software visait plutôt les PC très haut de gamme et un frame rate de 30 i/s. Autant dire que le challenge est ambitieux. Evidemment rien ne force un jeu basé sur id Tech 5 à tourner à 60 i/s, mais il est indéniable que ce choix a eu des conséquences sur l’architecture du moteur.
Le dernier point, sans doute celui qui a fait le plus parler de lui, concerne donc la fameuse technologie de MegaTexture déjà entraperçue dans Enemy Territory : Quake Wars. Derrière ce nom se cache en fait plusieurs technologies : tout d’abord deux textures (une texture de base, une normal map) d’une taille de 32 768 x 32 768, largement au-delà des capacités du hardware (8 192 x 8 192 pour les cartes compatibles Direct3D 10). Ensuite un ensemble de techniques de compression est utilisé afin de prendre ces deux textures de 4 Go chacune, de les combiner en un fichier de 5 Go puis de le compresser en un fichier d’environ 500 Mo. Tout cela est bien joli mais même avec les cartes modernes il est impossible de charger une telle quantité de données en VRAM et quand bien même ce serait le cas, le GPU ne saurait quoi en faire. Pour gérer cette texture, un ensemble d’algorithmes décompose donc l’image initiale en tiles de 128 x 128 texels et les charges sur la carte à la volée, uniquement lorsqu’elles sont nécessaires. Résultat : un terrain texturé de façon unique, sans motif répétitif ni jointures disgracieuses venant briser l’illusion et une consommation de VRAM réduite.
La virtualisation de textures
Le problème de cette première version de la technologie est qu’elle ne pouvait s’appliquer qu’aux terrains, ou plus précisément à toute géométrie pouvant être assimilée à un plan déformé. Avec id Tech 5 John Carmack a poussé plus loin le concept afin de pouvoir l’utiliser sur des géométries arbitraires. Mais concrètement comment ça marche ? Le concept est finalement proche de celui utilisé par la gestion de la RAM sur les CPU : une application et ses données ne sont pas chargées en RAM comme un seul bloc, en réalité tout est décomposé en pages de quelques kilo octets et seules les données nécessaires à un instant T sont présentes en RAM, les autres restent sur le disque dur.
Pour gérer tout cela un mécanisme de traduction d’adresses se charge de donner l’illusion à l’application qu’elle dispose d’une zone mémoire contiguë dans laquelle toutes les données sont disponibles alors qu’en pratique les pages sont éparpillées partout en mémoire et sur le disque : c’est le concept de mémoire virtuelle, le CPU ne manipule que des adresses virtuelles qui sont ensuite traduites en adresse physique par une unité dédiée (la MMU : Memory Management Unit). Si la page est présente en mémoire l’adresse virtuelle est remplacée par la véritable adresse dans la RAM, sinon la page est chargée en mémoire depuis le disque dur (on parle de défaut de page). Cette technique permet plusieurs choses : tout d’abord un mécanisme de protection (la MMU qui se charge de la traduction d’adresse ne laisse pas à un processus l’accès à une page mémoire qui ne lui appartient pas) et surtout un mécanisme permettant d’utiliser des applications nécessitant plus de mémoire qu’il n’y en a physiquement dans l’ordinateur.
Ainsi sur un système 32 bits, chaque processus dispose de son propre espace d’adressage de 4 Go (en général sous Windows 2 Go sont réservés au noyau, le processus ne peut donc utiliser que 2 Go) et tant que sa consommation mémoire reste dans la limite de cette taille il n’y a pas de problème, même si l’ordinateur dispose d’une quantité de mémoire physique nettement plus faible. Il convient de noter qu’aujourd’hui la quantité de mémoire physique flirte dangereusement avec les limites de l’adressage 32 bits accélérant le besoin d’une transition vers un adressage 64 bits.
Revenons à id Tech 5. Le problème consistant à placer une texture de plusieurs Go dans une mémoire de quelques centaines de Mo au mieux ne vous rappelle-t-il pas celui que nous venons de décrire ? Et bien la solution est exactement la même : dans les faits cette immense texture n’a jamais besoin d’être présente en mémoire dans son intégralité, par conséquent les textures comme nous l’avons vues sont découpées en tiles et ceux-ci sont chargés en VRAM uniquement selon les besoins, la RAM principale agit comme une zone de stockage intermédiaire, une sorte de mémoire cache venant tirer parti des principes de localité spatiale et temporelle. En effet lorsque le moteur demande une portion de la MegaTexture pour un frame donné il y a de fortes chances que pour le frame suivant il ait besoin d’une portion proche. Ainsi lorsqu’une partie est ramenée depuis le disque dur puis décompressée, autant en prendre un peu plus que nécessaire afin d’accélérer les accès suivants.
Dans la théorie c’est très beau, dans la pratique toute la difficulté consiste à déterminer quelles pages sont nécessaires pour un frame donné, et ensuite à programmer un shader permettant de texturer la géométrie avec toutes ses petites pages éparpillées en VRAM. Un des problèmes se posant concerne notamment le filtrage : que se passe-t-il par exemple aux bords des pages ? Si les pages sont chargées sous la forme d’un atlas de textures (plusieurs petites textures compactées dans une grosse texture pour plus d’efficacité) l’unité de texture du GPU utilisera des texels d’une texture qui n’a rien à voir lors du filtrage, ce n’est donc pas utilisable tel quel.
Soyons clairs, John Carmack n’a pas (encore ?) détaillé le fonctionnement de son algorithme. Il faut dire que sa volonté d’ouverture du temps de Doom III a peut être coûté cher à id Software. En effet plusieurs développeurs se sont inspirés de ses travaux pour reprendre certains concepts tout en se dépêchant de sortir leurs jeux en premier, mais plus grave une société comme Creative Labs a menacé id Software de procès sur la base d’un ancien brevet. Malgré cette absence de détails on peut quand même faire quelques suppositions, prévenons toutefois les âmes sensibles : la partie qui suit est assez technique, si vous ne souhaitez pas entrer dans les détails de l’algorithme mais juste avoir une idée des possibilités offertes n’hésitez donc pas à passer directement à la section suivante.
Suppositions sur l’algorithme
Concernant la gestion des pages cela peut être effectué avec un algorithme utilisant le GPU et le CPU de concert. Ainsi au début du frame la géométrie est rendue une première fois dans un buffer d’une taille précise : chaque pixel représente une page en mémoire. Avec une texture de 128 000 x 128 000 et des pages de 128 x 128 texels cela nous donne un buffer de 1000 x 1000, une résolution particulièrement faible pour nos GPU modernes. Ce rendu est donc extrêmement rapide surtout qu’il est très basique : le but n’est que de marquer certains pixels. Au lieu d’utiliser les coordonnées x, y, z de la géométrie on utilise les coordonnées u, v qui servent à l’application de texture.
Ce buffer est ensuite renvoyé au CPU (les transferts dans ce sens sont peu optimisés mais le buffer ne fait que 1 Mo ce qui ne pose aucun problème) qui peut déterminer les pages nécessaires en observant les pixels qui ont été remplis. Il compare ensuite les pages nécessaires pour ce frame à celles déjà chargées en VRAM en utilisant une table en mémoire.
Si une page est nécessaire mais pas encore présente le chargement se fait de façon asynchrone (le chargement est lancé et sans attendre qu’il soit terminé le reste du traitement se poursuit). Enfin une texture combinant toutes les pages nécessaires (un atlas de textures) est générée puis envoyée au GPU. Si les pages qui n’étaient pas déjà présentes en RAM n’ont pu être chargées dans le temps imparti, une version de plus basse résolution est utilisée. Ensuite un fragment shader se charge de transformer les coordonnées de texture virtuelles (elles adressent la grande texture) pour qu’elles correspondent à l’atlas de texture généré.
En ce qui concerne le filtrage de texture plusieurs solutions sont possibles : la première consiste à le faire manuellement dans le shader : cela nécessite 4 adressages de textures et quelques opérations arithmétiques. Cette solution a peu de chance d’être celle utilisée du fait de son efficacité : si vous suivez régulièrement les tests de GPU sur Presence-PC vous savez sans doute que les unités de texture voient leur nombre augmenter au ralenti par rapport aux unités de calcul, et que pour masquer un adressage de texture de plus en plus d’opérations arithmétiques sont nécessaires. Toute technique augmentant la charge à ce niveau et laissant inutilisée une partie du hardware (les unités de filtrage) est donc à proscrire. Une autre possibilité serait d’avoir un chargement un peu moins conservateur : lorsqu’une page est nécessaire, au lieu de ne ramener qu’elle, on ramène en fait les 4 pages les plus proches du texel voulu. Ces 4 pages sont combinées dans une texture plus grosse (256 x 256) et c’est cette texture qui est chargée dans l’atlas.
Si vous êtes vraiment férus de technique et souhaitez pousser plus loin les investigations vous pouvez vous référer à ce document décrivant un mécanisme proche de la virtualisation de textures utilisée par id Tech 5, tout du moins dans l’esprit. Pour ceux qui se sont égarés dans cette partie de l’article malgré nos avertissements, prenez une aspirine et n’abandonnez pas votre lecture, le reste est nettement plus facile à suivre…
Les bénéfices de la virtualisation de textures
Tout ceci est bien joli mais en pratique, qu’est ce que cela change au niveau du jeu ? Plusieurs choses : pour les graphistes cela permet de s’affranchir de toute contrainte concernant les textures. Le graphiste peut utiliser des textures de la taille qu’il veut et venir les placer sur ses modèles sans se soucier des limitations du hardware ou du budget mémoire : au final tout sera combiné dans une seule texture et l’algorithme d’adressage se charge de s’y retrouver.
Au niveau de l’aspect graphique du jeu les MegaTextures offrent de multiples avantages. Les graphistes peuvent se permettre de nombreux détails, en effet contrairement à un moteur classique où le mélange des couches se fait à l’exécution ce qui finit par ralentir le GPU lorsque le nombre de superpositions devient trop élevé, ici les couches sont toutes combinées lors de la compilation de la MegaTexture. Ensuite à l’exécution pour le GPU il s’agit d’une seule texture classique. Les graphistes peuvent donc apporter plus de détails dans leurs textures sans impact sur les performances.
Toujours en terme d’amélioration graphique les graphistes peuvent utiliser des fonctions de mélange plus avancées. Les moteurs classiques utilisent en général une simple interpolation linéaire entre deux textures en utilisant une texture alpha. Afin de masquer la répétition des textures ils utilisent en général plusieurs textures alpha pour faire ce mélange mais cette technique reste limitée.
Avec une unique texture sur laquelle travailler les graphistes ont un contrôle plus précis : au lieu de combiner les textures en utilisant quelques fonctions de mélange prédéfinies ils peuvent gérer ça au texel près en utilisant le mélange qu’ils veulent, inutile de se limiter à une simple interpolation linéaire. Les couches peuvent se mélanger en prenant en compte les informations de la normal map et les graphistes contrôlent tout ça précisément.
Dernier avantage cette fois en terme de performances : la virtualisation de textures permet un meilleur batching. Batching ? En français traitement par lot, un GPU n’est finalement qu’une machine à états : le programmeur spécifie des états qui vont contrôler la façon dont le GPU va rendre les triangles. Typiquement il s’agit d’activer l’application de texture, de spécifier les textures, les shaders, les données géométriques et de lancer le rendu. Pour obtenir les meilleures performances possibles il faut toutefois laisser au GPU la possibilité d’amortir le coût induit par le changement d’états, en clair cela signifie changer les états et ensuite dessiner un nombre non négligeable de triangles partageant ces états. Des changements trop répétés auront un impact particulièrement négatif pour les performances mais par moment il est impossible de faire autrement.
En particulier le changement de textures est une des raisons les plus fréquentes empêchant les gros batchs. Avec id Tech 5 et son unique MegaTexture ce problème est résolu et John Carmack affirme pouvoir effectuer tout le rendu en seulement 3 batchs (un pour le décor, un pour les objets opaques, un pour les objets transparents) ce qui est particulièrement peu. Evidemment tout cela est à relativiser en fonction du coût des algorithmes permettant cette virtualisation de textures, coût qu’il est impossible d’évaluer vu le peu de détails sûrs dont nous disposons, mais si John Carmack et toute l’équipe d’id Software vise un frame rate de 60 i/s même sur les consoles il semble clair que cette technique n’est pas si gourmande que ça.
Ombres & Lumières
Avec Doom III John Carmack avait orienté tous ses efforts sur l’intégration d’un moteur d’éclairage totalement unifié permettant de gérer les lumières dynamiques ou statiques de la même façon et de n’avoir qu’un seul mécanisme de gestion des ombres (les stencil shadows) appliqué sur l’ensemble du monde.
Trois ans plus tard il semble toujours aussi fier de l’élégance de sa solution mais il faut reconnaître que si d’un point de vue intellectuel tout ceci est bien séduisant dans la pratique cela a posé plusieurs problèmes. Le premier a notamment concerné les mappers qui n’étaient pas familiers de ce mode de gestion de la lumière. Jusqu’ici ils avaient l’habitude de mettre autant de lumières statiques qu’ils en avaient besoin jusqu’à ce que la pièce soit correctement éclairée, exactement comme ils le souhaitaient. Comme tout ceci était compilé dans des lightmaps cela n’avait aucun impact sur les performances à l’exécution. Avec le nouveau modèle d’éclairage chaque lumière avait un impact direct sur les performances, il fallait donc les placer avec parcimonie et bien peaufiner tous les paramètres ce qui demandait plus de temps.
D’un point de vue visuel le temps réel ne permettait pas non plus d’utiliser des modèles d’éclairage très évolués, pas question d’utiliser de la radiosité comme pour les lightmaps de Quake II. De plus les ombres stencil ne permettaient pas non plus de générer des ombres douces avec des performances compatibles avec le rendu temps réel.
Avec beaucoup de regrets John Carmack a donc du faire machine arrière et reconnaître que ce n’était peut être pas le moment d’unifier le modèle d’éclairage. Ainsi id Tech 5 revient à un modèle plus classique avec probablement (rien n’est encore fixé à ce stade du développement) un éclairage précalculé pour le terrain et tous les éléments statiques, et des shadow maps pour les ombres dynamiques. Carmack a avoué dans sa présentation ne pas s’être encore concentré sur cet aspect du moteur et cela se remarque sur le trailer où on peut constater que les interactions ombres statiques/ombres dynamiques ne sont pas parfaitement au point. Initialement lors du développement de Darkness, Carmack avait prévu de gérer toutes les ombres avec des shadow maps mais leur impact sur les performances était trop pénalisant pour un moteur privilégiant le framerate ce qui l’a donc contraint à revenir à une solution hybride.
id Studio, les outils
Comme l’a plaisanté John Carmack, « [id] a la réputation, totalement méritée, de développer une bonne technologie mais avec des outils particulièrement pauvres pour l’exploiter ». Mais de nos jours une philosophie si minimaliste ne peut plus suffire. Créer des jeux prend de plus en plus de temps et la technologie n’est plus le seul point sur lequel il faut se concentrer, le meilleure technologie du monde ne pourra pas briller si les graphistes et mappers n’ont aucun moyen de l’exploiter. Epic l’a bien compris en proposant, avec l’Unreal Engine 3, de nombreux outils particulièrement réussis et intuitifs.
Mais cette fois encore ils vont devoir faire face à un id Software nouveau, qui a pris conscience de ses carences et s’est donné les moyens de les corriger. id Tech 5 est donc fourni avec un ensemble d’outils réunis sous le nom d’id Studio. Derrière ce nom se cache : l’éditeur de niveaux, l’éditeur de terrains, l’éditeur de scripts, l’éditeur d’animations mais aussi des outils de gestion permettant de faire du report de bugs ou encore un calendrier pour l’équipe, une TODO List… Il s’agit donc véritablement d’un environnement intégré dédié à toutes les personnes impliquées dans la création du jeu.
Mais de tous ces logiciels le plus intéressant est indéniablement l’éditeur de terrains. Pendant longtemps, à chaque fois que quelqu’un mentionnait les MegaTextures dans une interview beaucoup de joueurs se demandaient comment les graphistes allaient pouvoir créer des textures aussi immenses. Ils imaginaient aussitôt le graphiste créer une image de 64 000 x 64 000 dans Photoshop et la remplir méticuleusement pixel par pixel. Heureusement les choses ne se passent vraiment pas comme cela : en pratique le graphiste crée le mesh de son terrain avec le modeleur qu’il préfère, et il lui applique une texture de base qui est répétée (cela ne pose pas de problème, cette texture ne constitue de toute façon que la couche de base). Ce terrain est ensuite importé dans l’éditeur de terrain avec sa texture de base, et là les graphistes peuvent travailler pour apporter les petites touches qui vont donner tout son caractère au jeu.
Concrètement ils disposent d’un ensemble de « tampons », des petites textures de 128 x 128 pixels ou moins, qu’ils sélectionnent dans une palette et viennent appliquer sur le terrain par petites touches, exactement là où ils veulent ajouter des détails. La démonstration est particulièrement impressionnante, non seulement le résultat est réussi graphiquement mais l’utilisation de l’éditeur semble extrêmement intuitive : tout cela semble aussi simple qu’utiliser un pinceau sous P
Conclusion
Après plusieurs années de silence, id Software sort de son mutisme et se relance dans la bataille des moteurs 3D en venant s’attaquer sérieusement à l’Unreal Engine 3, la référence actuelle. Si John Carmack n’a pas perdu son habitude de concentrer ses efforts sur des technologies qui le motivent sur un plan intellectuel plutôt que de s’orienter vers des effets visuels plus vendeurs et bien plus simples à illustrer pour des joueurs, id Software a en revanche changé assez sensiblement de stratégie commerciale.
Il semble que le département marketing de la firme a enfin réalisé que la concurrence avec Epic devait désormais être prise très au sérieux et qu’ils avaient sans doute pris du retard, trop habitués à voir les développeurs venir acheter leur technologie spontanément, sur la base de leur seule réputation. On les sent aujourd’hui plus agressifs : ils ont rationalisé le nom de leurs moteurs, ils n’hésitent pas à multiplier les démonstrations (à l’Apple WWDC, à l’E3 et évidemment à la QuakeCon) et ils développent des outils modernes pour exploiter au mieux leur moteur 3D. En d’autres termes ils utilisent les armes d’Epic pour les battre sur leur propre terrain.
Enfin dernière révolution en date : ils assouplissent d’une certaine façon leur philosophie consistant à vouloir rester petits à tout prix (état d’esprit qui avait, entres autres, été la principale source du conflit opposant Romero à Carmack à l’époque de Quake) en constituant une deuxième équipe au sein d’id Software.
Bref, id Software semble décider à jouer un rôle prépondérant durant cette génération et pour les joueurs, cela ne présage que de bonnes choses. Entre Crytek et son impressionnant CRY Engine 2, Epic et son inévitable Unreal Engine 3 et maintenant id Software avec id Tech 5 les développeurs de jeux ont le choix pour créer des jeux exploitant au mieux nos dernières consoles et PC.
