PARTIE I Contraintes de Production

1 – Contraintes de modélisation

RÈgle générale lors de la création d’une scÈne 

Afin que lors de l’ouverture des fichiers max lors de la validation des modÈles, nous n’ayons pas de réglages à faire, il est interdit de modifier les paramÈtres d’une scÈne max « standard » (ne pas modifier les éclairages ambiants, etc… présents par défaut dans max). Il faudra également que la scÈne envoyée ait comme fenÊtres de viewport une configuration par défaut, à savoir vue Top en haut à gauche, vue Front en haut à droite, vue Left en bas à gauche et vue Perspective en bas à droite, avec le modÈle centré dans ces vues. Vous pouvez travailler avec les réglages que vous souhaitez, mais les fichiers que nous recevrons devront suivre ces normes.

1.2 Taille des Faces

Eviter les trop grandes faces, afin de garder une homogénéité dans l’éclairage (particuliÈrement sur les toits des batiments).

Placement des objets dans max 

Les modÈles devront Être centrés sur la grille de max de façon a ce que leur centre se trouve environ au centre de la grille de max (0,0), et que leur base soit au niveau de cette mÊme grille (rien ne doit Être en dessous de 0 en Z, sauf cas spécial ou des parties d’un modÈle doivent aller en dessous de 0, comme pour un bassin par exemple). En effet, lors de la création des modÈles exportés depuis max vers le moteur de jeu, le modÈle sera créé par rapport au centre du repÈre max à l’endroit ou il sera posé, et ce qui est au dessous du Z= 0 dans max se trouvera sous le terrain dans le jeu.

Elements animés d’une scene 

Si un mesh doit comporter une animation d’un de ses éléments (exemple : drapeau dans un batiment de la base), cet élément devra Être séparé et enregistré dans un fichier.max différent. En effet, lors de la lecture du fichier exporté, si celui-ci comporte une animation, tout le fichier max verra son poids multiplié par le nombre de frames exportées. C’est donc pour un souci d’économie de poids des fichiers ase que les éléments animés doivent Être séparés.

Les éléments animés seront trÈs rares. Si il s’agit d’animations simples (rotation d’un radar), le mesh ne devra pas Être animé sous max : l’effet de rotation sera réalisé via fx dans le moteur du jeu.

