--------------------------------------------------------------------------------

 

6 Eclairer la map (LIGHT Stage)

 

      6.1 Nouveautés apportées par Q3Map2

 

Cette section est consacrée entièrement à l'étape LIGHT de Q3Map2. C'est dans ce domaine que le compilateur se démarque le plus de son prédécesseur.

 

Rappel : Quake 3 Arena supporte deux types d'éclairages : l'éclairage par Lightmap (Haute-Qualité) et par Vertex (Basse-Qualité), principalement pour que le hardware un peu dépassé à la sortie du jeu puisse suivre tant bien que mal ;-)

Pour ceux qui étaient familiers avec le switch -vlight, celui ci disparait purement et simplement car il est désormais "intégré" lors de la compilation avec -light.

Une map compilée par Q3map2 est rendu de manière identique que les réglages graphiques soient en mode "lightmap" ou "vertex" (finies les maps "fullbright" en mode vertex avec q3map2).

 

            6.1.1 -collapse

 

-collapse se charge de fusionner les lightmaps bruts s'ils sont quasi-identiques (différence maxi tolérée : 0,0025). Il est activé par défaut. Les gains au niveau du temps de compilation sont appréciables.

Vous pouvez désactiver la fusion par le switch -nocollapse.

 

            6.1.2 -debug

 

Active le mode debug des lightmaps.

 

            6.1.3 -debugunused

 

Les pixels lightmaps non utilisés sont colorés en rose.

 

            6.1.4 -export

 

Les lightmaps sont exportés en images .tga.

Utilisation : q3map -export [-v] <nomdelamap>

 

            6.1.5 -import

 

Les lightmaps sont importés à partir d'images .tga

Utilisation : q3map -import [-v] <nomdelamap>

 

A propos de l'import/export des lightmaps :

 

L'export peut aussi être utilisé comme une option supplémentaire à -light, pour calculer l'éclairage de la map et exporter les lightmaps générés en appelant une seule fois Q3Map. Ca évite d'avoir à retaper la ligne de commande.

Par cette méthode, l'import/export des lightmaps est automatique en utilisant les fichiers image maps/nomdelamap/lightmap_nnn.tga, où nnn est un nombre entier généré suivant une logique qui m'échappe actuellement.

 

Vous DEVEZ faire un -light avant d'utiliser le -export, alors vous pourrez faire un -import une fois que vous aurez bidouillé les .tga. Evidemment, si vous recompilez la map, les lightmaps exportés seront invalides. C'est à dire que si vous changez le BSP, alors les lightmaps ne correspondront plus et c'est baisé. L'allocation des lightmaps est la dernière chose qui ait lieu, c'est à dire que si vous recompilez la map même si vous n'y avez pas touché, les lightmaps seront quand même réarrangés différemment.

 

            6.1.6 -filter

 

-filter effectue un flou Gaussien sur les ombres, et applique au lightmap un filtre en boîte 3x3 (similaire au flou de Photoshop). Il n'a pas d'effet sur les sommets des lightmaps, car il ne peut récupérer aucun échantillon en-dehors du sommet. -filter fait la moyenne d'un luxel (pixel lightmappé) avec ses trois voisins directs. Pour rappel, le paramètre

-extrawide fait la même chose, mais -filter est légèrement plus performant.

 

            6.1.7 -nocollapse

 

Les lightmaps identiques ne sont plus fusionnés. (voir -collapse pour les explications techniques).

 

            6.1.8 -normalmap

 

Les lightmaps sont colorés suivant l'orientation de la surface sur laquelle ils sont appliqués. C'est idéal pour débugger une map éclairée par l'ombrage Phong.

 

            6.1.9 -shade

 

L'ombrage Phong est activé. Il n'est néanmoins utile que sous certaines circonstances, en se basant sur des shaders spécialement configurés.

 

            6.1.10 -shadeangle <degré>

 

Ce switch active également l'ombrage Phong, en vous permettant également de spécifier l'angle d'incidence de la lumière déterminé par l'argument <degré> (ex: -shadeangle 45 et l'angle d'incidence sera de 45°).

Attention, -shadeangle est parfois capricieux.

 

            6.1.11 -super <entier>

 

