Mapping et Hammer

Guide d’éclairage Source Engine : bien éclairer tes maps GMod

L’éclairage Source Engine expliqué : light, light_spot, light_environment, compilation HDR, lightmap scale, cubemaps et erreurs d’éclairage courantes.

Publié le 8 octobre 20266 min de lecture

Dans le Source Engine, l’éclairage est en grande partie précalculé : le compilateur VRAD calcule des lightmaps à partir de tes entités de lumière et les stocke dans le BSP. Pour les intérieurs, tu places des light et des light_spot, pour le soleil et le ciel un light_environment. Tu compiles ensuite avec VRAD et tu génères en jeu les cubemaps pour les reflets.

Les entités de lumière les plus importantes

Entité	Effet	Usage typique
`light`	Lumière ponctuelle, éclaire dans toutes les directions	Lampes, luminosité de base des pièces
`light_spot`	Cône de lumière avec un angle intérieur et un angle extérieur	Projecteurs, spots de plafond, lampadaires
`light_environment`	Lumière du soleil et du ciel pour toute la map	Zones extérieures
`light_dynamic`	Lumière en temps réel, non précalculée	Lumières mobiles ou vacillantes, à utiliser avec parcimonie
`env_projectedtexture`	Lumière projetée en temps réel avec ombres dynamiques	Accents ponctuels, coûteuse

La luminosité d’une lumière se compose de quatre nombres : rouge, vert, bleu et intensité. Les réglages de falloff définissent à quelle vitesse la lumière s’atténue avec la distance. Les lumières précalculées ne coûtent pratiquement rien en performances en jeu, alors que les lumières en temps réel coûtent quelque chose à chaque image. Construis l’ambiance avec light et light_spot et n’utilise les lumières dynamiques qu’à bon escient.

Soleil et ciel : light_environment et la skybox

Un light_environment éclaire la map à travers toutes les faces texturées avec tools/toolsskybox. Trois valeurs comptent :

Brightness and Color : couleur et intensité de la lumière directe du soleil.
Ambient Color and Brightness : la lumière diffuse du ciel. Elle éclaircit les ombres et décide à quel point les zones sans soleil direct sont sombres.
Pitch et Yaw : la direction d’où vient le soleil.

SunSpreadAngle adoucit les ombres du soleil. La texture de skybox elle-même se règle dans Map > Map Properties. La couleur de la lumière et la direction du soleil doivent correspondre à l’image du ciel, sinon la scène paraît incohérente. L’entité env_sun ne fait que dessiner le halo du soleil dans le ciel et n’éclaire rien.

Si tu veux montrer un paysage lointain, lis le guide de la skybox 3D.

Compiler en HDR ou en LDR

VRAD peut calculer l’éclairage en deux variantes : LDR (plage de luminosité classique) et HDR (plage étendue avec exposition automatique). Les paramètres sont -ldr, -hdr et -both. Sans aucun des trois, le VRAD de GMod ne calcule que le LDR. Dans la fenêtre de compilation normale de Hammer, la case à cocher « HDR » compile les deux.

Le LDR suffit pour des tests rapides.
Pour la sortie, compile avec -both. La map a alors le bon rendu pour les joueurs avec et sans HDR. L’éclairage est calculé deux fois, VRAD met donc d’autant plus de temps.

Dans les maps HDR, env_tonemap_controller pilote l’exposition automatique. Sans lui, c’est la plage d’exposition par défaut du moteur qui s’applique, et elle ne convient pas à toutes les maps. Les lumières ont aussi leurs propres valeurs de luminosité HDR. La valeur par défaut -1 -1 -1 1 signifie que la valeur normale est utilisée. L’enchaînement des étapes de compilation est expliqué dans VBSP, VVIS et VRAD expliqués.

Lightmap scale et qualité des ombres

Le lightmap scale d’une face indique combien d’unités couvre un échantillon de lightmap. La valeur par défaut est 16. Tu la modifies dans l’outil de texture (Shift+A).