Exemple : considérons un batiment équipé d’une porte animée. L’objet constituant la porte devra Être extrait du fichier contenant le batiment, et sauvegardé dans un fichier à part. La position occupée par le pivot de cette porte est identique à la position qu’elle avait au sein de la scÈne d’origine. Le plus simple est donc de modÈliser la scÈne entiÈre (ici, batiment + porte, puis de faire un « save selected » avec la porte selectionnée, pour enregistrer la porte seule avec son animation dans un fichier à part.

Dans le cas d’un objet animé par le moteur (ex : radar), l’objet devra Être enregistré dans un fichier séparé, mais son pivot sera placé en (0,0,0) dans la scÈne. Le fichier max devant recevoir le radar devra comporter une box nommée PIV_XXX (icit, par exemple PIV_Radar) qui sera placée ds la scÈne à l’endroit ou viendra le ModÈle du Radar.

2 – Contraintes de mapping et réalisation des textures

2.1 Tiling

Le tiling marche mais il est à proscrire, sauf cas spécifiques (exemple : dans le cas d’un poteau, on utilisera le tiling d’une petite texture, afin de ne pas avoir de texture rectangulaire trop grande, difficile a texturegrouper): le moteur redécoupe en effet les faces comportant des matériaux tilés, ce qui peut considérablement augmenter le nombre de polygones d’un modÈle. Seul le mapping au niveau du modificateur UVW map marche : ne pas toucher au tiling dans un materiau

Le tiling est donc déconseillé, car il découpe les meshes à l’export quand les coordonnées de mapping sortent de la surface (0,0 ; 1,1).

2.2 Les optimisations

Le but est de limiter le nombre de changement de render states ou batches lorsque l’on choisit les types des matériaux à attribuer à un objet. Il faudra donc veiller à limiter au maximum les valeurs différentes de différents matériaux d’un mÊme objet (ex : paramÈtres de valeurs spéculaires).

2.3 Textures 

Les textures utilisées dans les matériaux doivent impérativement Être au format tga (24 bits pour une texture sans canal alpha, 32 bits pour les textures contenant de l’alpha)

Les textures seront groupées par le moteur. Afin d’optimiser le groupage, les textures devront Être réalisées avec les tailles imposées ci-dessous :

Elles peuvent Être rectangulaires, mais sans atteindre une disproportion trop élevée, car cela gÊne le groupement de textures. Ces textures sont destinées à Être automatiquement regroupée dans un espace d’une taille maximale de 2048X2048.

2.4 Couche Alpha

Pour ajouter de l’opacité il faut que la texture contienne une couche alpha, qui sera prise en compte par le moteur. Cependant, il ne prendra pas en compte les niveaux de gris de la texture : ce qui est en dessous de 128 128 128 (RGB) sera considéré comme totalement transparent, et ce qui est égal ou au dessus de ces valeurs sera interprété par le moteur comme étant totalement opaque, laissant apparaitre la texture.

2.5 Définition des Textures

Afin d’avoir une définition de rendu homogÈne dans le jeu, la définition (taille) des textures variera selon la taille du modÈle, et le type de modÈle réalisé (Batiment/Décors, Véhicule ou unité d’infanterie). Cette taille sera définie en taille de « Cases IA » (à part pour l’infanterie), qui sont les cases utilisées sur le terrain par le moteur du jeu (Voir la Rubrique Cases IA, dans la partie 5 « Informations sur le moteur de jeu/Ressources fonctionnelles).

Il conviendra cependant de travailler les textures dans une définition 2 fois plus grande (à mettre dans un répertoire de travail HighRes), dans le cas d’un besoin ultérieur d’une plus grande définition.

Batiments/Elements de décors et Véhicules : 60 Pixels par case IA

Unités d’infanterie : Une texture de 256 * 256 pixels

Exemple, pour un véhicule de 5 cases IA de long et de 2 cases IA de haut dont on veut mapper un côté entier :

On détermine la taille de la texture, soit 5 X 60 = 300 pour la longueur et 2 X 60 = 120 pour la hauteur.

On choisit ensuite la taille la plus proche dans le tableau des tailles de textures. Ici, on considÈre donc la taille 248 X 120, ou 376 X 120 si nécessaire. C’est ce format qui sera utilisé dans le jeu.

Enfin, on double chaque dimension, ici 496 X 240 ou 752 X 240, cette taille servira à travailler la texture qui sera disponible dans cette version surdimensionnée notamment pour d’éventuelles cutscenes. Ces textures surdimensionnées seront rangées dans un répertoire «HighRes ».

D’une façon générale, il faut bannir les textures « trop rectangulaire » du genre 4 X 504.

2.6 Conseils pour la réalisation des textures :

Les textures doivent Être « pré éclairées ».

Texture retouchée Texture originale

Texture retouchée Texture originale

Le but est d’accentuer les volumes des différents éléments des unités afin qu’ils soient plus

Lisibles et identifiables.

Il faut ABSOLUMENT travailler en perpétuel aller retour avec le viewer, et en zoom arriÈre max pour correctement juger de cette clarté de lecture..

originale retouchée

2.7 Options de l’exporteur ASE2

Lorsque vous exporterez vos modÈles, cocher la case « export textures » permet d’exporter les textures utilisées par le modÈle exporté, ds le mÊme répertoire que le fichier ase2.

3 – Informations sur le moteur de jeu/Ressources Fonctionnelles

Les cases IA

Une case IA est l’unité qui détermine la plus petite surface considérée par le moteur de jeu. Elle mesure 136 unités génériques. Les dimensions d’un élément du jeu sont toujours exprimées en cases IA. Pour avoir sous Max un repÈre correspondant aux cases d’IA, configurez votre grille comme ceci (Grid spacing = 13,6).

3.2 Les Boites Fonctionnelles à incorporer dans les modÈles

Les boites sont des éléments qui ne sont pas visibles dans le jeu, mais qui déterminent certaines fonctionnalités du moteur de jeu.

Les boites ponctuelles – pour le positionnement d’effets

L’emplacement du pivot de ces boites détermine la position considérée par le moteur. L’orientation retenue est celle de l’axe local X de la boite.

Un point est signalé par une boite (exemple : boite Alcove)

Les noms de ces boites sont importants, ils sont composés d’un radical et d’un incrément.

Certains types de boites ne sont applicables qu’a certains batiments.

Attention :

• les propriétés des boites ne doivent comporter ni cast shadow et receive shadow. Au besoin, utiliser le script de vérification de boite.
• Ces boites seront directement créées dans le fichier max du modÈle.

A - Boites Ponctuelles

Ces boites sont utilisées principalement pour placer des repÈres dans les fichiers max, qui serviront de repÈre de placement pour des effets dans le jeu (placements de soldats dans des batiments, effets de tirs, placements pour un radar…)

Legende :

BB = Batiments de bases ( ex : HeavyFactory etc….)

BG = Batiments Génériques (par « blocs »)

BS = Batiments Spécifiques (ex : Capitol etc…)

BM = Batiments Mixtes (ex : Batiments San Fransisco, Batiments Londres)

DE = Eléments de décors ( ex : Mobilier urbain, etc…)

UI = Unités d’infanterie (soldats)

V = Véhicules (chars, etc…PAS LES VEHICULES DE DECORS)

B - Les boites Volumiques (VBox)

Ces boites sont utilisées pour définir des surfaces ou des volumes.

Pour cette catégorie de boite, le volume interprété sera celui de la bounding box de la boite, pour les surfaces, la dimension sur Z est ignorée. Il est donc important que la boite ne subisse aucune rotation.

Les noms de ces boites sont composés d’un radical commençant par « V » et d’un incrément.

Important : Le Pivot des VBox doit impérativement Être orienté sous Max en suivant celui du monde. Si cela n’est pas le cas, le moteur interprétera aléatoirement les infos d’orientations de La VBox.

Introduction

Afin d’avoir un retour visuel au plus proche du moteur de jeu directement dans Max, les matériaux à utiliser dans Max seront exclusivement des Matériaux de type « DirectX9 Shader ». Il sera donc impératif de travailler sous Max 7, et d’utiliser les matériaux créés spécialement pour le jeu (ces matériaux contiennent uniquement des paramÈtres pris en compte par le moteur du jeu). De plus, il faudra veiller à ce que Max utilise l’affichage DirectX (Customize/Preferences/Viewport/Display Drivers/Direct 3D)

Utilisation d’un Matériau de type « DirectX9 Shader »

A partir d’un matériau de base de Max, choisir le type « DirectX9 Shader ».

Attention : Une fois le type « DirectX9 Shader » choisi, une fenÊtre « Replace material » s’ouvre : Choisir « Discard old Material », et non pas « Keep old material as sub-material », proposé par défaut.

Une fois le type de matériau choisi, il faut charger le type de .fx associé au shader à utiliser. Les fichiers .fx utilisables sont au nombre de 3 :

_Eug_Standard.fx

- _Eug_BlendAdd.fx

- _Eug_Vitre.fx

Chaque matériau (Standard, BlendAdd ou Vitre) se présentera de la maniÈre suivante :

1 – Description du shader « _Eug_Standard.fx »

Ce shader sera utilisé le plus couramment ; il permet de créer les matériaux comportant une diffuse (avec ou sans couche alpha), les matériaux comportant une couleur de camp.

Il permet également les réglages des intensités spéculaires, via la texture utilisée dans le champ « specular level » et à la valeur du specular power (qui agit comme la valeur « glossiness » des matériaux standard de max, à savoir la taille de la tache spéculaire).

Il permet, si on choisit une technique « envmap », d’utiliser des textures d’environnement dans les reflets spéculaires (on obtient alors un materiau équivalent au type « chrome » ).

ParamÈtres de _Eug_Standard

Diffuse / Camp Map : Choix d’une texture diffuse avec ou sans alpha (la couche alpha sera interprétée différemment, à savoir comme valeurs de transparence ou zone de couleur de camp, selon le type de technique choisie).

Specular Level : Choix de la texture servant de masque pour les reflets spéculaires. Permet de définir un masque de réflexion spéculaire. Aux endroits oÙ la texture est blanche, la réflexion spéculaire est maximale, et au endroit oÙ la texture est noire, il n'y a pas de réflexion spéculaire. Les valeurs intermédiaires (niveaux de gris) sont acceptées.

Specular Power : Taille du reflet spéculaire (équivalent au « glossiness » des matériaux standard de Max). Plus la valeur est élevée, plus la tache spéculaire sera grande.

Env Map (ParamÈtre non exporté dans le moteur ) : Permet de choisir une image pour pouvoir visualiser sous max un matériau de type envmap ; la texture choisie se reflÈte dans la zone spéculaire du matériau. Cette texture doit Être au format .dds.

Couleur de camp (ParamÈtre non exporté dans le moteur) : Permet de choisir une couleur de camp (dans le cas du choix d’une technique « camp » ou « EnvMap_Camp ») pour la visualiser dans Max.

Light direction (ParamÈtre non exporté dans le moteur) : Permet de choisir une source de lumiÈre présente dans la scÈne max afin de visualiser le modÈle éclairé dans max.

Techniques associées au shader Eug_Standard :

Defaut : la map Diffuse/Camp est utilisée comme diffuse.

Pour ajouter de l’opacité dans un matériau, il faut que la texture contienne une couche alpha, qui sera prise en compte par le moteur. Cependant, il ne prendra pas en compte les niveaux de gris de la texture : ce qui est en dessous de 128 128 128 (RGB) sera considéré comme totalement transparent, et ce qui est égal ou au dessus de ces valeurs sera interprété par le moteur comme étant totalement opaque, laissant apparaitre la texture.

Envmap : map Diffuse/Camp interprétée comme pour la technique « défaut », mais le matériau utilisera une Env Map dans le moteur (reflet dans les valeurs spéculaires).

Camp : Identique à la technique « Defaut », mis à part que la couche alpha de la map « diffuse/camp » sera utilisée comme couleur de camp et non pas comme couche d’opacité.

L'alpha de la texture indique la puissance de la couleur de camp : la texture peut contenir une bande couleur de camp et une partie « normale » : l’alpha définira ou appliquer la couleur de camp. Cette couche alpha supporte les niveaux de gris : les parties en noir de l’alpha laisseront apparaitre la texture normalement, et plus elle va vers le blanc, plus la couleur de camp sera apparente dans la texture.

Exemple ci-dessous :

+ =

Texture Couche Alpha résultat dans le moteur

Recommandations : - La couche alpha de la texture recevant la couleur de camp devrait Être en noir pur et blanc pur : la partie blanche recevra la couleur de camp et la partie noire fera apparaitre la texture diffuse.

Attention : les textures avec des infos de couleur de camp doivent impérativement Être nommées _Camp à la fin.

Ex : US_abrams_canon_Camp.tga

Envmap_Camp : Identique à la technique « Envmap », mis à part que la couche alpha de la map « diffuse/camp » sera utilisée comme couleur de camp et non pas comme couche d’opacité.

2 – Description du shader « _Eug_BlendAdd.fx »

Ce shader sera utilisé pour obtenir un matériau de type « self illum » : rendu de type blend additif.

ParamÈtres 

Self Illum : permet de choisir la texture de self illum . Les valeurs les plus claires de la texture seront les plus lumineuses, les plus sombres les moins lumineuses.

Technique

BlendAdd_NoAlpha : Technique par défaut. La texture ne comportera pas de couche alpha (si il y en a une, elle sera ignorée !) .

Blend_WithAlpha : Dans ce cas, la couche alpha n’est pas ignorée. Le matériau utilisera la valeur de l’alpha pour la transparence. Le matériau utilisant cette technique ne projettera ni ne recevra d’ombre.

3 – Description du shader « _Eug_vitre.fx »

Ce shader sera utilisé pour réaliser les matériaux de type vitres.

ParamÈtres

Vitre Texture : Texture de la vitre, qui doit comporter une couche alpha.

Attention : les textures des matériaux vitres doivent impérativement Être nommées _Vitre  à la fin de leur nom.

Env Map (paramÈtre non exporté) :Permet de tester la vitre avec une texture de réflexion qui se réfléchira dans la vitre. Cette texture doit Être au format .dds.

Light Direction (paramÈtre non exporté) : permet de choisir une source lumineuse dans la scÈne max, qui sera prise en compte dans le retour visuel du viewport Max..

Technique

Vitre : Le matériau aura un aspect de vitre « standard », plus ou moins transparente selon la couche alpha de la texture présente dans  le champ « Vitre Texture ». Les zones de la couche alpha noire seront transparentes, les zones blanches seront opaques. Tiens compte des niveaux de gris.

VitreMiroir : Le matériau a un aspect de vitre « miroir », plus ou moins réflechissant selon la couche alpha présente dans le champ « vitre Texture ». Les zones de la couche alpha noire réfléchiront le plus la lumiÈre, les zones blanches la réflechiront le moins. Tiens compte des niveaux de gris.

1 – Batiments Génériques

Les batiments génériques utilisés dans Act Of War sont modélisés sous formes de blocs modulaires, qui permettront de réaliser différents types de batiments à partir d’un « kit » de blocs par type d’architecture. Ce systÈme permet de limiter le nombre de modÈles de base et de les utiliser afin de construire une multitude de batiments d’aspects différents. Par contre, il impose un certain nombre de contraintes (détaillées dans ce document) sur la façon de modéliser les blocs, afin que ceux-ci puissent Être correctement placés dans le moteur du jeu.

1.1 – Liste des blocs utilisés pour 1 type d’architecture.

Les batiments seront construits sur plusieurs niveaux : le niveau bas, qui correspond au rez-de-chaussée/boutique, le niveau  corniche, le niveau étages, qui peut Être utilisé plusieurs fois, permettant de construire des batiments ayant des nombres d’étages différents, et le niveau haut, qui comporte un étage et le toit du batiment.

5 blocs différents ont étés recensés pour les niveaux bas, milieux, et corniche, les blocs haut en comportant 1 de plus (dalle centrale du toit).

Les lignes en noir symbolisent les murs des blocs, les parties en bleu et en rose étant des repÈres visuels pour l’échelle des blocs par rapport à la grille d’IA utilisée par le moteur du jeu. La partie bleue a une dimension de 6cases IA sur 6. La partie en rose symbolise l’espace extérieur a ces 6 cases. Les parties en vert représentent en fait les détails architecturaux « dépassant » des murs (corniches…). Tous ces détails seront situés à l’extérieur de la zone bleue. A l’inverse , les détails « rentrants » (rebords fenÊtres…) seront extrudées à l’intérieur de la zone bleue.

Exemple :

 

Blocs des niveaux bas, corniche et étages :

Bloc A Bloc B Bloc C

 

Bloc D Bloc E

On peut classer ces blocs par « familles » : les blocs A, B, C, D et E, les blocs d’étages (blocs « milieu ») comportant des variantes (voir plus bas dans ce document).

Les blocs de bases comportant des portes seront également décrits plus loin dans ce document et seront à ajouter.

Blocs du niveau haut :

Ils sont identiques en terme d’occupation que les blocs des autres niveaux, a l’exception qu’ils comportent un toit (face au-dessus en plus par rapport aux blocs milieux et bas) et un bloc de plus (bloc F) pour les zones de toit centrales.

Bloc F

La zone en jaune représente le toit.

Important : le systÈme d’éclairage du moteur de jeu nécessite que les toits des blocs comportent un certain nombre de faces pour que l’éclairage rende bien. Pour chaque bloc de toit, la surface du toit sera donc subdivisée en 4 * 4 polygones (voir ci-dessous) :

Exemple d’assemblage de différents blocs :

 

Ci-dessus : différents blocs (B) utilisés pour la construction de l’angle d’un batiment à 3 étages (le dernier étage est inclus dans le bloc du haut, afin que son étape de destruction soit sympa graphiquement : si on n’avait mis que le toit tout seul, le résultat serait ridicule ;)).

