Optimisation (B : diminuer les r_speeds)

Oui, vous l'aurez compris, le meilleur moyen de faire diminuer ses r_speeds c'est de commencer à faire des "vraies" maps !

Comme à peu près tout le monde, j'ai moi aussi commencé à créer des maps gigantesques qui m'affichaient environ 1800 wpoly...

Maintenant je sais comment on doit créer une map, et grâce à cette méthode je dépasse rarement les 800 wpoly ! Ca peut paraître absurde, mais il y a de fortes chances que jusqu'ici vous étiez en train de créer des maps tout à fait foireuses, même si vous aviez l'impression que tout marchait bien.


Eh oui, c'est aussi bête que ça, et pourtant quand on le fait ça change vraiment tout !

Cas d'une map en intérieur

Si votre map se déroule entièrement à l'intérieur (cas d'une maison, d'une base telle que Black Mesa...), c'est encore assez simple à faire... Vous devez créer plusieurs pièces : des salles plus ou moins grandes, où on pourrait passer de l'une à l'autre grâce à des couloirs ou des portes.

Il faut à tout prix faire en sorte que lorsqu'on est dans une salle on ne puisse pas voir le contenu de l'autre salle. Half-Life ne doit pas calculer les polygones d'une salle que l'on ne voit pas !
Pour cela, il faut créer des zones de transition dans votre map (ascenseur, escalier, couloir...)

Par exemple, voici une zone de transition :


Lorsqu'on descend ces escaliers, on passe d'une pièce (qui se trouve derrière la porte à gauche), à une autre pièce (la cave à droite). Ainsi, grâce à cette zone de transition, si on est dans la cave, seuls les polygones de la cave sont calculés !

Cas d'une map en extérieur

C'est un cas très fréquent pour les maps Counter-Strike par exemple. Et c'est là que vous risquez de faire le plus d'erreurs...

Pourquoi ? Parce que vous ne comprenez pas ce que veut dire "créer des salles" lorsqu'on se trouve à l'extérieur !

Grâce au sky tout simplement !
Vous savez, la texture sky peut faire bien des choses que l'on ne soupçonne pas. Dans ce cas, elle va servir à créer des murs de skys, afin de créer des salles.
Il faut impérativement que le sky différencie les salles de votre map, et que les murs de sky touchent le sky du haut, un peu comme ceci :


Vous pouvez voir ici une "salle" en extérieur. Observez surtout comment le sky est placé... Il est partout présent ! Les murs de sky partent du haut des toits et s'arrêtent au sky tout en haut.
Et c'est pareil pour toutes les autres "salles" de la map ! Le joueur est constamment entouré de skys, mais lorsqu'il joue sur votre map il ne s'aperçoit pas de cette supercherie !
Efforcez-vous donc de respecter cette méthode pour vos futures maps. Vous verrez que de cette manière vous n'aurez pratiquement plus jamais à vous plaindre des r_speeds !

Si j'ai tellement insisté sur le sky, c'est pour que vous évitiez de commettre cette (grosse) erreur de débutant... Bon, je n'aime pas montrer le mauvais exemple mais là je crois que c'est nécessaire.
Voici ce qu'on appelle le sky box, que vous ne devez surtout pas faire :

Et comme vous pouvez le voir, il y a beaucoup trop de polygones à la fois... Du coup, je vous laisse imaginer les r_speeds...

Eh oui, dans ce cas c'est toute la map qui serait à revoir : il faudrait la restructurer en plusieurs salles. La map que vous voyez là est donc un mauvais exemple ! Evitez de faire pareil, parce que c'est bel et bien à cause de ça que vous vous retrouvez avec des r_speeds faramineuses !

Grâce à ce que vous venez d'apprendre, vous ne devriez presque plus jamais avoir de problèmes de r_speeds.
Je dis "presque" car il peut arriver parfois une situation assez gênante... à cause par exemple du découpage des polygones.

Il existe des méthodes plus ou moins délicates qui vous permettront d'éviter ce genre de problème que nous avons vu dans le précedent chapitre.

Eviter le contact direct des polygones

Lorsqu'il y a découpage des polygones, c'est que 2 blocs sont en contact l'un avec l'autre, et que le plus petit découpe le plus grand...

