NoNamed

Le blog qui s’appelle pas, on le siffle … le blog de cedzekill3r.

FPS Engine : id Tech, première partie …

L’id Tech est le moteur 3d d’id Software, il est née au balbutiement des FPS et a permis le développement d’une pléthore de jeux, il est alors entré dans l’histoire et perdure encore aujourd’hui. Il en est à sa version 5 et va permettre la sortie de Rage prochainement puis Doom 4 plus tardivement.

Son code réseau a toujours été propre ce qui permit de jouer en ligne/LAN des les premiers FPS tournant sur id Tech. il y avait déjà un mode coop sur Doom via NULL-Modem et sur Quake II via LAN.

id Tech 1

L’id Tech 1 est le premier moteur 3D de la firme id Software composée d’anciens du FPS comme John Carmack et John Romero qui ont travaillés sur les premiers jeux de shoot à la première personne comme HyperTank ou Catacomb 3D

Ce moteur a permit de faire fonctionner Doom en 93 et Doom 2 l’année d’après, deux jeux de la firme, mais il a aussi permit a plusieurs autres jeux de voir le jour comme Hexen ou Heretic.

Un peu de technique :

Le moteur de Doom n’est pas un moteur 3D comme il en existe à l’heure actuelle car il est impossible d’incliner le champ de vision sur l’axe vertical, deux pièces ne peuvent se trouver l’une sur l’autre mais cela permet de faire du rendu pseudo 3D texturé et cela très rapidement ce qui n’impose pas d’avoir un PC très puissant à l’époque. C’est un des facteurs qui a permit au jeu être connu par énormément de personne.

Les niveaux sont donc en 2D lorsqu’ils sont construit, voilà d’où vient le fait que deux niveaux ne peuvent se superposer sur la carte. Il sont représenté vue de haut dans l’éditeur de carte, des lignes représente les murs et les personnages sont vus de dessus.

Les niveaux sont découpés en secteurs, eux mêmes composés de vertex (sommet) qui est un point en deux dimensions, ils sont reliés pour former des lignes (linedefs) comportant un ou deux cotés (sidedefs) qui sont ensuite reliés ensemble pour former enfin des polygones appelés secteurs, un secteur est donc une pièce de la carte. Les sidedefs sont texturés des deux cotés et peuvent être orientés librement.

Ensuite viennent se greffer des objets dynamiques sur la carte appelés “things” (choses), ils peuvent représenter un ennemi, une arme, ou tout autre objet servant juste à décorer, ce sont des textures, animées pour certaines, appelées sprites.

Le niveaux sont convertit ensuite en arbre BSP (Binary Space Partitioning), cela permet de diviser le niveau en autant de branches qu’il le faut et de n’effectuer le rendu seulement lorsque le joueur atteint une des branches de l’arbre, le reste étant ignoré. Ce processus permet de maintenir une même vitesse d’exécution quelque soit la taille du niveaux. De plus les objets sont regroupés par secteurs, les objets n’étant pas dans le champ de vision sont ignorés de la même manière.

Enfin les textures des murs sont rendus avec la technique du Raycasting qui consiste a tracer des tranches de textures verticales pour donner l’illusion de murs, les plafonds et les sols sont rendus par le procédé de Z-Mapping qui trace des textures sur le plan horizontal.

Doom

Doom

Doom II

Doom II

Hexen

Hexen

Heretic

Heretic

id Tech 2

Apparut en 1996, il est le moteur de Quake premier du nom, une version modifiée est utilisée pour Quake II fin 97. Les deux jeux ont donc énormément de lignes de codes en commun. D’abords scindé en deux moteurs distincts : le Quake Engine et le Quake II Engine, il est finalement renommé en se basant sur le Quake II Engine en id Tech 2 vers 2007 lorsque idSoftware renomme ses moteurs sous la même dénomination.

Quake

Quake

Quake II

Quake II

