VIS : calcul de visibilité

 
 VIS comme son nom l'indique va calculer la visibilité du niveau, qu'est-ce qu'on entend par là exactement?
 
 La visibilité est extrèmement importante, c'est elle qui va dire au moteur du jeu quels polygones il doit dessiner , s'il n'y avait pas d'information vis, le moteur dessinerait tous les polygones du niveau, ce qui entraînerait une charge de travail gigantesque pour le pauvre CPU et on se retrouverait avec un taux de rafraichissement ridiculement bas.
 Le moteur définit tout d'abord dans quel secteur (bsp node) du bsp le joueur se trouve puis grace aux informations vis il sait quels secteurs sont visibles à partir de ce secteur et donc quels polygones il doit dessiner.
 De cette manière il ne traite que les polygones visible et décharge le CPU de tous ces calculs inutiles.
On comprend maintenant pourquoi tous les jeux affectionnent les couloirs tortueux qui coupent la visibilité et pourquoi les vaste étendues sont difficiles à gérer par le moteur.
 Le principe du rat courant dans un tunnel des premier jeux 3d devient clair, avec les machines limitées de l'époque, il aurait été pratiquement impossible de pouvoir créer de vaste salles à l'architecture complexe. Ce n'est que maintenant avec les dernières machines à la mode que l'on peut commencer à créer des niveaux plus complexes et plus vastes.
 Les nouveaux moteurs tels celui d'Unreal Tournament permettent de créer des endroits très vastes et complexes avec des effets spectaculaires, mais au prix d'une configuration hors norme.
 Par exemple Deus Ex qui utilise ce moteur , a de vastes étendues très détaillées, mais pour avoir une image fluide en 1024x768 il faut un CPU de plus de 600Mhz et au minimum 128 meg de RAM, de plus il faut une carte accélératrice extrèmement performante telle une Geforce 2 GTS par exemple.
 
 Voyons maintenant comment la visibilité est calculée:
 Reprenons notre exemple de tout à l'heure:
J'ai attribué une couleur par node et mis en noir les deux polyèdres solides pour bien visualiser les secteurs de la map
 
 Nous avons vu que BSP découpait la map en secteurs convexes appelés nodes, ces nodes sont bien entendus accolés les uns aux autres et séparés par des cloisons virtuelles appelées portals (portails).
Voici un portal séparant deux nodes:
Ce portal est donc constitué de deux leaf (feuille) chacune appartenant a un node
 
 Un portal est donc une surface de contact entre deux nodes, chaque node a son portal leaf, ce qui fait deux portals leaf à chaque liaison. Le joueur peut passer au travers et il sont bien sûr totalement invisibles.
 Vis va donc vérifier quel node est visible depuis quel autre. Comment va-t-il procéder?, eh bien il va vérifier quel portal peut voir quel autre, il va prendre des points de la surface d'un portal et vérifier si un de ces points voit un autre portal.
Voici un exemple de contrôle de visibilité:
La position 1 ne voit pas la position 2 mais le portal du node bleu voit le portal du node vert et réciproquement, ce qui veut dire que si le joueur se trouve à la position 1 il ne verra pas du tout le node vert, mais celui ci sera tout de même dessiné par le moteur parce que les deux portals se voient.
On remarquera que dans notre exemple il n'y a qu'un seul node qui ne voit pas tous les autres et qui n'est pas vu de tous
En effet le node vert ci dessus ne voit que les deux nodes bleus, et seuls les nodes bleu le voient.
 