Si vous voulez éviter ce genre de désagrément, la première méthode consisterait à éviter que les blocs ne se touchent !

Prenons un exemple : lorsque vous créez une pièce avec des piliers au milieu. Ceux-ci étant des cylindres, ils risquent de méchamment découper le sol !


L'astuce ici consiste à laisser un espace infime entre le pilier et le sol (1 unité suffit). Si cet espace est suffisamment petit, le joueur en passant par là ne devrait pas s'en rendre compte... et comme les blocs ne se touchent pas, il n'y aura pas de découpage du sol !


Si vous laissez juste 1 unité d'espace entre le pilier et le sol, je peux vous assurer que ça ne se verra pas. D'ailleurs, même sous Worldcraft on a beaucoup de mal à repérer cette supercherie.

L'astuce du func_wall

Comme je vous l'ai appris dans le chapitre précédent, les blocs se découpent allègrement entre eux... mais je n'ai jamais parlé des entités-blocs.
Y a-t-il découpage des polygones avec des entités-blocs ? Eh bien non ! Voilà pourquoi entre autres l'entité func_wall, de toute apparence identique à un bloc, peut nous être très utile.
Dans le cas des piliers que nous venons de voir, plutôt que de laisser un espace entre le pilier et le sol, on aurait pu convertir le pilier en func_wall. Même s'il le touchait, le pilier n'aurait pas découpé le sol !
Bingo

Rappelez-vous aussi du test que l'on avait fait dans le chapitre précédent avec une caisse au milieu d'une salle. Dans ce cas-là, le sol était découpé comme ceci :


Si la caisse est convertie en func_wall, alors le sol ne sera plus découpé !

Ah là là, c'est dur quand même le mapping lol

Les Hint Brush

Introduits avec les ZHLT, les Hint Brush peuvent être un moyen très pratique de faire baisser vos r_speeds... à condition que votre map soit déjà bien structurée.
Oui mais voilà, chaque situation est très différente, et se sera à vous de bien réfléchir à chaque fois avant de vous servir des Hint Brush... En plus, il ne faut pas oublier que le monde est en 3D : il faut aussi prendre en compte les éléments sur différents étages !

Moi, je vais vous montrer un exemple typique où les Hint Brush peuvent nous servir. A vous d'adapter cet exemple à votre map !

Exemple d'une map

Voici le plan schématique de la map "Hint" que j'ai créée pour l'occasion :


L'histoire est assez simple : le joueur part de la salle en bas à droite, puis traverse un couloir pour se rendre dans la salle en haut à gauche.

La salle en haut à gauche contient beaucoup de caisses que j'ai placé un peu n'importe comment histoire de faire monter les r_speeds. Il est normal que, lorsqu'on rentre dans cette pièce, les r_speeds se mettent à monter un peu...
Mais ce qui n'est pas normal, c'est que même si le joueur se trouve dans la pièce en bas à droite, il ait des r_speeds trop élevées (alors qu'il n'y a rien dans cette pièce) !
Oui ! Si on place le joueur sur la cible et qu'il regarde en direction du couloir, il pourra voir ses r_speeds augmenter terriblement... à cause des caisses de l'autre salle !
Dans ce cas, c'est plutôt agaçant : le joueur ne voit pas ces caisses, et pourtant Half-Life les calcule. Cela fait que les r_speeds sont élevées partout dans cette map !

Vous êtes sceptiques ? Voici un screenshot que j'ai pris en jouant sur cette map (je me suis placé sur la cible et j'ai activé le "gl_wireframe 2") :


Résultat : 305 wpoly !!! C'est aberrant, c'est stupide parce qu'on ne voit pas les caisses, mais c'est comme ça.

Explications

C'est à cause de HLvis (encore lui !), qui, en compilant la map, a "cru" que ces polygones étaient visibles (alors que ce n'est visiblement pas le cas).
HLvis divise à sa manière les blocs, en ce qu'on appelle des "blocs vis".
Voici la division qu'il a dû faire dans ce cas (schéma simplfié) :


Supposons maintenant que le joueur se place sur la cible et qu'il regarde vers le couloir :