Résultat des blocs précédents assemblés :

Exemple de batiment réalisable à partir de blocs :

Sorties de toit :

Les unités pouvant se rendre sur les toits des batiments, il faudra réaliser des sorties à placer sur ces toits. Etant donné que les unités ne seront pas exactement à l’échelle des batiments, on ne fera pas de sorties de type « cabanes », qui risqueraient de poser problÈme. Il faudra que ce soient des trappes, qui pourront Être posées sur les toits des batiments.

Exemple de sortie de toit (exemple basique…)

Il faudra penser à laisser un polygone à l’intérieur de la sortie, légÈrement surélevé par rapport à 0, afin d’y plaquer une texture simulant la sortie (trou) :

1.2 - Conseils pour la réalisation des blocs d’un type d’architecture

Le plus simple est de réaliser 4 « blocs de référence » : un bloc pour la partie « base » , un pour la partie « corniche », un autre pour la partie « milieu » (étages), et un dernier pour la partie « Toit ».

Par convention, on nommera les blocs de la maniÈre suivante :

Blocs de bas   : « BlocBase_nomdubloc » (Ex : BlocBase_E)

Blocs de corniches  : « BlocCorniche_nomdubloc »

Blocs d’étages   : « BlocMilieu_nomdubloc »

Blocs de toit : « BlocHaut_nomdubloc ».

