VBSP, VVIS et VRAD expliqués : les trois étapes de la compilation

La compilation transforme ton VMF en BSP jouable en trois étapes : VBSP construit la géométrie et vérifie qu’il n’y a pas de leak, VVIS calcule ce qui est visible depuis où, et VRAD calcule l’éclairage. VVIS et VRAD prennent la majeure partie du temps. Pour les tests, tu utilises des réglages rapides, pour la sortie une compilation complète.

Vue d’ensemble : qui fait quoi

Les trois programmes vbsp.exe, vvis.exe et vrad.exe se trouvent dans le dossier bin du jeu. Hammer les lance l’un après l’autre quand tu appuies sur F9 et copie le BSP terminé dans le dossier maps. Tout ce que les programmes affichent se retrouve aussi dans un fichier log à côté de ton VMF.

VBSP : géométrie et leaks

VBSP convertit tes brushes en faces, supprime les faces situées à l’extérieur de la map et découpe l’intérieur en visleafs. Il écrit aussi les entités, les props statiques, les overlays et les displacements dans le BSP.

Au passage, VBSP vérifie que la map est étanche. Il inonde l’espace en partant des entités et signale un leak dès qu’il atteint le vide extérieur. Le log affiche alors **** leaked ****, et VBSP écrit un pointfile que tu peux afficher dans Hammer via Map > Load Pointfile sous la forme d’une ligne qui mène au leak. Dans ce cas, aucun fichier de portals n’est créé. Conséquences : VVIS ne peut pas travailler, le moteur dessine toujours toute la map, et l’éclairage n’est calculé qu’en partie. Corriger une erreur de leak montre comment trouver le leak.

Le paramètre -onlyents est utile pour les tests. Il met seulement à jour les entités dans un BSP déjà compilé, sans reconstruire la géométrie. Tu gagnes du temps quand tu n’as modifié que la logique ou des réglages d’entités. Les brushes, y compris ceux des entités brush, restent tels quels. Dans notre test avec le VBSP de GMod, les props statiques ont aussi été mis à jour, les overlays non.

VVIS : visibilité

VVIS lit les portals entre les visleafs et calcule, pour chaque zone, quelles autres zones pourraient être visibles depuis celle-ci. Le moteur se sert ensuite de ce résultat pour décider de ce qu’il doit réellement dessiner.

Tu repères deux phases dans le log : BasePortalVis est un précalcul grossier, PortalFlow le calcul exact, généralement bien plus long. Avant ça, le log indique le nombre de portals. C’est lui qui détermine la durée plus que tout le reste. Beaucoup de petits brushes de monde et de grands espaces ouverts créent beaucoup de portals.

• Avec -fast, VVIS saute le calcul exact. La compilation est rapide, mais le moteur dessine plus que nécessaire en jeu. Ça ne convient pas à une sortie, et les mesures de FPS n’ont alors aucune valeur.
• Si VVIS prend trop de temps, transforme les détails en func_detail et simplifie la géométrie de monde. Pour les grandes zones ouvertes, il existe func_viscluster. Les détails sont dans VVIS prend une éternité.

VRAD : éclairage

VRAD calcule la lumière directe pour chaque face, la fait ensuite rebondir plusieurs fois sur les surfaces et stocke le résultat sous forme de lightmaps. S’y ajoutent des données d’éclairage pour les props statiques et pour les objets mobiles.

Les paramètres les plus importants :

• -fast : calcul rapide, visiblement plus grossier, pour les tests.
• -final : calcul plus précis pour la sortie, nettement plus lent.
• -ldr, -hdr, -both : définit quelle plage de luminosité est calculée. Avec -both, le calcul est fait deux fois.
• -StaticPropLighting, -StaticPropPolys, -textureshadows : meilleur éclairage et ombres plus précises pour les props statiques.

Le temps dépend de la taille de la map, du nombre de lumières et du lightmap scale. De petites valeurs de lightmap scale sur de grandes faces sont une cause fréquente de calculs très longs. Dans le log, tu vois d’abord l’éclairage direct (BuildFacelights), puis les différents rebonds et enfin un tableau qui montre le taux de remplissage des sections de données du BSP. Tout ce qui concerne l’éclairage est traité dans le guide d’éclairage Source Engine.

Réglages pour les tests et la sortie

Dans la fenêtre « Run Map » normale, tu choisis entre « No », « Normal » et « Fast » pour VIS. RAD propose les trois mêmes niveaux dans Hammer++, et le Hammer fourni y ajoute « Faster » et « Final ». Pour BSP, la troisième option est « Only entities » au lieu d’un mode rapide. « Expert » donne accès à des profils prêts à l’emploi et te laisse modifier les paramètres un par un.

Après la compilation finale, il reste deux tâches qui ne font pas partie des trois programmes : générer les cubemaps en jeu et packer le contenu custom dans le BSP. La marche à suivre est décrite dans Packer du contenu custom dans un BSP.

Quand la compilation échoue

Lis le log de haut en bas et cherche la première erreur. Les messages suivants n’en sont souvent que des conséquences. Un leak dans VBSP, par exemple, fait que VVIS ne trouve pas le fichier de portals. Si tu ne lis que le dernier message, tu cherches au mauvais endroit.

Tu peux aussi coller le log dans le Map Scanner. Il détecte les causes racines, les conséquences et les solutions adaptées dans les logs de VBSP, VVIS et VRAD.

Questions fréquentes

Pourquoi VVIS met-il autant de temps ?

La durée dépend du nombre de portals, et celui-ci augmente avec chaque brush de monde qui découpe l’espace. Transforme les détails en func_detail et garde simple la géométrie qui ferme la map. Les grands espaces ouverts coûtent en général plus cher que les intérieurs tortueux.

Puis-je sauter VVIS ou VRAD ?

Pour des tests, oui. Sans VVIS, le moteur dessine toujours toute la map, sans VRAD la map est uniformément claire et sans ombres. Une map publiée a besoin des deux étapes complètes.

Que signifie « leaked » dans le log ?

L’intérieur de la map n’est pas entièrement fermé par des brushes de monde, ou une entité se trouve à l’extérieur. VBSP ne crée alors aucun fichier de portals, et les étapes suivantes ne donnent pas de résultat exploitable. Corrige le leak avant de te pencher sur d’autres erreurs.

Dois-je tout recompiler après chaque modification ?

Après une modification des brushes, oui, car la géométrie, la visibilité et l’éclairage dépendent les uns des autres. Si tu n’as modifié que des réglages d’entités qui n’influencent pas l’éclairage, un passage de VBSP avec -onlyents suffit pour un test. Il ne met à jour ni les overlays ni les brushes, et une sortie demande une compilation complète.