#Tutorial
Beaucoup de Tutoriaux pour q3map2




Sommaire:

Introduction
Réaliser un terrain Lightmappé
Utiliser le cel-shading
Décompiler une map
Créer un effet de vitrail
Utiliser le bump-mapping
Tirer parti des AntiPortals
Ajouter un nouveau Soleil
Les portal skies
Le FogHull
Les Lightstyles
Le Phong Shading
Auto Models Distribution
Ajouter de la fourrure !
Les AlphaMods
Les Decals
L'Alpha Shadowing

Introduction

Ce petit groupement de tutorials va vous permettre d'utiliser différentes features offertes par q3map2.
Les tutorials sont parfois très courts, et ne nécessitent pas d'être bac+5 pour les comprendre. Ou pas.
Avant de paniquer au moindre problème, vérifiez que les shaders que vous utilisez se trouvent bien dans le fichier shaderlist.txt et que les chemins d'accès sont corrects.


Retour en haut

Réaliser un terrain Lightmappé

Vous n'êtes pas sans savoir que jusqu'ici, le système de terrain de Quake 3 ne pouvait être éclairé que par la sommaire et approximative méthode du vertex lighting. Q3map2 permet de contourner cette limitation.

Cette méthode est une sorte de hack, et est donc soumise à des restrictions. Les effets de certains shaders comme l'environment mapping (tcGen environment) seront bizarres à cause des normales ( = perpendiculaires) "en biais" des sommets des polygones qui composent la surface du terrain. C'est malheureusement nécessaire pour activer les lightmaps sur une portion de map non plane.

Avant de commencer, toutes les textures qui composeront votre terrain devront avoir le mot-clé shader q3map_terrain. (Généralement, vous avez deux shaders : textures/common/terrain et textures/common/terrain2 qui se trouvent dans le fichier common.shader).
Petit rappel pour la création de vos terrains :
Vous avez deux types de shaders qui se distinguent par leur suffixe : l'un se termine en _X (où X est un entier), l'autre en _XtoY (X et Y entiers). Le second se distingue du premier en opérant un mélange entre deux textures différentes pour adoucir les changement de textures du terrain. De base, cela se fait entre deux shaders, mais les plus Casse-cou/Caskou (OMG la pv joke) d'entre vous tenteront avec 3 textures, voire 4. Plus ils y en a, plus c'est long puisqu'il faut préparer les shaders de transition pour chaque texture. Notez qu'EasyGen peut s'en charger, mais il vous faudra retoucher les shaders derrière.

Voyons maintenant comment s'y prendre :
// Etape 1 : Shader de Terrain référence
textures/terrain/texture_base
{
	// Obligatoire
	q3map_tcGen ivector ( 256 0 0 ) ( 0 256 0 )
	// projette la texture toutes les 256 unités suivant les axes X et Y
	q3map_lightmapaxis z
	// projette le lightmap le long de l'axe Z (haut/bas)
	
	// Optionel
	q3map_lightmapmergable
	// fusionne tout le terrain en un seul lightmap sans coupures
	q3map_lightmapsamplesize 32
	// met la taille du sample du lightmap à 32 
	// (2x taille par défaut) pour économiser de la RAM
}

// Etape 2 : Shader de Terrain unique
textures/terrain/texture_0
{
	q3map_baseshader textures/terrain/texture_base
	// on récupère toutes les propriétés du shader de 
	// référence par héritage grâce au keyword q3map_baseshader
	{
		map textures/terrain/texture_0.tga
	}
	{
		map $lightmap
		blendFunc GL_DST_COLOR GL_ZERO
		// on applique le lightmap
	}
}

textures/terrain/texture_1
{
	// identique textures/terrain/texture_0
	// ne pas oublier de remplacer _0 par _1
}

// Etape 3 : Shader de Terrain pour la fusion des deux textures
textures/terrain/texture_0to1
{
	q3map_baseshader textures/terrain/texture_base
	{
		map textures/terrain/texture_0.tga
	}
	{
		map textures/terrain/texture_1.tga
		blendFunc GL_SRC_ALPHA GL_ONE_MINUS_SRC_ALPHA
		alphaGen vertex
		// phase de mélange
	}
	{
		map $lightmap
		blendFunc GL_DST_COLOR GL_ZERO
		// on applique le lightmap par-dessus
	}
}

Retour en haut

Utiliser le cel-shading

Vous avez probablement entendu parler du jeu XIII ou de Zelda : the Wind Waker. Leur caractéristique est d'offrir un design assez proche des bandes dessinées, avec des 'à-plat' de couleurs unies et un système d'ombrage simplifié (dit celshading). Si jamais vous mappez pour un mod au look cartoonesque, je vous recommande de tester le celshading sur votre map, ça risque de lui coller comme un gant.
Pour utiliser le celshading, ouvrez votre shaderlist.txt (dans X:\Chemin\vers\Quake3\baseq3\scripts) et ajoutez la ligne "cel"
Vous devez également, dans GTKRadiant ajouter la clé worldspawn "_celshader" avec pour valeur "cel/ink".
Vous aurez peut-être à déplacer le fichier cel.shader qui se trouve dans le répertoire où vous avez décompressé q3map2, pour le déposer dans le répertoire baseq3\scripts.
Si vous utilisez le q3map2 fourni avec GTKRadiant, vous n'avez pas ce fichier, vous pouvez le télécharger ici.

Il existe un switch dans q3map2 permettant d'étirer les textures afin qu'elles soient unies. q3map2 calcule la valeur RGB moyenne de la texture puis il "étire" le pixel le plus proche de cette valeur jusqu'à ce que la texture soit unie.
Ce paramètre est -flat, il se place lors du processus BSP.
>q3map2 -flat nomdelamap.map
A noter que cette méthode n'est valable que pour les flemmards n'ayant pas peur de gâcher un peu de mémoire vidéo. En effet, bien qu'étirée, la texture est tout de même chargée en mémoire. Afficher un seul pixel d'une texture 512x512, ça reste du gâchis, utilisez plutôt des textures unies de 1x1 pixel pour vos maps en celshading.

Cel Shading sur Q3DM17
Cel Shading sur Q3DM17


Retour en haut

Décompiler une map

Le décompilateur intégré dans Q3map2 n'est pas vraiment excellent, mais il a le mérite de rendre service lorsque l'on ne retrouve plus WinBSPc.
Plus précisément, vous pourrez être sûrs de perdre : vos func_group (y compris ceux liés aux terrains), l'alignement des textures, ainsi que les lumières et les models peuplant la map.
Il s'utilise de la manière suivante :
>q3map2 -convert -format map nomdelamap.bsp
Vous pouvez également tenter d'ajouter le paramètre -force si jamais la manip ne marche pas.


Retour en haut

Créer un effet de vitrail