Un peu de technique :

Au départ le rendu fut totalement logiciel, n’utilisant pas d’accélération graphique, mais par la suite quelques exécutables ont été compilés pour utiliser des cartes vidéo récentes en utilisant OpenGL, GLQuake était né.

Les niveaux sont découpés de la même façon que sur l’idTech 1, en arbre BSP sauf qu’il y’a moins de limitations, il est possible de superposer des piéces désormais, mais aussi de regarder dans toutes les directions. Pour éviter que des murs soient rendus alors qu’ils sont cachés derrière d’autres plus proche une Global Edge List est établit en stockant la liste des bords des triangles déjà affichés et en utilisant ces informations pour couper les triangles que l’on ne doit pas voir entièrement , seuls les parties visibles sont alors affichés. D’autres algorithmes existaient déjà à l’époque comme le Z-Buffer mais trop gourmand sur les prototypes de Quake.

Une texture est affichée en combinant sa lightmap avec elle pour donner une surface qui sera stockée pour être réutilisée, ce qui économisera le coût en ressources en évitant de recalculer le tout à chaque fois. Pour les murs lointains une surface plus petite est générée en utilisant les mipmaps des textures ce qui économise la mémoire et évite l’aliasing des textures vues de trop loin.

Pour les objets 3D, un Z-Buffer est utilisé pour les masquer par le décor quand nécessaire. Les objets sont soumis à l’éclairage ambiant, une couleur leur est attribué dépendant de leur position.

Le code réseau optimisé pour les pings faibles (LAN), est adapté pour des pings plus importants dans le but de jouer sur Internet, le jeu Quake World fait son apparition en 96.

Quake World

Quake World

Les moteurs passent sous licence libre en 99 pour le Quake Engine et 2001 pour son frère.

De nombreux jeux à part Quake vont sortir sur ce moteur, ce moteur va même être repris, modifié et adapté notamment pour le jeu Half-Life avec son moteur dérivé du Quake II Engine : le GoldSrc en 98 ou plus récemment en 2005 avec le DarkPlaces pour le jeu Nexuiz.

Half-Life

Half-Life

Nexuiz

Nexuiz

D’autres portages ont fait leur apparition au fil des ans pour un tas de système dont le MAC ou le Pocket PC, d’autres modifications se focalisaient sur l’amélioration du rendu et l’ajout de fonctionnalités comme l’éclairage dynamique, le brouillard, effets de particules etc …

La première partie s’achève ici, en espérant que cet article était intéressant pour vous, rendez-vous pour la suite : when it’s done !