Mais parfois tout ne se passe pas parfaitement bien, lors de la division de la map en node de bsp, d'infimes erreurs de calculs à virgule flottante ont lieu.
 C'est à ce moment que le message d'avertissement "Leaf portals saw into leaf" peut apparaître. Ceci arrive parfois et est causé par le fait que deux leaf (feuille) portal d'un même node sont comparés, c'est le plus souvent un bug de VIS . C'est dû au fait que la géométrie est définie avec une précision limitée, il peut y avoir de nombreux calcul avec virgule flottante qui finissent par engendrer un imprécision minime, mais suffisante pour tromper Vis et lui faire croire que ces deux leaf portals peuvent se voir, en réalité ils sont dans le même plan, mais l'imprécision de calcul engendre une légère courbure qui entraine le message d'erreur. Ce genre d'erreur peut être ignoré en général car il n'a pas de conséquence sur le bsp final. C'est souvent la méthode de construction et les formes complexes qui peuvent provoquer ces messages, si on crée un géométrie avec de nombreuses faces sous des angles variables, les calculs seront plus nombreux et les risques d'imprécisions plus grands.
 Voici un exemple de ce type d'erreur:
 
 Le portal vert n'est pas parfaitement dans le même plan que le rouge , ce qui fait qu'ils se voient l'un l'autre. Dans ce dessin l'erreur a été largement exagérée pour mieux voir l'erreur.
 Le portal vert et le rouge appartiennent au même node bleu, il y a une concavité entre les deux portals ce qui engendre le message d'erreur qui nous averti que si deux portals se voient c'est que le node n'est pas convexe.
 Si l'erreur se fait dans l'autre direction , il y aura une convexité entre les deux portals et donc pas de message d'erreur, comme avec l'exemple suivant:
 
 
 Après toutes ces explications, il faut maintenant réfléchir à une question importante, le calcul de visibilité doit-il être effectué partout, y a t-il des endroit où ça n'est pas nécessaire?
 La réponse est OUI , il est bien évident que procéder au calcul de visibilité dans une pièce encombrée de détails de construction est parfaitement inutile car il est clair que la pièce sera visible dans son entier sauf quelques rares endroits, il faut donc trouver un moyen d'empêcher ce calcul dans les endroits très détaillés car ce calcul pourrait prendre des heures, voir des jours.
 En fait il suffit de placer les éléments de détail dans une func_wall par exemple ou dans une func_illusionary, de cette manière, les nodes correspondants seront ignorés pour le calcul de visibilité.
 Donc une règle d'or : placer les détails du décor dans des func_wall ou similaires.
 Attention toutefois à ce que aucun élément contenu dans une telle fonction ne soit partie intégrante de la coque externe du bsp, sinon on recevra un message d'erreur, il faut bien sûr qu'aucun polyèdre membre d'une telle fonction ne dépasse légèrement vers l'extérieur.
 Une autre possibilité s'offre à nous maintenant si on utilise les outils de compilation de Zoner, on peut placer des polyèdre avec un texture HINT qui sera reconnue par le compilateur et qui bloquera le calcul de visibilité à cet endroit. C'est particulièrement utile si on utilise un générateur de terrain créant de nombreux polyédres avec des angles très variés qui risquent de poser problème au calcul de visibilité et surtout de ralonger celui-ci inutilement.
 
Tests pendant le jeu:
 
Maintenant encore quelque informations sur la façon de vérifier comment le bsp a été découpé et sur le nombre de polygones visibles.
Il est souvent intéressant de vérifier après compilation comment le processus bsp s'est déroulé et si la map a été inutilement découpée à certains endroits, pour ce faire on va entrer des commandes dans la console, il faudra donc démarrer Half-Life avec la ligne de commande : -dev -console
On va choisir le mode de rendu SOFTWARE c'est le seul qui permette de voir les polygones.
On entre après chargement du niveau : r_drawflat 1
De cette façon les textures seront remlacées par un patchwork de couleurs, chaque couleur correspondant à un polygone, on pourra alors voir comment le bsp s'est effectué et vérifier si des découpes inutiles se sont produites.
Pour voir le nombre de polygones visible, il faut entrer la commade : r_speeds 1
On verra alors le nombre de polygone de type world (decor) et de type entité. Lors de la création de HL compte tenu des machines de l'époque (1998) on conseillait de ne pas dépasser 800 world polygons et 6000 entity polygons visibles. Avec les machines actuelles qui ont doublé leurs performances, on peut logiquement doubler ces valeurs sans risquer d'avoir un FPS tros bas .
Avec un Athlon 850 et une Geforce 2 GTS je suis monté jusqu'à plus de 2500 world polygons et plus de 20000 entity polygons sans problèmes.