Fr/VIS optimization

Sans , tout ce qui est dans une carte est dessinée en permanence, indépendamment du fait que le joueur puisse le voir ou non, ce qui réduit les performances du jeu (et sa fréquence d'affichage). Très clairement, la liste de objets à afficher doit être découpée, mais comment ? Cela prendrait beaucoup trop de temps pour déterminer si un objet ou une surface peut être vu plutôt que les générer en premier lieu!
Les moteurs de jeux doivent faire un compromis. et utilisent tous deux le format , basé sur l'implémentation de . Cette page explique comme cela fonctionne et comment l'utiliser.
==Feuilles==
L'espace intérieur (i.e., non occupé par un ) d'une carte BSP est divisée en . La visibilité entre ces volumes 3D est calculée au moment où la carte est compilée, et embarquée dans le fichier BSP pour utilisation par le moteur. Tout comme les , les sont toujours convexes.
L'image ci-contre à gauche montre comment les feuilles devraient être générées sur un couloir en U (un découpage blanc a été ajouté pour plus de lisibilité). Il n'y a pas de ligne de mire entre les feuilles 1 et 3. Par conséquent lorsque la caméra est dans l'une de ces feuilles, le contenu de l'autre feuille n'est pas généré. Ce calcul très simple consiste à consulter un tableau de visibilité.
Il y a cependant un problème avec la feuille 2. Le contenu des 3 feuilles est généré lorsque la caméra est à l'intérieur de celle-ci, mis à part l'élimination des objets hors champ, même si le mur de gauche bouche complètement la vue. Il existe des outils permettant de surmonter ceci, que nous allons bientôt aborder. Gardez bien à l'esprit que dans beaucoup de situations, résoudre ce problème sera plus que de simplement dessiner la scène de manière moins optimale.
Soyez bien conscient que les s, s et s (incluant Blocs détail) n'affectent pas les feuilles. Créer un si cela pose problème: il est assez courant que des displacements soient créés comme des 'skins' détaillés par dessus un bloc de structure, par exemple.
===Réduire le temps de compilation VIS===
 (ou / sur ) permet de calculer la visibilité entre les feuilles (tandis que (ou / les crée). Cela ne devrait prendre que quelques minutes pour ce calcul, y compris sur des cartes de grande envergure. Si ce n'est pas le cas, vous devriez contrôler les points suivants. Même si ce n'est pas le cas, cela reste de bonnes pratiques !
* Utiliser des Blocs détail de la bonne manière.
* Conserver les alignés sur la grille le plus possible. Des dimensions en puissance de 2 restent l'idéal.
* Utiliser de simples qui n'ont pas été manipulés par d'autres outils, comme du découpage ou manipulation de sommets.
* Placer des sur de vastes zones avec une bonne visibilité. Les feuilles à l'intérieur se verront entre elles.
* Eviter de créer de grandes zones que le joueur ne verra pas, ou n’interagira pas avec dans un premier temps, dans la mesure du raisonnable. Utiliser une pour réduire la taille du ciel, et créer une structure sous les s.
Souvenez-vous que le temps de compilation VIS et les performances en jeu sont deux choses bien différentes. Il est préférable de supporter un long temps de compilation dans la mesure où le raccourcir compromet les performances.
===Contrôler les feuilles===
Depuis et sous , Hammer possède une fonction permettant de visualiser les feuilles de la carte sur la vue 3D: Map > Load Portal File. Cela permet d'afficher les arêtes sous forme de lignes bleues. C'est un outil fantastique d'apprentissage. Vous pouvez en effet compiler la carte sans VIS ni RAD (puis recharger le fichier portal pour rafraîchir l'affichage), vous observerez les changements très rapidement.
Les utilisateurs de et antérieur devront utiliser l'application .
Pour visualiser les feuilles en jeu, il existe une nommée "". mat_leafvis 3 surlignera toutes les feuilles dans la , tandis que mat_leafvis 1 n'affichera les contours de la feuille où la caméra se trouve actuellement. (Cette variable est un )
Vous pouvez aussi inspecter la géométrie en utilisant la variable . mat_wireframe 1 affichera un rendu de type fil de fer pour savoir comment les polygones sont dessinés dans la . (Cette variable est aussi un )
Feuilles en jeu.png|Feuilles en jeu
Wireframe en jeu.png|Rendu fil de fer en jeu
==Indicateurs==
Article principal 
Malheureusement les feuilles ne fonctionnent pas toujours aussi bien que dans notre premier exemple. Prenez comme exemple le plan situé à gauche (en pratique ce serait configuré comme sur le premier plan, mais mettons le de coté pour l'instant): les feuilles peuvent toutes se voir, menant à l'affichage de toute la zone en une seule fois pour de mauvaises raisons. C'est là qu'interviennent les indicateurs (hints en anglais).
Un indicateur (ou hint) est une face de bloc à l'aide d'un matériau tools\toolshint, qui découpe les feuilles en deux (les faces d'un bloc qui ne devraient pas être découpés doivent être texturées avec tools\toolsskip). Dans notre exemple, nous placerions un indicateur où se trouvent les lignes violettes, ce qui aura pour effet de découper les feuilles 1 et 3 sur le même principe que notre premier cas.
Il n'est pas possible de fusionner des feuilles ensemble, ce qui fait qu'il y aura 3 feuilles séparées sur la partie droite. Heureusement ce n'est pas un gros problème.
==Blocs détail==
Comme décrit précédemment, les feuilles sont modelées autour des . Mais si vous ne souhaitez pas qu'un bloc monde fasse cela ?
Si vous avez un bloc qui peut être vu en permanence (e.g. un socle de statue ou un mur autoportant), il n'y a pas de raison de créer des feuilles supplémentaire autour.
Dans ce cas de figure, vous utiliserez . C'est une qui indique aux compilateurs d'ignorer le bloc lors du calcul de visibilité, sans affecter son comportement. .
== Surfaces Nodraw==
Si un joueur ne peut pas voir une face d'un bloc sans tricher ou être un spectateur, il est recommandé d'apppliquer le matériau ou une texture . Nodraw supprime la face entière lorsque la carte est compilée sans affecter la visibilité, ce qui réduit à la fois le temps de rendu, et la taille du fichier (la n'ayant pas besoin d'être calculée).
Vous n'avez pas besoin d'appliquer la texture Nodraw aux faces qui touchent le vide (i.e., en dehors de la carte) ou les faces d'un bloc liées à la même entité (le monde étant une grande entité). Consultez .
==Areaportals ==
Article principal 
Sur l'image de gauche, toutes les feuilles peuvent se voir entre elles, et le matériau hint ne pourra pas y faire grand chose.
Dans ce cas de figure, nous devrions créer des s à l'ouverture des entrées. Cela permet au moteur de réaliser les tests de vue par objet que Carmack a créé via le système BSP/vislead. Avec les restrictions de calcul lorsque la camera regarde à travers les aeroportals, des gains de performance peuvent être réalisés si cela retire suffisamment d'objets de la vue.
L'image a des aeroportals marqués sur chaque ouverture, mais les placer tous les 4 diminuerait les performances plutôt que de les augmenter. La stratégie dépend du de chaque zone - dans la plupart des cas. Le mieux serait de créer un grand aeroportal à droite et laisser les autres couloirs vides.
(Il est possible d'utiliser des indicateurs (hint) pour la visibilité dans cette situation, mais en faible nombre et à des angles très précis. Si vous ne pouvez pas voir à travers une pièce en utilisant des indicateurs, vous devriez alors utiliser un aeroportal)
==Masques ==
Parfois vous souhaitez bloquer la visibilité alors que les ne le permettent pas. Si on considère un mur autoportant destructible derrière lequel se trouvent des modèles de personnages couteux en temps de calcul. Vous ne souhaterez pas dessiner ces modèles s'ils ne sont pas vu, mais sans des blocs monde connectés (à part le sol), vous ne pourrez pas le faire en séparant les feuilles.
Un (occluder en anglais) est l'outil nécessaire. Il s'agit d'un bloc qui cache les modèles (et non les blocs) derrière lui lorsque c'est activé. A la manière d'un qui cache des choses qui ne sont pas derrière. Pour des raisons évidentes, cela devrait être positionné à l'intérieur d'un objet opaque.
Il est cependant possible de convertir des blocs en modèles avec des {L|Propper}}. De ce fait, il est possible de cacher davantage de modèles avec un masque. Cela devrait être fait sur blocs qui ne servent pas à couper des feuilles.
== Distance de rendu ==
Si vous travaillez sur zone très vaste sans aucune obstruction, vous ne pourrez pas faire grand chose mis à part supprimer des détails ou utiliser des pour permettre un affichage de faible distance.
Les distances de rendu peuvent être appliquées individuellement sur les props, y compris les via les propriétés Start/End Fade Pixels. Comme les noms le suggèrent, ces valeurs représentent les distances en unités ou pixels à l'écran à partir de laquelle l'objet commence à disparaitre (fondu) jusqu'à son invisibilité totale.
{{tip|En réalité, toutes les entités avec modèle peuvent être fondus, tout comme les . Ces valeurs clés sont présentes () sur la plupart des entités.
Si vous utiliser les distances de rendu sur les props, on règle en général la différence des distances (entre début et fin) à 200. Cela permet d'obtenir un rendu correct, et plus la différence sera importante, plus le cout en calcul le sera également. Le fondu des modèles n'est pas ce qu'il y a de plus optimisé.
 est une entité bloc spéciale qui permet de gérer un fondu. Vous ne pourrez cependant pas utiliser des blocs liés à celui-ci.
= Voir aussi =
*