--------------------------------------------------------------------------------
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)
--------------------------------------------------------------------------------