Les sorties  : « BlocToitA_Sortie »

Pour les versions détruites des blocs, on aura le mÊme nommage , avec « _Dest01 » et « _Dest02 » à la fin du nom, pour les étapes de destruction1 et 2.

Particularités :

- Les Blocs base comportant une porte seront nommés « BlocBase_nomdubloc_Porte » (ex : BlocBase_B_Porte).

- Les Blocs Milieu et toits détruits entiÈrement (Dest02) auront 2 modÈles différents, afin de faire varier les cassures. La variation du bloc détruit sera alors nommé « Blocmilieu_X_Variation_Dest02 »

Les blocs de référence sont en fait les « blocs  A », qui contiennent les 4 côtés du mur. A partir de ces blocs, il suffira de retirer des côtés pour réaliser les blocs B, C, D, E et F.

Les différents Blocs pouvant Être manipulés dans le moteur du jeu (rotations), leur bords doivent avoir strictement la mÊme épaisseur, afin qu’ils s’ajustent parfaitement entre eux dans toutes les positions possibles. Le mieux pour cela est de placer les vertex d’une façade en entrant leur coordonnées numériquement dans Max. Pour que les blocs tiennent sur 6 cases d’IA dans le jeu, j’ai relevé les valeurs des placements des vertex de façades :

Le modÈle devra Être réalisé au centre du repÈre max, afin de pouvoir relever les valeurs de vertex. De plus, lorsque le modÈle exporté est créé dans le moteur du jeu, il est placé par rapport à son placement dans max, et doit toujours Être centré sur le repÈre de celui-ci en X et Y. Pour l’axe Z, ce qui est en dessous de 0 en Z sera sous le sol dans le moteur de jeu : le bas des blocs devra donc Être placé sur 0 en Z. Ceci est également valable pour les blocs d’étage, car c’est dans le moteur qu’ils seront « collés » aux blocs inférieurs.