Des valeurs plus petites, comme 8 ou 4, donnent des ombres plus nettes mais coûtent de la mémoire, de la taille de fichier et du temps de compilation.
Des valeurs plus grandes, comme 32 ou 64, sont peu coûteuses et suffisent pour les grandes surfaces éclairées uniformément.

Ces paramètres de VRAD améliorent la qualité de la compilation finale :

-final : calcul de la lumière plus précis, nettement plus lent.
-StaticPropLighting : calcule l’éclairage des prop_static par vertex du modèle plutôt qu’en un seul point.
-StaticPropPolys : utilise la forme visible des props pour les ombres au lieu du modèle de collision grossier.
-TextureShadows : tient compte des textures transparentes pour les ombres des props, à condition que les modèles soient inscrits pour ça dans un fichier RAD ou compilés en conséquence. N’a en général d’effet qu’avec -StaticPropPolys.

Des reflets avec env_cubemap

Les surfaces brillantes ne reflètent pas l’environnement réel, mais un panorama capturé à l’avance. C’est à ça que servent les entités env_cubemap :

Place au moins un env_cubemap par pièce ou par ambiance lumineuse, à peu près à hauteur de tête et pas à l’intérieur de la géométrie.
Compile la map et charge-la en jeu.
Tape buildcubemaps dans la console.
Si tu as compilé avec -both, génère les cubemaps une fois pour le LDR et une fois pour le HDR. Entre les deux, bascule avec mat_hdr_level et recharge la map.

Après chaque nouvelle compilation, tu dois générer à nouveau les cubemaps. Les problèmes courants sont traités dans Corriger les reflets des cubemaps.

Erreurs d’éclairage typiques

Fullbright : Tout est uniformément clair et sans ombres. La map ne contient alors aucune donnée d’éclairage. Soit il n’y a aucune entité de lumière, soit VRAD n’a pas été lancé ou s’est interrompu. Vérifie le compile log.
Map trop sombre : Souvent, la valeur Ambient du light_environment est trop basse, ou il manque des lumières d’appoint dans les intérieurs. Des entités light supplémentaires de faible intensité et des surfaces plus claires aident, car les textures claires renvoient plus de lumière.
Bords d’ombre durs, en escalier : Le lightmap scale est trop grossier. Baisse-le sur les faces concernées. Les raccords d’éclairage visibles sur une géométrie de brushes arrondie s’éliminent avec les smoothing groups.
Props noirs : Sans -StaticPropLighting, un prop_static est éclairé en un seul point. Si ce point est dans le noir ou à l’intérieur d’un mur, tout le modèle devient noir. Un info_lighting utilisé comme origine d’éclairage règle le problème.
Trop de light styles : Les lumières qui portent un nom ou un style de clignotement ont besoin de leurs propres lightmaps. Si beaucoup d’entre elles se superposent sur une même face, VRAD émet un avertissement.
Leak : Avec un leak, VVIS ne fournit pas de données de visibilité, et VRAD ne calcule alors que la lumière directe, sans rebonds. Corrige d’abord l’erreur de leak de la map.

Tu peux coller les messages du log de VRAD dans le Map Scanner. Il associe les messages connus à leurs causes et à leurs solutions.

Questions fréquentes

Pourquoi ma map est-elle en fullbright ?

Le BSP ne contient aucune donnée d’éclairage. Ça arrive quand il n’y a pas une seule entité de lumière dans la map, ou quand VRAD a été sauté à la compilation ou s’est interrompu sur une erreur. Place une lumière, compile avec RAD réglé sur « Normal » et vérifie le log.

Combien d’entités light_environment une map peut-elle avoir ?

Une seule. Le soleil et le ciel valent pour toute la map. Plusieurs entités avec des valeurs différentes ne donnent pas un éclairage différent selon les zones.

Dois-je compiler en HDR ?

Non, une map uniquement en LDR fonctionne. Pour une map publiée, -both est le choix sûr, car la map est alors éclairée correctement quels que soient les réglages graphiques des joueurs.

Pourquoi les reflets sont-ils faux après la compilation ?

Les cubemaps n’ont pas encore été générées pour cette compilation. Chaque nouvelle compilation les supprime. Charge la map, lance buildcubemaps et redémarre la map.