Une fonctionnalité sympa permettant d'ajouter à l'ambiance de votre map, surtout si celle si se déroule dans une église : les vitraux. C'est un simple mot-clé à ajouter au shader de votre texture, "surfaceparm lightfilter". Vous n'avez rien à ajouter à la compilation, tout est automatique. Au final, la lumière va traverser votre texture et se colorer suivant les couleurs de cette texture. Vous pouvez renforcer le réalisme en ajoutant une couche alpha bloquant la lumière au niveau des armatures du vitrail (il suffit d'ajouter une couche supplémentaire à votre shader - pour plus d'informations, reportez-vous au Q3map2 Shader Manual (Anglais)).

Lightfilter
Lightfilter

Si vous voulez faire un effet de vitrail sur une surface courbe, vous devrez soit ajouter le keyword "q3map_patchshadows" dans votre shader, soit carrément ajouter le switch -patchshadows lors du processus LIGHT (attention, avec ce dernier, TOUTES les surfaces courbes génèreront des ombres).


Retour en haut

Utiliser le bump-mapping

Le bump-mapping est un poil complexe à mettre en oeuvre.
D'abord, vous devrez créer le normalmap associé à votre texture. Le normalmap contient les informations de volume de votre texture.
Pour créer ce normal map, il vous faut obligatoirement PhotoShop 6 ou supérieur et le filtre associé.
Ce filtre est à placer dans le répertoire X:\Chemin\vers\Photoshop\Plug-Ins\Filters\
Il vous faut au minimum DirectX 9 installé sur votre système.
Par exemple, vous avez ici la texture que nous allons utiliser et son normalmap associé :

texture normal map
Texture
Normal Map


Pour créer le normal map, c'est relativement simple. Faites une copie de la texture à normalmapper, puis convertissez-la en Noir et Blanc (et uniquement en Noir & Blanc). Pour cela, vous pouvez passer par le filtre "Photocopie" dans le sous-menu Dessin, qui vous donne directement le résultat en N&B. Vous pouvez retoucher les niveaux via le menu Image>Adjustements>Brightness/Contrast.... Faites une copie de sauvegarde la texture en noir & blanc dans un coin du disque, elle servira tout à l'heure.
Ensuite, il s'agit de générer le normalmap. Dans la fenêtre des channels (Fenêtre Layers/Channels/History), Sélectionnez les 4 channels (Rouge, Vert, Bleu, le RGB s'ajoute automatiquement), puis allez dans Filters>NvTools>NormalMapFilter...
Une boîte de dialogue apparaît, ressemblant à ceci :

Editeur Normal Map
Editeur Normal Map