Exemple pour les coordonnées d’un mur :

Sur l’image ci-dessus, les vertex du mur gauche du bloc sont alignés et ont leur coordonnées en Y= - 408 (se mettre en repÈre « world » dans Max). Ces valeurs sont celles permettant d’avoir des blocs qui occuperont exactement 6cases d’IA sur 6 dans le moteur de jeu.

La hauteur variera d’un type d’architecture à l’autre : pour mes test, mes blocs de base avaient une hauteur de 550, mes blocs étages 250 et mes blocs toit 270 environ.

Pour les détails « extérieurs » (corniches) et « intérieurs » (fenÊtres) des murs, leur taille dépendra de l’architecture du batiment. Il faudra cependant veiller à ce que les valeurs d’extrusion de ces détails soient les mÊmes pour tous les côtés, de la mÊme façon que pour les murs.

Attention : pour les blocs de type A,B et E, il faudra réaliser l’intérieur des murs de façade (voir ci-dessous), car ce sont les seuls blocs ou l’on pourra voir l’intérieur en vue InGame ( à travers les fenÊtres). Les autres blocs ont juste besoin de leur façade extérieure, avec, dans les 2 cas, des murs intérieurs (voir partie suivante décrivant les sols de blocs).

Les modÈles devront avoir le mÊme aspect dans la vue Top de max que dans la liste du début de ce document (dessins des blocs).

