VVIS prend une éternité ? Comment réduire ton temps de compilation

Q: func_detail ralentit-il la map en jeu ?

Non, tant que tu l’utilises correctement. En revanche, func_detail ne bloque pas la visibilité. Les murs qui séparent deux pièces doivent donc rester des world brushes, sinon le moteur affiche les deux pièces en même temps.

VVIS prend une éternité si ta map crée trop de portals. Réduis-les avec func_detail, des pièces plus simples et des hints ciblés, sans -fast à la publication.

Publié le 8 octobre 20266 min de lecture

VVIS tourne pendant des heures quand ta map contient trop de visleafs et de portals. La cause la plus fréquente : de la géométrie de détail construite en world brushes. Transforme en func_detail tout ce qui ne bloque pas la vue sur une grande surface. Le nombre de portals diminue et le temps de calcul baisse en général de façon spectaculaire.

Ce que VVIS calcule réellement

VBSP découpe l’intérieur de ta map en visleafs. Ce sont des portions d’espace convexes, délimitées par les faces des world brushes. Partout où deux visleafs se touchent, un portal est créé. VVIS calcule ensuite quels visleafs peuvent se voir à travers ces portals. En jeu, le moteur utilise ce résultat pour ne pas afficher les zones qui ne sont pas visibles.

L’effort n’augmente pas de façon régulière avec la taille de la map. À chaque portal supplémentaire, le nombre de combinaisons à vérifier croît de manière disproportionnée. C’est pourquoi un seul hall mal construit peut coûter plus de temps que tout le reste réuni. L’article sur VBSP, VVIS et VRAD explique comment les trois outils de compilation s’articulent.

Lire le nombre de portals dans le log

Au démarrage, VVIS affiche deux nombres avant que le calcul proprement dit ne commence. L’exemple suivant montre la présentation :

 842 portalclusters
2302 numportals
BasePortalVis:       0...1...2...3...4...5...6...7...8...9...10 (3)
PortalFlow:          0...1...2...3...

numportals est ta mesure la plus importante. Il n’y a pas de seuil fixe, car le temps de calcul dépend aussi du processeur et de l’agencement des pièces. Ce qui compte, c’est la comparaison : note le nombre avant une modification, puis après. S’il baisse nettement, tu es sur la bonne voie.

La phase longue, c’est PortalFlow. Tant que de nouveaux chiffres y apparaissent, VVIS travaille encore et n’est pas bloqué. L’article lire un compile log montre comment interpréter les autres lignes.

Pourquoi trop de portals sont créés

Détails en world brushes : Chaque face d’un world brush peut découper davantage l’espace. Piliers, marches d’escalier, encadrements de fenêtres, moulures, rambardes et meubles faits de brushes produisent ainsi une multitude de minuscules visleafs.
Formes inclinées et arrondies : Cylindres, arches et brushes pivotés découpent l’espace selon des angles particulièrement défavorables.
Grandes zones ouvertes : Dans un vaste espace extérieur, presque tous les visleafs se voient entre eux. VVIS doit quand même vérifier chaque combinaison.
Espace creux inutile : Une boîte géante autour de la map ou d’immenses volumes d’air au-dessus de la zone de jeu augmentent le volume à découper.
Trop de hints : Chaque hint brush ajoute des découpes, et donc des portals.

Les solutions par ordre d’efficacité

Convertir les détails. Sélectionne les brushes, appuie sur Ctrl+T et choisis func_detail. La règle de base : ne reste world brush que ce qui rend la map étanche ou bloque la vue sur une grande surface, c’est-à-dire les murs extérieurs, les sols, les plafonds et les cloisons entre les pièces.
Simplifier l’enveloppe. Construis les pièces avec des world brushes droits et simples, et place la forme visible devant, en func_detail. Les murs arrondis et les arches n’ont jamais leur place dans la géométrie world.
Utiliser des props et des displacements. Les modèles et les displacements ne découpent pas l’espace. Construis le terrain en displacement, avec en dessous un brush simple en tools/toolsnodraw.
Regrouper les zones ouvertes. Avec func_viscluster, tu marques un volume dans lequel tout voit tout de toute façon. VVIS considère les visleafs qu’il contient comme mutuellement visibles et évite de les vérifier un par un.
Placer les hints de façon ciblée. Un hint brush porte tools/toolshint sur la face de découpe et tools/toolsskip sur tous les autres côtés. N’en place un que là où une découpe précise améliore vraiment la visibilité, par exemple à l’angle d’un couloir.
Vérifier le résultat. Via Map → Load Portal File, Hammer affiche les portals de la dernière compilation. En jeu, mat_leafvis 1 montre le visleaf dans lequel tu te trouves ; la commande nécessite sv_cheats 1.

Pour l’étape 1, garde en tête que func_detail ne rend pas la map étanche. Si tu convertis un mur extérieur par erreur, VBSP signale un leak. L’article corriger l’erreur de leak explique quoi faire dans ce cas.

Ce que fait -fast et quand l’utiliser

Avec le paramètre -fast, VVIS saute le calcul précis et ne fournit qu’un résultat approximatif. Dans Hammer, cela correspond au réglage « Fast » sous « Run VIS ». La compilation se termine vite, mais en jeu le moteur considère comme visible bien plus que ce qu’on peut réellement voir. Le framerate en pâtit.

Réglage	Adapté pour	Inconvénient
VVIS désactivé	Tests rapides de la géométrie et de la logique	Aucune donnée de visibilité, tout est affiché, VRAD ne calcule que la lumière directe
`-fast`	Tests de l’éclairage et de l’aspect visuel	Visibilité approximative, framerate moins bon
Calcul complet	Publication et tests de performances	C’est le plus long

Une map que tu publies ou vends a besoin du calcul complet. Si elle ne se termine dans un délai raisonnable qu’avec -fast, c’est le signe d’un problème de structure, pas une raison de garder le raccourci. Tu trouveras d’autres mesures pour le framerate dans l’article optimiser les performances d’une map GMod.

Si VVIS reste long malgré tout

Compile des sections séparées avec le cordon tool et compare numportals. Tu repères ainsi la zone qui produit le plus de portals.
Charge le fichier de portals dans Hammer et cherche les endroits où les lignes deviennent très denses. On y trouve presque toujours de la géométrie de détail oubliée.
Vérifie si le log contient aussi des avertissements ou des erreurs. Tu peux coller un compile log dans le Map Scanner. Il détecte les causes, les erreurs en cascade et les solutions adaptées dans les logs VBSP, VVIS et VRAD.

Questions fréquentes

Combien de temps VVIS devrait-il prendre ?

Il n’y a pas de valeur fixe. Une map construite proprement est en général terminée en quelques minutes, et les très grandes maps demandent plus de temps en proportion. Si VVIS tourne pendant des heures, la raison est presque toujours la géométrie et non le matériel.

Puis-je simplement sauter VVIS ?

Pour des tests rapides, oui. Pour une publication, non, car sans données de visibilité le moteur affiche en permanence la map entière. Sur les maps plus grandes, le framerate s’effondre alors.

Les areaportals raccourcissent-ils le temps de VVIS ?

Non. Les areaportals agissent à l’exécution et masquent en jeu les zones qu’on ne peut pas voir à travers une ouverture. Ils améliorent le framerate mais ne règlent pas un problème de compilation.

func_detail ralentit-il la map en jeu ?

Non, tant que tu l’utilises correctement. En revanche, func_detail ne bloque pas la visibilité. Les murs qui séparent deux pièces doivent donc rester des world brushes, sinon le moteur affiche les deux pièces en même temps.