Au sens strict, ce paramètre effectue un supersampling arbitrairement ordonné des lightmaps suivant la grille (ah vous êtes bien avancés là !) -super remplace les switchs -extra et -extrawide. (-extrawide est de toutes façons handicapé d'un bug). Ce remplaçant effectue un réel supersampling à <entier> passes (-super 2 est équivalent à -extra, -super 2 -filter est équivalent à -extrawide), plutôt que le filtre bizarre made in -extrawide. L'argument de -super doit obligatoirement être supérieur ou égal à 2.

 

            6.1.12 -supersample <entier>

 

Paramètre identique à -super.

 

Rappel : Qu'est ce qu'un lightmap ? <<<< A mettre dans le lexique

 

Un lightmap, c'est tout simplement une texture couleur 24bits un peu spéciale qui est appliquée sur chaque polygone. Pour simplifier encore plus, le lightmap agit comme une sorte de masque : plus celui-ci est opaque et moins la lumière passe, la surface sur laquelle le masque est appliqué est donc éclairée en conséquence. Pour tous les types de lumières, il y a un système de mélange (le blend - crucial à comprendre pour réussir vos shaders) où la couleur RGB de la texture du polygone est multipliée avec celle du lightmap.

 

Le LIGHT Stage se charge de générer chaque pixel lightmappé (luxel) de chaque lightmap.

(Pour des informations exhaustives sur le LIGHT Stage, lisez le tuto de SPoG)

 

            6.1.13 -thresh <décimal>

 

-thresh indique le seuil de la récursivité de la subdivision des triangles. Les valeurs possibles vont de 0.1 à 1.0 (valeur par défaut: 1.0).

Plus la valeur est faible, plus le temps de compilation augmente, pour un éclairage beaucoup plus précis et vice-versa.

 

Le pavé technique en rapport:

Pour déterminer la perpendiculaire au luxel (pixel lightmappé) pour l'ombrage phong et le bumpmapping, Q3Map2 procède comme ceci :

 

Soit T le seuil de récursivité définit par -tresh

Soit N la taille du sample définie par -samplesize (16x16 par défaut)

Soit R la taille de la plus petite arète d'un triangle subdivisé

 

Les triangles de la map sont subdivisés de manière récursive (ils deviennent de plus en plus petits) jusqu'à ce que R < T x N

 

De faibles valeurs de -tresh entraînent un ombrage phong et un bump-mapping plus précis, puisque plus la valeur est basse, plus les triangles sont petits et donc nombreux, les samples pour un luxel sont donc plus nombreux, les normales (pour le bump-mapping) générées sont alors plus précises, et finalement l'ombrage devient plus précis.

 

 

--------------------------------------------------------------------------------

 

      6.2 Les autres paramètres

 

Les paramètres suivants sont issus de Q3Map 1.x

 

            6.2.1 -bounce <N>

 

Tout le monde en parle, et en fait peu de personnes savent de quoi il s'agit. Le bounce, c'est tout simplement le calcul des rebonds de la lumière sur les surfaces. Par exemple, un mur éclairé par une forte lumière rouge va également émettre de la lumière pour peu que le paramètre -bounce soit au moins égal à 1.

Il n'y a pas de limite pour le nombre entier N. De plus, à chaque passe le BSP est re-généré, donc vous pouvez abandonner la compilation en plein bounce sans pour autant perdre la map.

 

La lumière réfléchie est de la couleur du lightmap (vertex en cas de vertex lighting) multiplié par la couleur de la texture, sous-samplée [to a certain granularity ] sur chaque surface éclairée.

 

Vous pouvez utiliser le keyword q3map_lightimage dans un shader pour outrepasser les valeurs de la couleur réfléchie.

 

            6.2.2 -bouncegrid

 

Les entités (static models, items...) seront éclairées par la méthode du bounce.

 

(a foutre dans le lexique)

Le lightgrid est utilisé pour l'éclairage des models et des entités du jeu, comme les models de joueurs, les boîtes de munitions, les powerups, ... Le lightgrid a un effet sur l'éclairage par vertex (reste à savoir lequel).

 

            6.2.3 -fast

 

Peu utilisé pour les compiles finales sous Q3map 1.x pour cause de résultat assez moche, -fast nous revient tout frais avec Q3map2 et devient alors très acceptable pour une compile destinée à la release de la map (surtout s'il s'agit d'une map en extérieur avec un terrain), du moment que vous lightez la map de manière appropriée.

 

Concrètement, le compilateur utilise un système d'enveloppage de lumières et cela permet de zapper certaines sources de lumières, entrainant un gain de vitesse pouvant aller jusqu'à 50 fois plus vite.

 

      Enables light envelopes for area lights, speeding light up by 50x or more on

      some maps. Has the side effect of dimmer maps with large numbers of dim surface

      lights.

 

This enables light envelopes for area lights, and enables light culling.

 

            6.2.4 -fastgrid

 

Même chose que -fast, mais seulement appliqué calculs du lightgrid (éclairage dynamique des entités)

 

            6.2.5 -fastbounce

 

Accélère le bounce. Peu utilisé.

 

            6.2.6 -cheap

 

Paramètre assez intéressant permettant un gain de temps sur la compilation sur les maps très éclairées. Il stoppe en effet le calcul de la lumière pour un sample (taille par défaut : 16x16 pixels, réglage via -samplesize) lorsqu'il dépasse les valeurs RGB (255, 255, 255). Attention, ce switche crée parfois des artefacts bizarres sur les maps comportant énormément de lumières saturées et colorées. N'utilisez pas ce switch si vous bouncez la map si vous voulez préserver touts les lumières émises.

 

            6.2.7 -cheapgrid

 

Même chose que -cheap, mais seulement appliqué calculs du lightgrid.

           

            6.2.8 -area <N>

 

Redimensionne l'intensité des lumières de surface (textures ayant un shader du style q3map_surfacelight ou équivalent).

-area 2 multiplie par 2 la puissance émise par les surfacelights.

-area 0.2 la divise par 5.

           

            6.2.9 -point <N>

 

Redimensionne l'intensité des lumières placées par points (clic droit>light dans GTKRadiant)

-area 2 multiplie par 2 la puissance émise par les points.

-area 0.2 la divise par 5.

 

            6.2.10 -notrace

 

Aucune ombre ne sera générée (pas de light tracing), mais la map sera tout de même éclairée. Gain de temps de compilation non-négligeable.

           

            6.2.11 -patchshadows

 

La commande indispensable pour forcer les surfaces courbes à générer des ombres.

 

            6.2.12 -novertex

 

Le vertex lighting est ignoré.

 

            6.2.13 -nogrid

 

Les calculs liés à l'éclairage dynamique des models/entités sont ignorés. (Pas de calcul du lightgrid)

 

            6.2.14 -smooth

 

Actuellement inactif.

 

Ce switch adoucit les ombres en utilisant un anti-aliasing maison. Certains me feront la remarque, le switch -extra fait la même chose; mais -smooth active l'anti-aliasing (par sous-sampling) uniquement sur les pixels ligthmappés qui subissent un ombrage. En conséquence, le temps de compilation est réduit de 60 %, pour des résultats comparables à -extra. Il peut également être combiné avec -filter et -super, pour un sampling en 16 ou 48 passes (à redéterminer).

 

            6.2.15 -extra

 

(extra est obsolète, préferer -super 2)

 

A chaque pixel lightmappé est associé 4 samples (au lieu d'un seul par défaut). La lumière moyenne émise par ces 4 samples est enregistrée comme provenant du pixel lightmappé. Permet d'éviter l'aliasing des ombres dû au switch -fast. Privilégiez toutefois -filter, plus efficace.

 

            6.2.16 -extrawide

 

(extrawide est obsolète, préferer -super 2 -filter)

 

Fonctionne comme -extra, sauf qu'il prend cette fois 12 samples pour créer un luxel (pixel lightmappé).

Il est inutile de mettre à la fois dans votre batch -extra et -super 2 puisque ce dernier est prioritaire par rapport à -extra.

 

            6.2.17 -samplesize <N>

 

-samplesize permet de fixer la taille d'un pixel lightmappé. Par défaut, leur taille est de 16x16. L'augmenter allègera votre temps de compilation, et évidemment la diminuer l'augmentera très fortement. Evidemment, si vous l'augmentez, cela diminuera la précision de l'éclairage de la map, et vice-versa.

Plutôt que de tenter un -samplesize 1 qui aura pour effet de mettre 2 jours à compiler un simple cube, vous pouvez jouer avec le switch -filter qui anti-aliasera les ombres, l'effet in-game sera très similaire.

 

            6.2.18 -border

 

Crée une bordure autour de chaque lightmap, à des fins de debug.

           

            6.2.19 -nosurf

 

Les details brushes et les surfaces courbes ne génèrent pas d'ombres (NON TESTE)

 

      Disables surface tracing (detail brushes and patches) for shadow calculation.

 

            6.2.20 -dump

 

Copie les lumières générées par le bounce dans des fichiers préfabs numérotés (maps/<map>_bounce_<n°bounce>.pfb)

 

--------------------------------------------------------------------------------