Les blocs d’étages et de toit devront comporter un sol . En effet, on pourra voir à travers les fenÊtres des batiments, et ce sol est donc nécessaire. Pour le niveau bas, il conviendra de réaliser un sol légÈrement surélevé, afin d’éviter des problÈmes de Z-Buffer au niveau du sol. Du coup, les points d’entrées de batiments (portes) comporteront une marche, qui mÈnera au niveau du sol de rez-de-chaussée.

Cependant, afin d’améliorer les perfs du jeu, qui se joue en vue aérienne, il faudra que les planchers intérieurs soient limités à une surface la plus réduite possible : le mieux est donc de réaliser le plancher uniquement derriÈre les fenÊtres, cad à l’endroit ou les unités pourront se poster. Etant donné que l’on pourra voir à travers les fenÊtres, il faudra également construire les murs intérieurs. Voir exemple ci-dessous :

Afin de laisser assez d’espace pour le placement des unités derriÈres les fenÊtres, la largeur des planchers intérieurs devra Être d’environ 145.

1.3 – Etapes de destruction

Chaque bloc constituant un batiment peut Être détruit indépendamment des autres. Il y a deux étapes de destruction : la premiÈre modifie uniquement la texture des blocs (impacts d’explosions…), et la deuxiÈme détruit le bloc.

Pour réaliser les blocs détruits de l’étape de destruction 2, le plus simple est de partir du bloc intact correspondant et de le modifier : il faudra impérativement laisser les vertex de bords des blocs (ceux étant en contact avec des blocs voisins) intacts, afin que les blocs soient toujours contigus entre blocs intacts/détruits ou détruits/détruits (voir ci-dessous). Par contre, dans l’étape de destruction 2 des blocs, les sols intérieurs des blocs devront Être modelisés de façon à correspondre à la surface entiÈre du bloc.

BlocMilieu_B (intact)

BlocMilieu_B_Detruit

Exemple de résultat d’un batiment partiellement détruit :

Lors de l’étape de destruction 2 des blocs, il faut faire apparaitre l’épaisseur et la partie intérieure des murs, ainsi que les murs intérieurs (on ne fera pas de portes à l’intérieur des batiments, car on verrait du vide derriÈre !!!).

Pour les Blocs base détruits, il faudra veiller à ce qu’il reste toujours un passage pour les unités, car tant que l’immeuble n’est pas entiÈrement détruit, les unités devront pouvoir accéder aux blocs accessibles (toits ou fenÊtres).

1.4 - Portes et fenÊtres

Etant donné les restrictions imposées par la mise en place du systÈme, les portes et fenÊtres ne contiendront pas d’animations : il faudra que les portes soient donc réalisées en position ouvertes. Les portes seront réalisées à partir des blocs bases (variations de ces blocs avec ajout de portes). Les fenÊtres ne seront pas toutes ouvertes : il faudra en laisser fermées et d’autres non. Pour les blocs étages, le mieux est de faire des variations à partir des blocs, afin de ne pas se retrouver, lors de la construction des batiments, avec une colonne de fenÊtres ouverte et une autre fermée.

1.5 - Box à associer aux blocs des batiments génériques

Les box sont à mettre uniquement dans les modÈles intacts des blocs

Les boites à associer aux différents blocs sont les suivantes :

