Visibilité

GoldSrc/Source(en)

Source 2(en)

edit

This article or section needs to be cleaned up to conform to a higher standard of quality because:

Cet article couvre à l'origine uniquement Source, mais des informations GoldSrc ont été ajoutées, tout comme la plupart des concepts. Néanmoins, beaucoup d'éléments Source ne sont pas suffisants, et les éléments d'optimisation fournis par ZHLT(en) et le standard VHLT(en) ne sont pas mentionnés.

For help, see the VDC Editing Help and Wikipedia cleanup process. Also, remember to check for any notes left by the tagger at this article's talk page.

Sans VIS(en), 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. GorldSrc(en) et Source(en) utilisent tous deux le format BSP(en), basé sur l'implémentation Quake de  John Carmack. Cette page explique comme cela fonctionne et comment l'utiliser.

Feuilles

Feuilles pour un couloir.

L'espace intérieur (i.e., non occupé par un bloc monde(en)) d'une carte BSP est divisée en feuilles(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 blocs(en), les feuilles(en) 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 couteux(en) que de simplement dessiner la scène de manière moins optimale.

Soyez bien conscient que les displacement(en)s, point(en)s et bloc(en)s (incluant Blocs détail) n'affectent pas les feuilles. Créer un bloc monde(en) NODRAW(en) 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.

Note:Les blocs monde avec textures $translucent(en) découpent les feuilles(en).

Attention:Les feuilles ne peuvent pas être générées si votre carte a une fuite(en).

Astuce:Les feuilles sont découpées toutes les 1024 unité(en)s sur le plan xy indépendamment des blocs dans le but de découper les vastes zones. La grille sur Hammer(en) est mise en surbrillance en rouge pour vous assister.

Note:Les feuilles fonctionnent aussi bien verticalement qu'horizontalement. Le ciel est traité comme une extension des pièces et rues.

Réduire le temps de compilation VIS

VVIS(en) (ou VIS(en)/HLVIS(en) sur ) permet de calculer la visibilité entre les feuilles (tandis que VBSP(en) (ou QBSP2(en)/HLBSP(en) 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 bloc monde(en) alignés sur la grille le plus possible. Des dimensions en puissance de 2 restent l'idéal.
• Utiliser de simples bloc monde(en) qui n'ont pas été manipulés par d'autres outils, comme du découpage ou manipulation de sommets.
• Placer des func_viscluster(en)(depuis Source 2007) 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 Skybox 3D(en) pour réduire la taille du ciel, et créer une structure bloc monde(en) sous les displacement(en)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

Visualisation des feuilles sous Hammer

Depuis Source 2007 et sous Hammer++, 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 Source 2006 et antérieur devront utiliser l'application glview(en).

Astuce:Pour plus clarté, utiliser auto visgroup(en)s pour supprimer les objets de votre carte qui ne bloquent pas la visibilité - généralement tout sauf les bloc monde(en), ainsi que les "Tool Brushes," "Eau" et "Displacements"

Pour visualiser les feuilles en jeu, il existe une variable de console(en) nommée "mat_leafvis(en)". mat_leafvis 3 surlignera toutes les feuilles dans la PVS(en), tandis que mat_leafvis 1 n'affichera les contours de la feuille où la caméra se trouve actuellement. (Cette variable est un cheat(en))

Vous pouvez aussi inspecter la géométrie en utilisant la variable mat_wireframe(en). mat_wireframe 1 affichera un rendu de type fil de fer pour savoir comment les polygones sont dessinés dans la PVS(en). (Cette variable est aussi un cheat(en))

• 

  Feuilles en jeu

• 

  Rendu fil de fer en jeu

Indicateurs

Article principal Hint brush(en)

Toutes les feuilles dessinées en même temps sans indicateurs.

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 texturée(en) à 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.

Astuce:C'est une bonne pratique d'utiliser des indicateurs pour séparer des zones couteuses de la même feuille. En faisant cela, le temps d'affichage des zones couteuses en sera réduit.

Blocs détail

Comme décrit précédemment, les feuilles sont modelées autour des blocs monde(en). 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 func_detail(en). C'est une entité interne(en) qui indique aux compilateurs d'ignorer le bloc lors du calcul de visibilité, sans affecter son comportement. Il n'est pas rare de l'utiliser sur de grands blocs, qui passent alors en détail(en).

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 toolsnodraw (Dans ) ou une texture NULL (Dans ). 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 lightmap(en) 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 Brush(en).

Astuce:(Dans ) VBSP combine tous les func_details en un seul à la compilation. Les faces des func_details qui sont épurés n'ont pas besoin d'être texturés en Nododraw.
(Dans ) HLCSG(en) supprime les faces des func_details qui partagent un niveau de détail, ou qui sont épurés avec un niveau de détail inférieur.

Areaportals (seulement dans Source)

Main article:  Areaportal

Teal lines indicate good areaportal locations.

In the image to the left all of the leaves can see each other, and this time there is very little that hint brushes can achieve.

In this situation we should create Areaportal(en)s at the mouth of selected openings. These make the engine perform the per-object line of sight testing that Carmack created the BSP/visleaf system to avoid—but with that system behind it, and with the calculations restricted to when the camera looks through the areaportal, performance can be gained if one blocks enough objects from view.

The image has areaportal locations marked over each mouth, but placing all four would likely hinder performance more than help it. Your strategy depends on the relative cost(en) of each area—in most situations, creating the large areaportal to the right and leaving the corridors alone would be best.

(It is possible to use hints to reduce visibility in this situation, but only with a ridiculous number of them at very precise angles, which impacts performance in its own way. If you can't see across a room for hint brushes, then you should be using an areaportal!)

Astuce:Areaportals are also useful because they can be closed to completely and cheap(en)ly block visibility past them. It's a good idea to attach an areaportal to every window-less door in your map, so that they can automatically perform this function.

Note:Areaportals make no account for objects in front of them.

Attention:Areaportals can cause problems if placed incorrectly, so be sure to read about them carefully(en).

Occluders (seulement dans Source)

Sometimes you want to block visibility in a way that visleaves simply don't allow: consider a destructible free-standing wall behind which are standing several expensive character models. You don't want to draw the models if they aren't being seen, but without any connected world brushes to work with except the ground you can't do it by separating leaves.

An Occluder(en) is the tool for the job. It's a brush that hides models (not brushes, alas) behind it when enabled, in a similar manner to an areaportal hiding things that aren't behind it. For obvious reasons, it should be entirely contained inside an opaque object.

It is possible, however, to convert some brushes into models with something like Propper(en). That way, it's possible to hide more models with an occluder. This should be done on detail(en) brushes, which aren't used for cutting visleaves(en).

Draw Distance

If you are dealing with a large open area without any cover at all then there isn't a lot you can do but remove detail or employ fog(en) to disguise a low draw distance. Configure draw distance with Map > Properties > Far z_clip plane.

Draw distances can also be applied selectively to props, even prop_static, with the Start Fade Dist/Pixelsand End Fade Dist/Pixelskeyvalue(en)s. As the names suggest, these values can represent either distance in units or pixels on-screen as per theScreen Space FadeKV.

Astuce:In fact, all entities with a model can be faded, as well as overlays(en). These keyvalues are !FGD for most of these entities, however.

If you enter fade distances on props, it’s a good general rule to have the difference between the two numbers (start and end) be 200. It looks pretty good, and the larger that number is, the longer the model incurs an increased cost to render. Fading models do not go through the fast path and incur additional sorting cost.

func_lod is a special brush entity that can fade out. You can't use any brushes tied to it as any other entity, however!

Sample Maps

• sourcesdk_content\hl2\mapsrc\
  • sdk_func_detail.vmf
  • sdk_hints.vmf
  • sdk_occluders.vmf

See also

• Skybox Optimization(en)