Les réglages sont les suivants :

  • Filter Type : 3x3 ou 5x5 (ce dernier étant plus précis)
  • Scale : Plus la valeur est haute, plus le volume est marqué. Jouez avec cette valeur pour obtenir un résultat satisfaisant.
  • Height Source : Average RGB
  • Alpha Field : Height


  • Sauvegardez l'image en .tga 32bits. Reprenez votre image en Noir & Blanc, et ajoutez-lui le mot "DEVANT" ou "FRONT" pour les anglophones. Ce tip vous servira dans GTKRadiant à bien aligner votre texture de manière à ne pas avoir le relief à l'envers. Vous arrivez donc avec trois textures :

    texture image gtkradiant normal map
    Texture
    Image GTKRadiant
    Normal Map


    Il nous reste à créer le shader qui va bien :
    textures/nomdelamap/nomdelatexture
    {
    qer_editorimage textures/nomdelamap/nomdelatexture_taggee.tga
    		// Texture taggée qui apparait dans l'éditeur
    q3map_lightmapsamplesize 1x1
    		// BumpMapping plus précis
    q3map_normalimage textures/nomdelamap/nomdelatexture_normalmap.tga
    		// Normal Map de la texture
    	{
    	map $lightmap
    		// On calcule d'abord le lightmap global de la map
    	}
    
    	{
    	map textures/nomdelamap/nomdelatexture.tga
    		// On applique la texture
    	blendFunc GL_DST_COLOR GL_ZERO
    		// le mélange des couleurs : 
    		// +- Src * GL_DST_COLOR : la texture est mélangée au contenu du frame buffer 
    		// +- Dest * GL_ZERO : tous les pixels du frame buffer deviennent noirs
    		// Au final, on obtient une sorte d'effet "filtre" un peu spécial 
    	}
    }
    

    Autant le format de l'image taggée n'a pas d'importance, autant vous êtes obligé d'avoir le normal map en .tga 32bits
    N'oubliez pas d'ajouter une source lumineuse et vous obtiendrez un rendu un peu comme celui-ci :

    Bump Mapping Ingame
    Bump Mapping Ingame


    Quelques remarques pour finir :

  • Pour les Lightmaps haute-résolution (samplesize inférieur à 16), utilisez de préférence un normalmap détaillé (Filter Type en 5x5)
  • Pour les terrains lightmappés, utilisez un normalmap dont vous aurez passé au préalable un filtre de flou (sous photoshop).
  • Sous Photoshop 7, une erreur peut parfois survenir en vous disant que la texture à partir de laquelle vous essayez de générer le normalmap ne dispose pas de couche Alpha (transparente). Pour corriger le problème, sélectionnez les zones noires de votre texture filtrée par Photocopy (via Select>Color Range...), supprimez la sélection puis regénérez le normalmap en sélectionnant le RGB et l'alpha.
  • Petite astuce pour observer la présence du bump ou non : la cvar /r_lightmap active ou désactive l'affichage des lightmaps in-game. /r_lightmap 1 active les lightmaps, /r_lightmap 0 les désactive.
  • Dernier recours si ça ne rend rien in-game : Passez les brushes qui seront bumpmappés en func_group. Ajoutez la clé _lightmapscale à l'entité avec pour valeur 2. Compilez et lancez la map. Ca ne marche pas ? essayez la valeur .125. Toujours pas ? mettez la clé _lightmapscale dans l'entité worldspawn et réessayez avec les deux valeurs précédentes. Pas d'amélioration ? "Cassez" votre mur en blocs de 256x256, retentez de passer chaque bloc en func_group avec la clé comme tout à l'heure.
  • Oubliez le bounce si vous utilisez le bumpmapping, ça dégage tout vos reliefs.
  • Le Bump marche avec les terrains lightmappés, les surfaces courbes et aussi avec le Phong Shading.


  • Retour en haut

    Tirer parti des AntiPortals

    Le principe des AntiPortals est assez difficile à comprendre au premier abord. Disons que si vous avez compris comment marchent les Hint brushes et les AreaPortals, vous aurez déjà fait une grande partie du chemin.

    AntiPortal sous GTKRadiant
    AntiPortal sous GTKRadiant


    A ne verra pas B, mais un effet HOM (champ de miroirs). Les bords du brush AntiPortal ne découpera pas le sol lors du processus BSP. Cet exemple ne présente pas un "bon" cas d'utilisation. Les AntiPortals permettent de bloquer de VIS de manière permanente (contrairement aux Hints brushes et AreaPortals), mais suivant les découpes des autres brushes (regardez les screens suivants pour comprendre) :

    AntiPortal sous GTKRadiant (2)
    AntiPortal sous GTKRadiant (2)


    In-game (r_clear1)
    In-game (r_clear1)


    AntiPortal Ingame (2)
    In-game (2)


    L'utilisation des Areaportals est soumise à plusieurs restrictions :

  • Vous ne pouvez pas les aligner avec les splits créés par les structural brushes, ni avec ceux créés par le moteur, sous peine de leak. (les splits du moteur ont une taille de 1024*1024 par défaut, modifiable avec la clé worldspawn _blocksize). C'est le plus ennuyeux car il est difficile de prévoir à l'avance où se situeront ces découpes. Un bon départ est d'utiliser le plugin prtview inclus dans n'importe quelle version de GTKRadiant.


  • Vous ne devez pas placer un antiportal dans le champ de vision du joueur. Si vous le faites, vous aurez droit à un effet HoM (Champ de Miroirs). Les placer à l'intérieur de structural brushes (ou mieux, de detail brushes) est la meilleure utilisation que vous puissiez faire.


  • Les Antiportals ne peuvent pas être utilisés à la manière d'Unreal Tournament 2kX, c'est à dire que vous ne pouvez pas avoir un antiportal qui coupe à moitié votre map et s'attendre à le voir bloquer le vis. Vous devez sceller la map de façon à ce qu'il y a ait 2 zones distinctes délimitées par votre Antiportal.


  • Conseils d'utilisation :

  • Une seule face du brush doit avoir le shader Antiportal. Les autres faces devront être texturées avec Skip (qui lave plus blanc, c'est bien connu). Bon en fait une surface texturée avec Skip est tout simplement zappée lors de la compile.


  • Un Antiportal ne génère pas d'ombres contrairement à un caulk. On peut donc le placer à l'intérieur de structures assez fines sans avoir d'ombres non voulues une fois le LIGHT stage terminé.


  • Un AntiPortal ne DECOUPE pas les solides avec lesquels il est en contact, contrairement à un Caulk, vous pouvez donc le placer n'importe où, il n'influera pas sur les découpes lors du processus BSP


  • Le meilleur cas d'utilisation pour un AntiPortal, c'est pour optimiser le VIS sur un terrain. Pour rappel, un terrain à la sauce q3map2 est composé de detail brushes, et ceci pour des raisons de simplification (si, si vous verrez, c'est mieux que ça soit detail ;)


  • Vous pouvez combiner les Antiportals avec les Hints et/ou le Sky, pour optimiser au mieux la division de vos zones.



  • Retour en haut

    Ajouter un nouveau Soleil

    Créez un spotlight (une light reliée à un info_null -Ctrl+K pour les lier-), puis ajoutez la clé _sun et la valeur associée 1. L'angle du trait "-->-->" déterminera l'angle du soleil, et les clés _color et light règlent respectivement la couleur du soleil (RGB) et son intensité. Pour désactiver la directive q3map_sun de vos shaders, ajoutez "_noshadersun" "1" au worldspawn.

    2 Soleils In-game
    2 Soleils In-game


    J'en profite pour caser deux choses que je ne pouvais mettre autre part :
  • Si vous êtes gêné par le bug des skyboxes (trait noir sur les bords du ciel avec les cartes 3D ATI et les dernières nVidia), utilisez le switch -skyfix lors du processus BSP. Pas besoin par contre si vous mappez pour Enemy Territory ou Jedi Academy.
  • la directive q3map_sunExt est équivalente à sa grande soeur q3map_sun, en ajoutant deux paramètres : la déviation angulaire et le nombre de samples. On l'utilise comme ceci :
  • q3map_sunExt <r> <g> <b> <puissance> <angle> <élévation> <deviation> <samples>
    <deviation> : Correspond à la largeur du soleil en degrés
    <samples> Nombre de samples (jitter)
    
    Cela permet de gérer une approximation pour créer un effet de pénombre (demi-ombre) afin de générer une ombre partielle en plus de l'originale. Au final, cela fait une sorte de transition en passant d'une zone éclairée à une zone de pénombre (ombre claire) puis à une zone d'ombre (ombre plus foncée).


    Retour en haut

    Les portal skies

    Prenez un un ciel classique sous Quake 3. Il est en 2d, statique, bref, pas très très joli même si l'on peut lui ajouter des trucs rigolos comme des nuages ou un effet de lens-flare. Un portal sky agit comme une sorte de caméra qui va "retransmettre" un bout de map à part de votre niveau. Ca veut dire que les parois de votre ciel se comportent comme des écrans de télévision. Et ce bout de map sera affiché de cette manière. Vous aurez donc au final un ciel en 3 dimensions, qui pourra être lightmappé, phong shadé ou encore combiné à d'autres techniques offertes par q3map2.
    Technique simple à mettre en oeuvre et jolie à l'oeil, que demander de plus ? Allez hop, au boulot :)

    Pour les utilisateurs de Quark ou d'un GTKRadiant 1.2.x ou antérieur :
    Dans la dernière version de q3map2, dans le dossier extras se trouve le fichier entities_skybox.def. Lancez GTKRadiant et vérifiez dans project settings que le cvar "script" a pour valeur *.def. Puis copiez entities_skybox.def dans le répertoire X:\votre\repertoire\quake3\baseq3\scripts\.

    Lancez GTKRadiant et créez votre sky en créant un bout de map bien étanche. Vous n'avez pas de limite quant à la taille (taille suggerée : 128x128x128), et si vous voulez ajouter un shader de ciel standard, vous pouvez le faire sans problèmes. Vous pouvez également utiliser les surfaces courbes sous réserve d'ajouter le switch -patchmeta à la compilation lors du processus BSP. Si vous ne voulez pas du -patchmeta tentez un q3map_nonplanar sur les shaders recouvrant vos patches (Aucune garantie que ça fonctionne à coup sûr). Si vous avez l'erreur MAX_PATCH_PLANES, virez vos surfaces courbes.
    Des que les brushes sont montés, occupez vous de l'éclairage, soit vous laissez les shaders de sky standard s'en occuper (q3map_sun / skyLight mais surtout pas q3map_surfacelight) soit vous le gérez vous même avec des shaders émettant de la lumière. A noter que l'on ne peut pas utiliser d'entités autres que le misc_model dans un portal sky. Le misc_model est compilé dans le BSP contrairement aux autres entités.

    Une fois le sky prêt, placez l'entité _skybox au milieu de votre mini-map. Cette entité correspond à l'emplacement de votre vrai map. Placez-là de telle manière à ce que la map par rapport au sky ne soit ni trop haut, ni trop bas, suivant les cas.
    On peut bidouiller les champs de l'entité _skybox : ils sont au nombre de 3 :
    • _scale : rêgle l'échelle de taille (une valeur de 2 multiplie par 2 la taille de la box, à 0.5 elle est divisée par 2)
    • angles : trois valeurs (défaut : 0 0 0 dont les angles respectifs sont X, Y et Z). contrôle l'assiette de la box. Si vous voulez la faire pencher, il faut modifier ces paramètres (valeurs de 0 à 360).
    • angle : (Non testé)


    Placez un sky différent de celui du portal sur votre vraie map. De là où il se situe sera visible la mini-map. Pour plus de sureté, vous pouvez même caulker, puisque en fait, dès qu'il y aura un effet HOM potentiel, Q3map2 applique automatiquement le sky portal.

    Compilez, mangez, c'est chaud.

    Sky Portal sur JK2 (la lune)
    Sky Portal sur JK2 (la lune)



    Retour en haut

    Le FogHull

    Marre de ce polycount trop élevé sur CTF SQF ? Vous ne voulez pas passer six ans à optimiser votre map ? Utilisez le Fog Hull, connu également sous le nom de "Brouillard Cache Polygones". Quake 3 propose en standard un shader de brouillard bien sympathique, mais peu utile puisqu'il n'empêche pas le moteur 3D de calculer les polygones qu'il cache grâce à sa densité.
    Q3map2 arrive à point nommé pour patcher ce système de fog en empêchant le moteur de calculer les surfaces masquées par le brouillard. Pour mettre tout cela en oeuvre, suivez le guide (n'oubliez pas le pourboire) :

    Je sais ça fait mal, mais il va falloir que vous supprimiez d'abord tous vos brushes de brouillard que vous aviez méticuleusement placés.
    Evaluez la distance de clipping, c'est à dire la distance à partir de laquelle vous voulez que le moteur stoppe le calcul de vos polys. Créez une clé worldspawn nommée _farplanedist ayant pour valeur la distance de clipping désirée. Mettons 2048 par exemple.

    Créez une seconde clé worldspawn intitulée _blocksize avec pour valeur la moitié ou le quart de la valeur de la clé _farplanedist. Si jamais à la compilation, un vilain MAX_VISDATASIZE apparaît, augmentez la valeur du blocksize. Dans notre exemple, _blocksize prendra pour valeur 1024 (il peut également prendre 512).
    (Petite parenthèse technique, le _blocksize détermine la taille maximale d'un triangle, un peu comme le subdivide pour Half-Life. Mettre un blocksize à 256 équivaut à limiter la taille de vos polys à 256x256. Si vous avez une surface plus grande, elle sera subdivisée en plusieurs polygones de 256x256, soit une augmentation significative des r_speeds. Evitez donc de trop faire joujou avec).
    Créez un shader de sky complet, c'est à dire 6 images TGA 8 x 8 pixels ayant une couleur unie qui sera la même que votre brouillard, plus le shader script associé ci-dessous :

    Rappel Important :
    Les valeurs RGB que vous rencontrerez ci-dessous sont comprises entre 0 et 1 (elles sont dites normalisées) contrairement à la logique qui voudrait qu'elles soient comprises entre 0 et 255. Pour normaliser les valeurs standard, divisez votre valeur R, G et B par 255. Par exemple, un RGB normalisé de 225 132 28 vaut 225/255 132/255 28/255 c'est à dire .882 .517 .109 (en tronquant).

    
    // Shader qui aura 6 textures de skies nommées : 
    // monsky_up.tga
    // monsky_dn.tga
    // monsky_lf.tga
    // monsky_rt.tga
    // monsky_ft.tga
    // monsky_bk.tga
    textures/skies/monsky
    {
    	// A ne pas modifier
    	surfaceparm noimpact
    	surfaceparm nolightmap
    	surfaceparm sky
    
    	qer_editorimage textures/skies/monsky_bk.jpg
    	// Votre sky dans GTKRadiant
    
            skyparms env/monsky - -
    	// Paramètres du sky
    
    	// A modifier
            q3map_lightimage textures/common/white.tga
    	// Arrangez-vous pour y mettre une texture 
    	// ayant la même couleur que votre brouillard
    
    	q3map_sun	1 1 1 300 -45 70
    	// Le soleil dont les paramètres correspondent à :
    	// q3map_sun <R> <G> <B> <intensité> <angle> <élevation>
    	// Modifiez les valeurs pour que le soleil émette une 
    	// lumière de la couleur de votre brouillard
    
    	q3map_surfacelight 200
    	// Puissance de la lumière émise.
    	// Vous pouvez modifier ce paramètre en fonction des
    	// résultats que vous comptez obtenir in-game
    }
    

    Une fois cela fait, créez à nouveau une clé worldspawn _foghull ayant pour valeur le nom de votre sky (Ici, skies/monsky). Il faut obligatoirement y indiquer le chemin relatif (ici, skies/), sinon le compilateur ne s'y retrouvera pas.

    Texturez maintenant le ciel de votre map avec le shader que nous venons de créer. Compilez la map avec BSP et VIS -fast (pas besoin du LIGHT pour le moment). Lancez Quake 3 (ou n'importe quel jeu utilisant le moteur de Q3) et lancez la map avec la commande /devmap. Vous devriez voir votre foghull en arrière-plan, qui masque des polygones. Déplacez-vous et constatez que des portions de polygones apparaissent et disparaissent, preuve que votre foghull fonctionne. Si vous avez un effet HOM (Hall of Mirrors), augmentez d'abord le _farplanedist. Au besoin, diminuez le _blocksize (avec prudence). Re-compilez à chaque fois (BSP + VIS -fast) jusqu'à ce que le HOM disparaisse.

    Créez maintenant votre shader de brouillard à partir du modèle ci-dessous :
    // Shader de brouillard
    textures/sfx/monfog
    {
    	// Pas toucher !!
    	surfaceparm trans
    	surfaceparm nonsolid
    	surfaceparm nodrop
    	surfaceparm fog
    
    	// A modifier
    	fogparms ( .1 .1 .1 ) 2000
    	// Le brouillard dont les paramètres correspondent à :
    	// fogparms <R> <G> <B> <distance jusqu'à opacité>
    	// La valeur 2000 est en fait la valeur 2048 cité au début du tutorial 
    	// retranchée de 48 unités pour être certain que le fog masquera bien le clipping
    }
    

    Montez maintenant votre brush de fog texturé par le shader précédent dans votre map, en laissant un petit espace (1 unité suffit) entre chaque bord de votre map. Veillez à ce que toute la map soit foggée, il ne faut en effet qu'une seule face du fogbrush soit visible par le joueur (le joueur étant à l'extérieur du brush), sinon ça ne marchera pas. Compilez (BSP + VIS -fast), vérifiez que tout est parfait. Si oui, faites une compilation complète avec VIS et LIGHT.

    Foghull In-game (q3dm17)
    Foghull In-game (q3dm17)


    Foghull In-game wireframe (q3dm17)
    Foghull In-game wireframe (q3dm17)



    Retour en haut

    Les LightStyles

    Les lumières dynamiques sont assez spéciales à mettre en place, mais une fois toutes les étapes suivies correctement, ca donne des effets assez sympathiques.

    Attention toutefois, des problèmes de compatibilité ont été rencontrés avec qfusion (rc3 il me semble). Du reste, je n'ai pas testé avec les versions supérieures. Soldier Of Fortune 2, Jedi Knight 2 et Elite Force tirent parti des styled lights normales, pas besoin donc de suivre ce tuto qui ne s'adresse qu'aux mappeurs pour Quake 3, RTCW, Elite Force et Enemy Territory.

    L'utilisation du switch -external pendant le LIGHT process est recommandé pour les maps ayant de larges terrains. Je recommande personnellement l'utilisation des lumières dynamiques dans de petites pièces faibles en polygones.

    Qu'est il possible de faire avec des lumières dynamiques ?

    1°) Lumières mouvantes (déplacement/rotation)

    2°) Lumières clignotantes

    3°) Lumières à intensité dynamique

    4°) Lumières changeant de couleur

    5°) Des combos divers des possibilité ci-dessus.

    Je ne vous cache pas qu'il va falloir mouiller la chemise pour faire fonctionner tout cela correctement :)

    Comment fait on marcher tout cela ?
    • 1ère étape : Ajouter une clé style à chaque entité light. Mettez-y une valeur comprise entre 1 et 31 (la valeur 0 est réservée). Si vous avez des shaders émettant de la lumière, ajouter le mot-clé q3map_lightStyle N où N est tojours compris entre 1 et 31.


    • 2ème étape : Ajouter à l'entité worldspawn la clé "_styleNrgbgen" ou "_styleNalphagen" suivant l'effet que vous comptez faire, et N correspond à la valeur que vous avez définie plus haut
      • AlphaGen : Comme son nom l'indique, ce mot-clé s'occupe de la transparence. idéal pour les lumières à variation d'intensité.
      • RgbGen : Comme son nom l'indique aussi, il gère les couleurs RGB, idéal pour faire changer de couleur une lumière.


    • 3ème étape : Là c'est assez lourd. Il faut que vous patchiez les shaders susceptibles de se faire "toucher" par les lumières dynamiques en ajoutant le keyword q3map_styleMarquer APRES la couche $lightmap, mais avant celle des textures pour que Q3map2 puisse correctement générer tous les shaders qui génèreront les lightmaps à la compilation. Je ne vous cache pas que plus y'en a et plus la compilation risque de durer effroyablement longtemps. Pour les textures masquées (Une histoire de Z-Buffer), utilisez le mot clé q3map_styleMarker2.
    • 4ème étape : Compilez avec les switchs suivants -nocollapse (Obligatoire...de toutes facons, il est activé d'office que vous le mettiez ou non), et -external pour éviter certains crashes lors de la compile de maps ayant de grands terrains (pour Enemy Territory principalement). Tout cela est à placer au LIGHT Stage.


    Soucis sur lesquels on peut buter :

  • Les Shaders ayant la couche lightmap après celle de la texture. Pour le moment ça donne un résultat assez moche. Essayez de réarranger (inverser marche le plus souvent...mais pas tout le temps) les couches des shaders concernés.
  • Seules les surfaces lightmappées peuvent subir l'éclairage dynamique. Les entités misc_models (vertex lightés) et celles éclairées dynamiquement par le lightgrid ne pourront pas l'être. Utilisez au besoin l'entité light_junior a coté de vos entités pour simuler un éclairage décent


  • Vidéo Sous TrueCombat
    Vidéo Sous TrueCombat



    Retour en haut

    Le Phong Shading

    Le Phong Shading est une méthode alternative d'éclairage. Vous avez d'un coté les lightmaps que tout le monde connait, et de l'autre le Phong. Le Phong se base sur les normales (les perpendiculaires) des sommets pour générer des ombres par interpolation. Notez que ça peut donner parfois des résultats un peu bizarres ;) Très efficace pour les terrains, le résultat est souvent meilleur qu'avec la méthode (bancale) des lightmaps.
    Pour la mettre en pratique, il s'agit de créer/modifier vos shaders en se basant sur le script suivant :
    
    textures/phong/votre_texture 
    // en cas de soucis, pensez à intervertir la commande :
    // map textures/phong/votre_texture.tga  (stage1)
    // et celle-la :
    // map $lightmap  (stage2)
    { 
    	q3map_nonplanar
    	// convertit les brushes ayant les même attributs 
    	// (scale, offset et rotation sur toutes les faces adjacentes texturées)
    	// mais non alignés entre eux en un seul mesh
    
    	qer_editorimage textures/phong/votre_texture.tga
    
    	q3map_shadeangle 120 
    	// active le phong avec un angle de 120°
    
    	{ 
    	// stage 1
    		map textures/phong/votre_texture.tga 
    
    		rgbGen identity 
    	}
    	{
    	// stage 2 
    		map $lightmap 
    
    		tcGen lightmap 
    		// tcGen lightmap est optionnel
    		// il permet de s'assurer que les coordonnées de 
    		// la texture seront bien générées en fonction 
    		// du lightmap (créé par le phong)
    
    		blendFunc GL_DST_COLOR GL_ZERO 
    		rgbGen identity 
    	} 
    }
    
    
    A la compilation, spécifiez le switch -shade au LIGHT stage. Vous pouvez également ajouter -shadeangle X où X est l'angle d'incidence (d'arrivée de la lumière sur le sol). X est compris entre 0 et 360. Au-delà de 180, vous commencez à éclairer par-dessous. Faites gaffe :) Le -shadeangle vous permet de vous passer du bidouillage des shaders pour y appliquer la directive q3map_shadeangle. Si ça paraît alléchant, quelques soucis d'ombrage peuvent apparaître. Ne l'utilisez pas si vous pensez également utiliser du Lightmapping à certains endroits de votre map et du Phong Shading à d'autres.

    Un truc a retenir, ne jamais utiliser -filter au LIGHT stage avec le phong shading d'activé, le filtre de flou créé par filter détruit généralement la qualité de l'ombrage. Utilisez plutôt le switch -thresh 0.5 ou 0.25 Attention, diminuer cette valeur augmente fortement le temps de compilation

    Phong Shading (shadeangle 90)
    Phong Shading (shadeangle 90)



    Retour en haut

    Auto Models Distribution

    Vous en avez assez de copier-coller vos models sur votre terrain ? Q3map2 vous permet gràce à un simple mot-clé shader de répartir suivant vos directives des models sur n'importe quelle surface.
    Il vous suffit simplement de coller le parametre q3map_surfacemodel sur le shader qui recevra les models, de remplir correctement ses paramètres (voir ci-dessous) et le tour est joué.

    Description :
    q3map_surfacemodel <chemin du md3> <densité en unités> <chances d'apparition> <taille min> <taille max> <angle min> <angle max> <orienté>

    <chemin du md3> : chemin jusqu'au model .md3
    <densité en unités> : densité d'apparition, plus le nombre est élevé, plus les models seront nombreux
    <chances d'apparition> : valeur comprise entre 0 et 1, plus elle est élevée, plus les models pourront apparaître toutes les X unités (X est définit par le paramètre <densité en unités>)
    <taille min> : taille minimale du model
    <taille max> : taille maximale du model > Ingame, chaque model aura une taille comprise entre ces 2 valeurs.
    <angle min> : angle minimum du model
    <angle max> : angle maximum du model > Ingame, chaque model aura un angle compris entre ces 2 valeurs.
    <orienté> : C'est un flag, il prend pour valeur 0 (désactivé) ou 1 (activé). Activé, le model sera perpendiculaire à la surface sur laquelle il repose, alors que désactivé, il se contentera de rester perpendiculaire par rapport au plan.

    Exemple :
    q3map_surfacemodel models/mapobjects/tree2/tree2.md3 64 0.001 0.5 4.0 0 360 1

    Ici, on aura un model d'arbre (tree2.md3) généré avec une probabilité de 0.001 toutes les 64 unités sur toute la texture. Chaque model aura une taille comprise entre la moitié de sa taille initiale et 4 fois celle-ci. L'angle horizontal de chaque arbre sera compris entre 0° et 360°.

    Vous avez dit Unreal ?
    Vous avez dit Unreal ?



    Retour en haut

    Ajouter de la fourrure !

    Une feature sympathique de q3map2 est la possibilité de créer un semblant de fourrure. Idéal pour simuler l'herbe d'un terrain, ou créer un effet glow. Attention toutefois à ne pas en abuser, parce que ça consomme pas mal de ressources. Un fichier exemple contenant les textures, les shaders, une map d'exemple et sa source sont disponibles en téléchargement à cette adresse.

    On attaque par la création d'un shader de base et de sa texture associée.
    // Prêt à l'emploi
    textures/fur/texture_base
    {
    	q3map_cloneshader textures/fur/texture_fur
    	{
    		map $lightmap
    	}
    	{
    		map textures/fur/pink_base.tga
    		blendFunc GL_DST_COLOR GL_ZERO
    	}
    }
    
    Vous devez appliquer ce shader et uniquement celui-ci sur les brushes de vos maps pour obtenir de la fourrure. Notez que vous pouvez modifier un shader déja existant (par exemple un terrain pour obtenir de l'herbe). En effet, il vous suffit juste d'ajouter la ligne q3map_cloneshader textures/fur/texture_fur au shader existant. Faites particulièrement attention au noms de vos shaders car la directive q3map_cloneshader invoque le shader de fourrure en supposant que son nom est texture_fur. Vérifiez bien que les noms correspondent.

    A l'attention des utilisateurs de terrains :
    Vous avez un terrain avec une texture d'herbe et une autre de roche, et vous voudriez que l'herbe générée par le fur de q3map2 compose avec les transitions de textures avec harmonie ? rien de plus simple. Utilisez la directive q3map_cloneshader sur votre shader d'herbe et sur tous les shaders de transition (ici transition herbe/roche). Lors d'une transition herbe/roche, l'herbe générée par le fur disparaitra progressivement et proprement.

    La texture, au format TGA 24 bits doit être opaque. Pour vous aider à créer cette texture, utilisez l'image pink_base.tga qu'Ydnar a eu soin de préparer. Vous n'avez plus qu'à la recolorer selon vos goûts.

    Maintenant, on s'occupe du shader de fourrure proprement dit, ainsi que ses deux textures associées :
    // Génération de la fourrure proprement dite
    textures/fur/texture_fur
    {
    	// On ne touche pas !
    	q3map_notjunc
    	q3map_nonplanar
    	q3map_bounce 0.0
    	q3map_shadeangle 120
    
    	surfaceparm trans
    	surfaceparm pointlight
    	surfaceparm alphashadow
    	surfaceparm nonsolid
    	surfaceparm noimpact
    
    	nomipmaps
    	
    	// On peut toucher !
    	q3map_lightimage textures/fur/texture_fur.q3map.tga
    	// remplacez texture_fur.q3map.tga par le nom de votre texture
    
    	q3map_fur 8 1.25 0.1
    	// format: q3map_fur <nombre de couches> <hauteur> <adoucissement>
    	// <nombre de couches> Augmentez/diminuez cette valeur si 
    	// texture_fur.tga est respectivement plus opaque/transparente
    	// <hauteur> Hauteur de la fourrure.
    	// <adoucissement> plus la valeur est élevée, plus la fourrure sera floue
    
    	{
    		map textures/fur/texture_fur.tga
    		blendFunc GL_SRC_ALPHA GL_ONE_MINUS_SRC_ALPHA
    		rgbGen vertex
    	}
    }
    
    Les deux textures, au format TGA 32 bits doivent avoir une couche alpha (transparence). De même, pour créer cette texture, utilisez respectivement les images pink_fur.q3map.tga et pink_fur.tga. Vous n'avez plus qu'à la recolorer comme tout à l'heure. Vous pouvez également les modifier comme vu plus haut. En densifiant la texture (c'est à dire en diminuant la transparence), vous pourrez augmenter le nombre de couches. La texture du q3map_lightimage se régénère à partir de la texture de fourrure en appliquant un filtre de flou sous Photoshop.

    Pour un effet de glow, tentez un q3map_fur 1 8 0.5. En ce qui concerne les terrains, vous pouvez agrémenter l'effet d'un deformVertexes wave ou bulge, ça simulera le vent qui fait bouger l'herbe :)

    Fur In-game
    Fur In-game



    Retour en haut

    Les AlphaMods

    (En construction)


    Retour en haut

    Les Decals

    Une décalcomanie (decal en anglais), c'est comme un tatouage sur une map. Ca se fait très simplement grâce, encore une fois, à q3map2.
    Créez une surface courbe en simple patch mesh qui aura comme texture votre decal. Passez-là en entité _decal (q3map2.5.7 ou supérieur requis). linkez un info_null sur cette entité (Sélectionnez le _decal, puis l'info_null, et faites Ctrl+K), en agençant les brushes comme le montre le dessin :

    Mini HowTo en image
    Mini HowTo en image


    Le lien entre l'info_null et le patch gère l'axe et la distance de projection.

    Shader Editing :
    Vous pouvez également bidouiller le .shader de votre decal si jamais les résultats ne sont pas probants :

    En cas d'effets Z-fighting, activez sort 6
    
    // Shader fonctionnant dans la plupart des cas
    // (comprendre : dans les cas foireux)
    textures/decals/test_decal
    {
    	qer_trans 0.75
    
    	q3map_noTJunc	
    	q3map_nonplanar
    	q3map_shadeAngle 179
    	//  rendu plus efficace
    
    	surfaceparm nonsolid
    	surfaceparm nomarks
    	surfaceparm trans
    
    	// Ces deux directives sont obligatoires
    	surfaceparm nolightmap	
    	polygonOffset	
    	
    
    	// optionnel
    	sort 6
    	// Place le decal légèrement 
    	// en avant par rapport à la surface du brush
    
    	{
    		map textures/decals/mon_decal.tga
    		blendFunc GL_ZERO GL_ONE_MINUS_SRC_COLOR	
    		// *inverse* la texture, 
    		// ca corrige les soucis de brouillard
    		rgbGen identity
    	}
    }
    


    Si vous ne voulez pas de decal sur un certain type de shader, utilisez le surfaceparm nomarks (ça dégage également les impacts de balles/explosifs...faites gaffe ;)

    Decal
    Decal



    Retour en haut

    Les Alphashadows

    La technique des alphashadows permet de réaliser des effets d'ombres précis en passant à travers des textures ayant un canal alpha (c'est à dire ayant des zones opaques et des zones transparentes). La mise en oeuvre est simple, mais le réglage des ombres peut demander un peu plus de temps.

    Création de la texture :

    D'abord nous allons créer une texture ayant un canal alpha sous Photoshop (version 6 et supérieures).

    Pour plus de simplicité, la zone noire représente la surface transparente de la texture.

    Création de la texture
    Création de la texture


    Sélectionnez cette zone via l'outil Séléction>Plage de couleur. J'ai choisi une tolérance assez faible pour cette texture. En fonction de la forme de la votre, vous pouvez jouer avec cette valeur.

    Sélection de la couleur Sélection de la couleur
    Sélection de la couleur


    Inversez la sélection via Ctrl + Shift + I.

    Inversion de la sélection
    Inversion de la sélection


    Activez la création du channel alpha en passant en mode Quick Mask via la touche Q.

    Création du canal alpha
    Création du canal alpha


    Vous pouvez maintenant sauvegarder votre texture, au format Targa, en n'oubliant pas de cocher la case 'Couche Alpha'.

    Sauvegarde au format TGA Sauvegarde au format TGA
    Sauvegarde au format TGA


    Il ne vous reste plus qu'à la placer dans le répertoire baseq3/textures/alphashadows.

    Création du shader :

    On s'attaque ensuite à la création du shader qui va rendre notre texture spéciale.

    textures/alphashadows/alphashadow
    {
    	
    	qer_editorimage textures/alphashadows/alphashadow.tga
    	qer_trans 0.5
    	// Pour afficher la texture dans l'éditeur.
    	// elle sera également transparente
    
    	surfaceparm alphashadow
    	// Pour activer l'alphashadow
    
    	cull none
    	nopicmip
    	nomipmaps
    	// Ces trois directives sont optionnelles :
    	//
    	// cull none force la texture à être affichée sur les deux côtés d'une surface, 
    	// utile lorsque le joueur peut se trouver d'un côté ou de l'autre de la texture.
    	//
    	// nopicmip empèche la texture d'être dégradée via la commande r_picmip
    	// nomipmaps empèche la texture d'être dégradée en fonction de la distance 
    	// d'affichage
    
    	{
    		map textures/alphashadows/alphashadow.tga
    		blendfunc GL_ONE GL_ZERO
    		alphafunc GE128
    		// jouez avec cette valeur en cas de mauvais résultats
    		// les valeurs possibles sont :
    		// GT0, LT128, GE128
    		depthwrite
    		rgbGen identity
    	}
    
    	{
    		map $lightmap
    		rgbGen identity
    		blendFunc GL_DST_COLOR GL_ZERO
    		depthFunc equal
    	}
    
    
    }
    
    On sauvegarde tout ça dans le fichier alphashadow.shader que l'on place dans le répertoire baseq3/scripts. On inscrit ensuite alphashadow à la fin du ficher shaderlist.txt du répertoire baseq3/scripts.

    Implémentation :

    Crééz une map toute simple, les seules conditions requises sont la présence d'une source lumineuse sous la texture suffisamment forte pour que l'ombre soit projetée sur la(les) surface(s) en face de la texture. Vous pouvez également télécharger les maps d'exemples made in channouze pour ce tutorial.

    Réglages :

    On peut jouer sur certains paramètres afin d'affiner la précision des ombres. Sur les screenshots suivants, je compare la qualité des ombres en fonction de différents réglages. A gauche de chaque capture, le rendu final, à droite, la vue du lightmap (en utilisant la commande r_lightmap 1). J'ajoute également le temps de compilation pour chaque cas, ainsi que le nombre de lightmaps exportés, bon indicateurs de la lourdeur de la map.
    Pour info :
    • Configuration de compilation : Athlon 1800+, 256Mo DDR
    • Ligne de commande : q3map2.exe -light -super 4 -samples 3 -export
    BOUNCE

    On va d'abord tâter du bounce. Le bounce se règle à la compilation via le switch -bounce n. Ce switch simule la radiosité en faisant "rebondir" la lumière de murs en murs.

    bounce 0 bounce 1
    bounce 0 (défaut)
    Compilation des lumières : 1 seconde
    Lightmaps exportés : 2
    bounce 1
    Compilation des lumières : 52 secondes
    Lightmaps exportés : 2


    bounce 2
    bounce 2
    Compilation des lumières : 128 secondes
    Lightmaps exportés : 2


    Conclusions : D'un part les lightmaps ne sont pas très précis (aliasing important) et de plus, le bounce diminue le contraste des ombres et prend du temps. Pour jouer avec le bounce, 2 possibilités :
    • Soit vous supprimez le paramètre -bounce de votre batch de compilation. Ce qui est assez contraignant si vous avez remarqué que le bounce est essentiel pour le reste de votre map.
    • Soit vous repérez les surfaces sur lesquelles l'ombre est appliquée et vous pouvez alors modifier les shaders correspondant en ajoutant la directive q3map_bounce n (n nombre réel positif). Une valeur à 4 ré-émet quatre fois plus de lumière qu'elle en reçoit, alors qu'à 0.5, seule la 'moitié' de la lumière reçue sera ré-émise. Je ne vous le cache pas, c'est très contraignant. Il faut souvent dupliquer les textures et copier/coller les shaders juste pour y ajouter une ligne. Après, c'est à vous de voir jusqu'à quel degré vous êtes perfectionnistes :)
    LIGHTMAPSCALE

    Maintenant qu'on a vu l'influence du bounce, regardons le second paramètre : la taille du lightmap. Petit rappel : le lightmap est la texture que la compilation applique sur votre map pour simuler la présence d'ombres. Et comme toute texture, on va pouvoir influer sur sa taille pour "forcer" l'obtention des ombres précises. On va donc ajouter la clé _lightmapscale dans le worldspawn avec les valeurs suivantes :

    Scale 0.5 Scale 0.25
    Lightmapscale 0.5
    Compilation des lumières : 3 secondes
    Lightmaps exportés : 2
    Lightmapscale 0.25
    Compilation des lumières : 10 secondes
    Lightmaps exportés : 8


    Scale 0.125
    Lightmapscale 0.125
    Compilation des lumières : 18 secondes
    Lightmaps exportés : 10


    Un lightmapscale adapté (c'est-à-dire entre 0 et 1) permet de gagner en précision des ombres, mais au prix d'un temps de compilation assez élevé. Le souci, c'est que l'on a toujours un effet d'escalier assez gênant.

    Astuce pour optimiser le temps de compilation : séléctionnez les brushes qui vont recevoir l'ombre et passez-les en func_group. Ouvrez la fenêtre des entités (touche 'N') et ajouter dans le champ key : _lightmapscale et dans le champ value la taille du lightmap.

    DEVIANCE & SAMPLES

    Autre paramètre sur lequel on peut influer, et non des moindres, la réduction des effets d'escaliers (aliasing) sur les ombres. Pour cela, on passe par l'une des nouvelles fonctionnalités offertes par q3map2 : l'effet pénombre. Il suffit d'ajouter deux clés aux entités émettant de la lumière : _deviance et _samples. Inexplicable en français, je vous réfère aux screenshots qui parlent d'eux-mêmes.

    deviance 2 deviance 3
    Lightmapscale 0.5, _deviance 2, _samples 16
    Compilation des lumières : 24 secondes
    Lightmaps exportés : 2
    Lightmapscale 0.5, _deviance 3, _samples 16
    Compilation des lumières : 23 secondes
    Lightmaps exportés : 2


    samples 32
    Lightmapscale 0.5, _deviance 2, _samples 32
    Compilation des lumières : 45 secondes
    Lightmaps exportés : 2


    On observe bien que plus le nombre de samples est élevé plus la qualité est bonne. Par contre, si on augmente le paramètre _deviance, ça a tendance à dilater l'ombre et à donner un effet très moyen. Augmenter davantage les samples n'est pas très rentable en regard du temps de compilation.

    FILTERRADIUS

    Un autre paramètre est apparu avec la version 2.5.8 de q3map2, il s'agit du "lightmap filter radius". Pour vulgariser comme un sagouin, on peut dire que le compilateur prend le lightmap, lui applique un flou gaussien sous photoshop, et le sauvegarde.
    Pour tester cela, on prend l'entité light de notre map d'exemple, et on lui colle un _filterradius avec différentes valeurs :

    filterradius 16 filterradius 8
    filterradius 16, lightmapscale 0.5, bounce 0
    Compilation des lumières : 5 secondes
    Lightmaps exportés : 2
    filterradius 8, lightmapscale 0.5, bounce 0
    Compilation des lumières : 3 secondes
    Lightmaps exportés : 2


    filterradius 4
    filterradius 4, lightmapscale 0.5, bounce 0
    Compilation des lumières : 3 secondes
    Lightmaps exportés : 2


    Le filter radius est donc assez efficace sur les ombres détaillées avec un rayon court (entre 4 et 8). Ce qui est d'autant plus avantageux, c'est que plus ce rayon est petit, plus la compilation est rapide.

    POUR FINIR

    On peut maintenant tenter une simulation de "rendu final" avec le lightmapscale et l'effet pénombre d'une part, et un filter radius d'autre part.
    Pour le fun, on peut passer un coup de bounce à chacune des passes.

    bounce 0 bounce 1
    Lightmapscale 0.25, bounce 0,
    _deviance 2, _samples 16
    Compilation des lumières : 75 secondes
    Lightmaps exportés : 8
    Lightmapscale 0.25, bounce 1,
    _deviance 2, _samples 16
    Compilation des lumières : 838 secondes
    Lightmaps exportés : 8


    à comparer à :

    bounce 0 bounce 1
    Lightmapscale 0.25, bounce 0, filterradius 4
    Compilation des lumières : 10 secondes
    Lightmaps exportés : 6
    Lightmapscale 0.25, bounce 1, filterradius 4
    Compilation des lumières : 577 secondes
    Lightmaps exportés : 8


    En conclusion :

    A lightmapscale équivalent, le filterradius s'en tire haut la main en termes de durée de compilation. C'est d'autant plus probant lorsque l'on rajoute un coup de bounce par-dessus. De plus, il est graphiquement plus esthétique, étant donné que l'effet pénombre a tendance à dédoubler les ombres en fonction du paramètre _deviance (et pour cause ! c'est ce pourquoi il a été conçu). Le choix est tout fait semble t'il. Cela dit, il n'appartient qu'à vous de faire quelques réglages et de trouver le meilleur compromis entre qualité et rapidité de compilation.

    Concernant le nombre de lightmaps exportés, plus leur nombre est élevé, plus la map sera lourde. Dans le cas de notre exemple, 6 lightmaps sont légérement au-dessus des normes, mais ça passe sur la majorité des ordinateurs. Au-delà de 10 par contre, c'est trop, même si le résultat est très réussi. Ainsi, entre un lightmapscale à 1 et l'autre à 0.125, la map est passée de 100Ko à 600Ko, soit une augmentation en taille de 600% ! Imaginez le résultat sur de grandes maps...

    On peut également influer sur la précision du sample lors de la création du lightmap. Ca se passe par le switch -samplesize N qui se place lors de la phase BSP. Une valeur à 4 donne des lightmaps assez précis, mais il faudra passer obligatoirement un coup de filterradius pour adoucir le crénelage marqué. Inutile de vous dire que la compile en pâti (environ 2 à 3 fois).

    Si vous voulez réaliser des alphashadows précises avec des surfacelights (textures émettant de la lumière), il vous faudra ajouter la directive q3map_lightmapFilterRadius x y à votre shader (x est la quantité de flou à appliquer sur le lightmap de la surfacelight, et y le flou à appliquer sur les surfaces touchées par l'éclairage du surfacelight). Généralement, un q3map_lightmapFilterRadius 0 8 est très efficace.

    Ainsi s'achève ce tutorial un peu plus long, mais il a le mérite d'aller au bout des choses et de vous donner un aperçu du fonctionnement de ces paramètres un peu louches fournis en bundle avec q3map2.

    default compile lightmapscale 0.25 + filterradius 4
    Default compile filterradius 4 + lightmapscale 0.25


    On ne le répètera jamais assez : I love my q3map2 !

    Retour en haut


    © Sylvain 'nunux' Douce
    Les marques citées appartiennent à leur propriétaires respectifs.
    Tous droits réservés.