- Pour les blocs ne comportant pas de fenÊtres ouvertes, ni de portes, 4 box suffisent : 2 box pour indiquer sol (sol_01 et sol_02) définissant la base du bloc, et 2 box plancher définissant le haut du bloc (voir ci-dessous). Ces box seront utilisées pour avoir les infos de placements des blocs les uns par rapport aux autres lors de leur assemblage, les infos d’occupation au sol, de visibilité, et de collision. Elles devront donc Être placées rigoureusement, l’info reprise par le moteur étant les coordonnées du point de pivot des box. Elles devront Être calées aux bords extérieurs des murs des blocs (voir ci-dessous).

 

Ainsi, en reprenant l’exemple utilisé dans  2- (Conseils pour la réalisation des blocs d’un type d’architecture ) , les coordonnées des pivots des box seront donc (X,Y,Z):

Plancher_01 : 408, 408, 550

Plancher_02 : 408, -408, 550

Sol_01 : -408, -408, 0

Sol_02 : 408, 408, 0

- Pour les blocs comportant des fenÊtres ouvertes, il faudra placer des box « alcôves » derriÈre ces fenÊtres, qui serviront de repÈres pour le placement des soldats se postant aux fenÊtres. Il faudra donc les caler par rapport aux mesh des soldats, sachant que c’est la base de ce soldat qui se placera sur le pivot des box alcôves. Si besoin est, il faudra donc baisser légÈrement les box alcôves par rapport au sol du modÈle du bloc, afin que le haut du corps et la tÊte des soldats apparaissent aux fenÊtres.

- Enfin, les blocs de sortie ( BlocToitA_Sortie ) comporteront 2 box « occupation » (occupation_01 et occupation_02), qui definiront une zone interdisant aux soldats de traverser la sortie une fois sur le toit, ainsi qu’une box « entree_01 », définissant le point d’arrivée des unités pour accéder au toit ou en redescendre. Ces blocs ne comporteront pas de box « plancher », mais auront par contre les box « sol » (voir ci-dessous).

En arriÈre plan sur ce schéma, j’ai mis un bloc_haut, afin de visualiser ou se placera la sortie.. Typiquement, dans le cas ou le joueur clique sur le toit d’un batiment pour y placer ses unités sélectionnées, celles-ci se dirigeront vers le le mur le plus proche, puis reparaitront à l’emplacement de la box entrée_01. Celle-ci doit donc Être positionnée en 0 en Z, afin que l’unité se retrouve bien à la hauteur du toit .

1.6 – Les Boutiques

Les Batiments génériques sont prévus de telle maniÈre que les « Blocs Base » et « Blocs Corniche » puissent Être remplacés pour n’importe quel type d’architecture par des Blocs base spéciaux de boutiques. Cela permet d’ajouter de la variation aux immeubles, et de faire des quartiers commerciaux. On se limite à n’utiliser que des blocsbase et corniche de type B et C pour les boutiques.

Les Blocs de base représenteront les devantures des boutiques (vitrines…), et les Blocs Corniches Les enseignes de ces boutiques. Cela signifie qu’un blocBase de boutique devra avoir un BlocCorniche qui lui correspond. Le nommage des fichiers devra donc Être explicite, de maniÈre a repérer le bloc corniche associé au bon blocbase.

Ex : BlocBase_B_Books et BlocCorniche_B_Books

Tout comme pour les BlocsBase normaux, les Blocs “Boutiques” auront des variation pour avoir des portes.

Exemple :

BlocBase_B_Books BlocBase_B_Books_Porte

 

BlocBase_C_Books BlocBase_C_Books_Porte

BlocCorniche_B_Books BlocCorniche_C_Books

1.7- Resumé

Batiments spécifiques

Dans Act Of War, les batiments spécifiques désignent les grands batiments de décors (ex : Capitol…). Les unités de jeu peuvent entrer à l’intérieur de ces batiments, mais pas aller sur les toits.

Ces batiments sont découpés en « Parties », chaque partie étant considéré comme un batiment indépendant (chaque partie est sélectionnable indépendamment et les points de vies sont indépendants pour chaque partie). Chacune de ces parties comportera un ou plusieurs groupes ; ces groupes définissent les plus petites parties destructibles (mÊme si un seul objet ) des parties.

2.1 - Box à associer aux parties d’un batiment Spécifique

Chaque comporter une ou plusieurs Vbox de : Sélection, Sol et Vision. Elles devront également comporter une Box située au centre de la partie, qui servira a déterminer la direction du tir des soldats qui attaquent la partie du batiment, ainsi que la direction suivie par les soldats pour pénétrer dans la partie.

Les endroits susceptibles d’accueillir des soldats (fenÊtres, meurtriÈres…) comporteront des boites alcôves. Ces alcôves devront Être nommées en fonction du Groupe et de la partie auxquels elles appartiennent.

Comme d’habitude, les Vbox Sol devront Être snappées sur les cases d’IA.