27 commentaires pour “FPS Engine : id Tech, première partie …”

  1. skaven dit :

    On pouvait jouer à 2 à DOOM grâce à un cable NULLModem (communication série).

  2. SPTX dit :

    Parler de l’IDtech sans mentionner l’IDtech3 c’est comme parler de spaghettis bolo sans parler de la bolognaise.

    à moins que tu le reserve pour la suite, ce qui me semble être le cas.
    Donc jvais juste critiquer une peu l’orthographe.

  3. cedzekill3r dit :

    skaven a dit :
    On pouvait jouer à 2 à DOOM grâce à un cable NULLModem (communication série).

    Merci ! Je ne le savais pas …

  4. Kher dit :

    Les écoutes pas ces aigris, moi j’aime beaucoup ton blog et ton pseudo !

  5. cedzekill3r dit :

    Kher a dit :
    Les écoutes pas ces aigris, moi j’aime beaucoup ton blog et ton pseudo !

    merci Kher ! en voilà un qui me motive grave a écrire la suite !
    encore merci !

  6. Seita dit :

    Article comme toujours intéressant ! Et du coup trop court.

  7. cedzekill3r dit :

    Merci à tous, je vais essayer de l’étoffer un peu, mais la suite arrive !!!

  8. channie dit :

    Tu peux également citer Warsow qui utilise QFusion, un fork de Q2.

  9. Caroline dit :

    bon euh, on pourrait en revenir au sujet de l’article maintenant ?

  10. cedzekill3r dit :

    Revenons au sujet oui !

    Je ne suis pas pour la modération des commentaires mais je vais modérer la dérive du sujet pour une fois.
    Désolé mais c’est pas sain.

  11. Conradson dit :

    Pour revenir au sujet, je trouve l’intention est louable, mais au final on a que trop peu de détails sur la technologie des moteurs, les différences selon les versions, la façon dont-ils ont conçu le moteur, etc…

  12. cedzekill3r dit :

    Conradson a dit :
    Pour revenir au sujet, je trouve l’intention est louable, mais au final on a que trop peu de détails sur la technologie des moteurs, les différences selon les versions, la façon dont-ils ont conçu le moteur, etc…

    La peur sans doutes d’en faire trop ! Je peut ajouter tout un tas de termes techniques mais je ne sais pas si tout le monde le veux au fond … je vais détaillé un peu, enfin sans trop partir dans les Voxels, les Z-Buffer, et tout le tintouin …

  13. Celibatman dit :

    N’aies pas peur d’en faire trop Cedzekill3r, c’est une excellente initiative de décortiquer ces moteurs, si tu as envie d’être exhaustif, ne te gènes pas pour nous.

  14. Gregzenegair dit :

    Ce qui serait intéressant , ce serait, sans spécialement entrer dans le détail technique, d’expliquer les améliorations apportées par chaque évolution du moteur, mais cela requiert une connaissance plus poussée des jeux/moteurs en question.

  15. Ze_PilOt dit :

    Les maps de doom étaient pas plates, c’est juste qu’on pouvait pas superposer deux niveaux. Mais il y avait des escaliers et tout..

  16. ap0 dit :

    Étoffe ton (très bon) article, peu importe s’il y a des termes techniques : si les gens ne comprennent pas, ils passeront au paragraphe suivant.

  17. cedzekill3r dit :

    Les maps de Doom ne sont pas plates oui en effet, je me suis mal exprimé, je vais modifié ce détail merci !
    Je m’attèlerais a la tâche demain pour étoffer cet article …

  18. neFAST dit :

    AH ouais, si tu peux ajouter des détails techniques je suis preneur !

  19. Lolokth dit :

    Dans Heretic, n’y avait-il pas des pièces superposées ? En tout cas on pouvait regarder en haut et en bas.

  20. karna dit :

    Dans Duke Nukem 3D c’était le cas aussi, grâce à une bidouille : on pouvait tomber dans un puits et se retrouver dans une pièce juste en dessous, mais c’était une sorte de “téléporteur” maquillé si je me souviens bien.

  21. cedzekill3r dit :

    Lolokth a dit :
    Dans Heretic, n’y avait-il pas des pièces superposées ? En tout cas on pouvait regarder en haut et en bas.

    Il faudrait que j’y rejoue, mes souvenirs me font défaut !

    karna a dit :
    Dans Duke Nukem 3D c’était le cas aussi, grâce à une bidouille : on pouvait tomber dans un puits et se retrouver dans une pièce juste en dessous, mais c’était une sorte de “téléporteur” maquillé si je me souviens bien.

    Il me semble que Duke Nukem avait contourner le problème, le Build Engine était capable de superposer les salles.

  22. Caroline dit :

    oui on pouvait superposer les salles dans duke mais en bidouillant avec un téléporteur comme dit plus haut (même méthode pour l’eau : quand on sautait sur la texture de l’eau, ça activait un téléporteur. Il fallait donc faire, à l’écart de la map, une chambre remplie d’eau ou se retrouvait le joueur. Quand il remontait à la surface, hop, retéléport dans la map d’origine ^^).

    Ou on pouvait aussi les superposer dans build (l’éditeur) mais c’était invisible pour le joueur … enfin bref, c’était du bon vieux bricolage !

  23. cedzekill3r dit :

    Caroline a dit :
    oui on pouvait superposer les salles dans duke mais en bidouillant avec un téléporteur comme dit plus haut.
    On on pouvait aussi les superposer dans build (l’éditeur) mais c’était invisible pour le joueur … enfin bref, c’était du bon vieux bricolage !

    On savait se démerder à l’époque c’est vrai !
    Je me pencherais sur Duke Nukem, il a rythmé ma vie pendant 5 bonnes années a le faire et le refaire ! Come Get Some !!!

  24. LeGreg dit :

    C’est une erreur commune de dire que Doom utilise le ray casting. En fait ray casting veut dire lancer de rayon (contrairement à ray tracing qui est le “traçage de rayon”, impliquant des branchements -> ray casting + rayons secondaires, tertiaires). Donc faire du Ray casting ça suppose qu’on lance des rayons (une fois par pixel ou une fois par colonne de pixels si on a une complexité réduite) pour déterminer les faces visibles dans la scène. Mais ce n’est pas ce que fait le moteur de Doom.

    Doom est plus proche d’un rasterizer (même idée que celui qui est dans votre carte graphique pour rasterizer les triangles). Traverser la liste de polygones (murs) de l’avant vers l’arrière (avec l’aide de l’arbre BSP pour le tri) tout en évitant de retracer par dessus un mur existant en stockant un booléen “déjà dessiné”, c’est une version super simplifiée d’un z buffer : voir ce tutorial (reverse painter) pour une idée similaire.

    Pourquoi la rasterization est plus rapide ? parce qu’il ne faut pas faire de nombreux branchements par pixel ou colonne de pixel. Parce que les colonnes partagent la même “profondeur” donc les textures sont simplement étirées linéairement en hauteur pour les murs (ou horizontalement pour les sols). Parce que le clipping avec le booléen “déjà tracé” est rapide, et le design du moteur ne permettait pas de tracer plus de “N murs” par image ce qui limitait la traversée de l’arbre.

  25. cedzekill3r dit :

    LeGreg a dit :
    C’est une erreur commune de dire que Doom utilise le ray casting. En fait ray casting veut dire lancer de rayon (contrairement à ray tracing qui est le “traçage de rayon”, impliquant des branchements -> ray casting + rayons secondaires, tertiaires). Donc faire du Ray casting ça suppose qu’on lance des rayons (une fois par pixel ou une fois par colonne de pixels si on a une complexité réduite) pour déterminer les faces visibles dans la scène. Mais ce n’est pas ce que fait le moteur de Doom.
    Doom est plus proche d’un rasterizer (même idée que celui qui est dans votre carte graphique pour rasterizer les triangles). Traverser la liste de polygones (murs) de l’avant vers l’arrière (avec l’aide de l’arbre BSP pour le tri) tout en évitant de retracer par dessus un mur existant en stockant un booléen “déjà dessiné”, c’est une version super simplifiée d’un z buffer : voir ce tutorial (reverse painter) pour une idée similaire.
    Pourquoi la rasterization est plus rapide ? parce qu’il ne faut pas faire de nombreux branchements par pixel ou colonne de pixel. Parce que les colonnes partagent la même “profondeur” donc les textures sont simplement étirées linéairement en hauteur pour les murs (ou horizontalement pour les sols). Parce que le clipping avec le booléen “déjà tracé” est rapide, et le design du moteur ne permettait pas de tracer plus de “N murs” par image ce qui limitait la traversée de l’arbre.

    Là je suis sur le cul, je vais revoir ma copie … je pensé que doom utilisait le même procédé que wolfenstein 3D pour les murs, mais ne parles-tu pas de la manière dont ils sont cachés par les autres murs ?

  26. lapphora dit :

    LeGreg a dit :
    C’est une erreur commune de dire que Doom utilise le ray casting. En fait ray casting veut dire lancer de rayon (contrairement à ray tracing qui est le “traçage de rayon”, impliquant des branchements -> ray casting + rayons secondaires, tertiaires). Donc faire du Ray casting ça suppose qu’on lance des rayons (une fois par pixel ou une fois par colonne de pixels si on a une complexité réduite) pour déterminer les faces visibles dans la scène. Mais ce n’est pas ce que fait le moteur de Doom.
    Doom est plus proche d’un rasterizer (même idée que celui qui est dans votre carte graphique pour rasterizer les triangles). Traverser la liste de polygones (murs) de l’avant vers l’arrière (avec l’aide de l’arbre BSP pour le tri) tout en évitant de retracer par dessus un mur existant en stockant un booléen “déjà dessiné”, c’est une version super simplifiée d’un z buffer : voir ce tutorial (reverse painter) pour une idée similaire.
    Pourquoi la rasterization est plus rapide ? parce qu’il ne faut pas faire de nombreux branchements par pixel ou colonne de pixel. Parce que les colonnes partagent la même “profondeur” donc les textures sont simplement étirées linéairement en hauteur pour les murs (ou horizontalement pour les sols). Parce que le clipping avec le booléen “déjà tracé” est rapide, et le design du moteur ne permettait pas de tracer plus de “N murs” par image ce qui limitait la traversée de l’arbre.

    Évidemment. Tu peux pas faire un rendu 2D bitmap des textures de Doom sur un simple zbuffer 24 bits en raytracing, à la limite tu joues sur un reverse ollie ou un grind pour affiner l’éclairage et étendre la texture pixel par pixel pour ne pas trop charger la mémoire et éviter un overflow binaire parce qu’un float en statique ça te fait vite une fuite. Les mecs d’ID ont été bons en jouant sur ça.

  27. cedzekill3r dit :

    lapphora a dit :

    LeGreg a dit :
    C’est une erreur commune de dire que Doom utilise le ray casting. En fait ray casting veut dire lancer de rayon (contrairement à ray tracing qui est le “traçage de rayon”, impliquant des branchements -> ray casting + rayons secondaires, tertiaires). Donc faire du Ray casting ça suppose qu’on lance des rayons (une fois par pixel ou une fois par colonne de pixels si on a une complexité réduite) pour déterminer les faces visibles dans la scène. Mais ce n’est pas ce que fait le moteur de Doom.
    Doom est plus proche d’un rasterizer (même idée que celui qui est dans votre carte graphique pour rasterizer les triangles). Traverser la liste de polygones (murs) de l’avant vers l’arrière (avec l’aide de l’arbre BSP pour le tri) tout en évitant de retracer par dessus un mur existant en stockant un booléen “déjà dessiné”, c’est une version super simplifiée d’un z buffer : voir ce tutorial (reverse painter) pour une idée similaire.
    Pourquoi la rasterization est plus rapide ? parce qu’il ne faut pas faire de nombreux branchements par pixel ou colonne de pixel. Parce que les colonnes partagent la même “profondeur” donc les textures sont simplement étirées linéairement en hauteur pour les murs (ou horizontalement pour les sols). Parce que le clipping avec le booléen “déjà tracé” est rapide, et le design du moteur ne permettait pas de tracer plus de “N murs” par image ce qui limitait la traversée de l’arbre.

    Évidemment. Tu peux pas faire un rendu 2D bitmap des textures de Doom sur un simple zbuffer 24 bits en raytracing, à la limite tu joues sur un reverse ollie ou un grind pour affiner l’éclairage et étendre la texture pixel par pixel pour ne pas trop charger la mémoire et éviter un overflow binaire parce qu’un float en statique ça te fait vite une fuite. Les mecs d’ID ont été bons en jouant sur ça.

    NimportNawak !

Laisser un commentaire

Vous devez être connecté avec votre compte Wefrag pour publier un commentaire.