Il "voit" un bout du bloc vis 3. Dès lors qu'un bloc vis est vu, HLvis pense qu'il faut calculer tous les autres blocs vis avec lesquels il est en contact... c'est-à-dire le bloc vis 4 avec toutes les caisses qui vont avec !

Moralité : 305 wpoly pour rien

Heureusement, les Hint Brush vont nous tirer d'affaire !

Apparence des Hint Brush

Pour pouvoir introduire des Hint Brush dans votre map, il faut tout d'abord charger dans Worldcraft le fichier de textures "ZHLT.wad"
Ce wad contient 3 textures dans les versions récentes des ZHLT, et seulement 2 textures dans les anciennes versions.
La texture rajoutée est NULL : tout bloc possédant cette texture ne sera pas compilé par les ZHLT dans le *.bsp. Cela n'a aucun rapport avec les Hint Brush, donc vous pouvez oublier cette texture

Pour ce qui est des 2 autres textures, voici à quoi elles ressemblent :

HINT	La texture HINT, c'est celle qui va donner une information à HLvis lorsqu'il calculera les portals. Elle permettra en quelque sorte d'éviter que de trop nombreux blocs soient calculés pour rien.
SKIP	Quant à la texture SKIP, elle est toujours utilisée en même temps que HINT. En fait, cette texture ne sert strictement à rien ("Skip" en anglais signifie "Passer"). Seul HINT va donner une information : SKIP n'a aucun effet mais on en aura besoin, vous allez voir...

Un Hint Brush sous Worldcraft, c'est en réalité un bloc normal à 6 faces, dont toutes les faces sont recouvertes de la texture SKIP, sauf une (et pas n'importe laquelle) qui possède la texture HINT :

Fonction des Hint Brush

Comme nous l'avons vu tout à l'heure, HLvis s'est très mal débrouillé en découpant les blocs vis... ce qui nous a amené à avoir des r_speeds élevées pour rien !

Concrètement, les Hint Brush vont nous permettre d'ordonner à HLvis de découper les blocs vis d'une autre manière. Si vous prenez le temps de réfléchir 5 minutes sur votre problème, vous trouverez tous seuls où vous devez placer vos Hint Brush !

Comme je vous l'ai dit, seule la face recouverte de la texture HINT va avoir un effet. Toutes les autres (avec la texture SKIP) seront oubliées.

La face (et je dis bien la face) recouverte de la texture HINT va découper les blocs vis avec lesquels elle est en contact.
Voilà tout simplement à quoi sert un Hint Brush, et si vous avez bien suivi mes explications jusqu'ici, alors vous venez de tout comprendre !

Sur le schéma des blocs vis, voici le découpage idéal que l'on aimerait obtenir :


Vous voyez, ici on a rajouté un découpage des blocs vis au niveau de l'intersection du couloir... Cela fait que seule l'autre partie du couloir sera calculée (puisqu'elle est en contact direct avec le bloc vis de l'intersection), et du coup l'autre pièce avec ses nombreuses caisses n'est pas calculée !

Pour faire ce découpage, j'ai donc placé mon Hint Brush comme ceci dans Worldcraft :


La face Hint a découpé les blocs vis et le tour était joué !

Conclusion

Ah, il ne me reste plus qu'à vous faire admirer le résultat :


La différence se fait ressentir : ça nous fait 200 wpoly de moins d'un coup !!! Quel soulagement

A noter que si j'avais mis encore plus de caisses dans l'autre salle, les Hint m'auraient fait descendre encore plus les wpoly (la différence aurait été plus grande). Bref, vive les Hint Brush !
Le tout est de savoir les placer judicieusement, et surtout de ne pas en abuser...
D'ailleurs, j'ajouterai à ce sujet que si vous doublez le nombre de blocs vis dans votre map, alors le temps de compilation quadruple !!! Mais c'est très mathématique alors ne cherchez pas trop à comprendre lol
Ca veut juste dire qu'il ne faut pas trop en abuser. Enfin, dernière chose : je vous offre cette map de test appelée "Hint" dont je me suis servi tout au long des explications. Vous pouvez la télécharger ci-dessous :


Elle comprend le *.rmf et le *.bsp compilé en "Full compil". Je vous conseille de la lancer en Half-Life Solo pour pouvoir profiter du "gl_wireframe"