Important : Afin de pouvoir intégrer le batiment dans le moteur de jeu de maniÈre fonctionnelle, il faut pouvoir identifier les groupes appartenant à chaque partie d’un batiment spécifique.

2.2 - Nommage des box 

Les conventions de nommages seront les suivantes pour les Boites d’une partie (je reprends pour l’exemple l’AirAndSpaceMuseum, voir schéma ci-dessous).

XX = Nom de la partie dans laquelle appartient la VBox

YY = Numéro de la Vbox

2.3 – Nommage des fichiers

Les batiments spécifiques sont eux aussi constitués de morceaux, mais moins modulaires que pour les batiments génériques. Ces morceaux constituent en fait un découpage du batiment spécifique, et ont un nom commun au sein du fichier, complété par un incrément et un éventuel niveau de destruction.

Exemple de nom de fichier : WASH_OldExecutive_Dest01 : batiment « OldExecutive » en destruction 1.

Batiments Mixtes

3.1 - Présentation

Les batiments « mixtes » sont des batiments génériques trop complexes pour Être construits par la méthode traditionnelle par blocs. Ils combinent les méthodes des batiments génériques et des batiments spécifiques pour leur mise en place :

Ils ne sont pas découpés en parties, mais directement en groupes (chaque partie destructible est groupée).

Comportent une ou plusieurs Vbox de Visions et de Sélection (Vvision et Vselection)

Comportent une ou plusieurs Box Vsol

Ils peuvent avoir des Alcôves, qui devront Être nommées selon l’appartenance aux groupes dans lesquels seront situées les alcôves (Alcove_GroupXX_YY)

Les batiments mixtes permettent également d’avoir une (une seule !) partie permettant a des soldats d’accéder à un « plancher » ex ; toit, terasse…

Des Box d’occupations (« VOccupation_XX ») peuvent également Être présentes sur les planchers, pour interdire l’accÈs à certaines parties du plancher (exemple ; éléments présents sur un toit comme des cheminées, antennes etc…).

Pour les batiments Mixtes comportant un plancher, une Box « Entree_01 » sera placée à l’endroit ou l’unité apparaitra lorsqu’on lui dira de se rendre sur le  plancher.

- Description du plancher

Le plancher, si il yen a un, devra Être défini par plusieurs Vbox :

Une Vbox « Vplancher_01 » qui sera placée de maniÈre à englober toute la surface du plancher.

Une ou plusieurs Vbox « VMorceauPlancher_GroupXX », qui seront placées au niveau des surfaces du plancher, mais auront la taille des groupes inclus dans ce plancher. Il y aura donc autant de Vbox VmorceauPlancher que de groupes associées à ce plancher. (Voir Illustration ci-dessous).

4 Les Elements de décors

Les élements de décors d’Act Of War regroupent tout ce qui n’est pas contrôlable par le joueur ; ces éléments regroupent le mobilier urbain, les ponts, véhicules de décors, etc.

4.1 - Elements de décors

Regrouper le mobilier urbain spécifique à une ville ou un pays et en fonction des matériaux qu’ils utilisent.

Exemple de nom de fichier : US_SET_Trash: une poubelle intacte aux USA, version détaillée

4.2 - Véhicules civils

Les véhicules civils sont susceptibles de pouvoir circuler. Dans ce but, il est nécessaire que les roues soient des objets indépendants

Exemple de nom de fichier : US_SET_Cadillac_Dest02 : une Cadillac détruite version détaillée

5 Les Unités de jeu contrôlables

5.1 - Les Véhicules

Exemple de nom de fichier : US_Humvee : un Humvee américain tout neuf version détaillée.

5.2 - Les Unités d’infanterie

Lorsque deux personnages sont présents dans le fichier (pour le mortier par exemple), les biped doivent avoir des noms différents.

Les batiments de Bases

6 Les Etapes de destruction

Tous les éléments dans le jeu doivent pouvoir Être détruits. Pour cela, il est nécessaire qu’une ressource soit déclinée selon plusieurs étapes de destruction. On distingue, dans la plupart des cas, l’état intact, la destruction 1, et la destruction 2. Une ressource graphique est souvent déclinée dans 3 fichiers nommés différemment, mais contenant des éléments qui gardent le mÊme nom.

La forme générale du nom de fichier est :

<NomdeFichier> pour la version intacte

<NomdeFichier>_Dest01 pour destruction 1 : l’élément est abimé mais reste fonctionnel.

<NomdeFichier>_Dest02 pour la destruction 2 : l’élément est détruit.

Important : pour les éléments de décors destructibles , il faudra classer les ressources 3D en deux catégories : éléments « écrasables » et éléments « renversables », selon le modÈle de destruction réalisé (exemple : un poteau qui tombe = modÈle renversable ; un banc detruit qui est en morceaux = modÈle écrasable).