Optimisation sur Source Engine : Partie 1

Dans ce tutoriel, vous verrez comment optimiser en simplifiant votre map. Inclut le mode d'emploi de Propper :D

Optimisation sur Source Engine : Partie 1

Dans ce tutoriel, vous verrez comment optimiser en simplifiant votre map. Inclut le mode d'emploi de Propper :D

Crée le 21 nov. 2020

Bonjour à toutes et à tous ! :D

Ça fait un bon moment que je souhaite faire un tutoriel assez complet pour l'optimisation sur Source, mais n'étant pas très doué pour les vidéos, et ne trouvant pas de support convaincant... Enfin bon, maintenant que GCA a un nouveau site super cool, c'est le bon moment. :D

Avant toute chose, je tiens à préciser que ce tutoriel est beaucoup plus complet et va plus en profondeur sur le fonctionnement du moteur. Il a été écrit par un ancien mapmaker français d'Half-Life 2. Il n'existe, selon moi, pas plus complet mais il peut paraître un peu austère et complexe pour les débutants. Je vais donc tenter de simplifier certains points (notamment en zappant le fonctionnement de VVIS car c'est quand même un peu tordu). De plus, il manque certains points qui n'étaient pas primordiaux à l'époque, comme l'utilisation de Propper qui est tout simplement devenue obligatoire tellement les maps sont complexes de nos jours.

Voilà tout pour l'introduction. ^^

Ce tutoriel sera divisé en 3 parties (celle-ci étant la première), composées chacune de plusieurs sous-parties.

Simplification de la map

Utiliser le moins de faces possibles

La première chose à savoir lorsque l’on débute en mapping, c’est que la texture NODRAW permet de ne pas calculer l’apparence d’une face. Cela économise des ressources. L'impact d'une seule face est faible, mais ce n’est pas négligeable sur une map complexe.

Il faut donc éviter ce genre de chose…

Nous ne devons texturer que ce nous sommes censés voir. Par conséquent, les faces non visibles doivent être en nodraw.

Autre chose ! Une situation qui vous arrivera assez souvent. Ici pour faire ces grandes fenêtres (oui bon y a pas de vitre mais vous verrez plus tard que ça ne change pas grand-chose xD), j’ai fais plusieurs petits blocs pour faire le mur.

Sauf que si l’idée est bonne, la pratique ne l’est pas. En réalité, le mieux aurait été de ne faire qu’un seul brush supérieur au lieu d’en créer 3 petits. Non seulement vous économiserez en ressources (encore une fois pas beaucoup, mais c’est mortel lorsque vous êtes borderline avec les limites), mais vous éviterez également les risques de bugs bizarres d’éclairage. C’est un peu technique mais sachez simplement que l’éclairage sur un brush est calculé selon une grille dont la taille des cases est définie (la fameuse lightmap, souvent à 16 vous remarquerez). Il n’est pas rare de voir une différence de luminosité assez importante entre deux faces placées côte à côte. Mais nous verrons ça peut-être plus tard, ce n’est pas le sujet ici.

Petit aparté car je sens le sujet venir :

Mais donc si je texturise un bloc avec du nodraw, je pourrais voir à travers ?

Eh bien oui et non ! En réalité, voir à travers ne veut pas dire que le moteur va considérer que vous voulez voir à travers. Vous voyez ? :D Je m’explique.

Dans source, l’optimisation se fait en grande partie grâce à des tests de visibilités durant la compilation. Un brush (terme technique pour dire bloc) peut masquer des parties de la carte selon sa taille. Ici par exemple, j’ai fait une petite salle entourant le joueur. Ce dernier n’est pas censé voir à travers puisque ce sont des murs assez haut.

Ça, Source l’a bien compris. C’est pour cela que nous obtenons ceci en regardant le mur texturé avec du nodraw :

Comprenez donc que l’effet du nodraw est de simplement ne pas associer de texture à une face. On peut voir que des éléments persistent mais, de manière générale, la carte est masquée. Plus-tard nous verrons qu’au travers de diverses techniques, il sera possible de masquer l’entièreté de la carte.

Utiliser les func_detail

Ahh les fameux func_detail. LA solution miracle pour compiler Rockford ! xD C’est vrai quoi, ils sont magiques ces func_detail ! Eh bien presque !

Tout d’abord, définissons le func_detail car c’est important pour éviter les mauvaises utilisations. Le func_detail est ni plus, ni moins, un brush sans test de visibilité. Nous avons précédemment vu que les brushs permettent d’économiser des ressources chez le joueur en limitant les zones chargées, toujours selon leur taille. D’ailleurs, si ta Rockford ne compile pas, c’est tout simplement parce que tu en as créé en trop grand nombre et en trop grande concentration. Les calculs de visibilités deviennent alors trop complexes et VVIS plante (sans s’arrêter, sinon c’est pas drôle :D). Donc la réponse de « pourquoi mettre du func_detail partout permet de compiler », eh bien c’est que les tests de visibilité ne sont pas exécutés pour les blocs possédant cette propriété.

Quand doit-on transformer un brush en func_detail ?

Un brush doit être transformé en func_detail lorsque ce dernier est trop petit et qu’il ne cache rien. On peut par exemple citer les détails (d’où le nom en fait) comme les trottoirs, murets, et les vitres. Oui la définition de détail est assez vague mais bon.

Au final, ce qui reste en brush sans propriété particulière sont des éléments comme des murs fermant hermétiquement une salle, ou assez haut pour masquer une partie de la zone de jeu.

Attention! Toute surface texturée avec un matériau transparent (translucent) sera automatiquement ignorée par le test de visibilité. Aussi étrange que ça puisse paraître, la géométrie du brush en question persiste cependant dans le calcul des portals, laisser ces brushs transparents en brushs sans propriété revient donc à une perte de temps au niveau du temps de compilation. Voilà donc pourquoi je n'ai pas mis de fenêtre à ma maison, c'est comme s'il n'y avait rien pour VVIS (nan en fait j'avais juste la flemme :kappa:).

Ces éléments de cette merveilleuse villa sont à mettre en func_detail. Ils ne masquent rien, ils ne feront qu’allonger le temps de compilation. Pour regarder quels éléments ne sont pas en func_detail, il suffit de décocher « World Details » dans le VisGroup :

Nous obtenons ceci :

Pour vous donner une idée des éléments restant sur une map bien optimisée, voici quelques screens :

Sur Rosewood

Alt text

Sur Florida Alt text

Mais parfois la transformation en func_detail ne suffit plus, les limitations vous hurlent de souffrance, c’est là qu’intervient propper le sauveur de maps ! :D

Utilisation de Propper

Envie de lire la suite de ce tutoriel ?

Connecte-toi dès maintenant, et accède entièrement à tous les tutoriels de GCA !

#Hammer

Écrit par SofianeLasri#3420

9

Sommaire