Catégories
ModMaking

Megatexture on air

Les coyotes de Doom3world ont réussi à faire fonctionner la techno ‘MegaTexture’ sous Doom 3, Q4 et Prey.

Pour les plus pressés, la version initiale (non lightmappée) se télécharge sur FileFront

Ceux qui s’intéressent au fonctionnement de tout ce bordel, et notamment la méthode pour activer les stencil shadows peuvent lire la suite 🙂

Comment ?

Tout le monde l’a dit et répété, en testant quelques trucs dans la console de Doom 3, on obtient quelques commandes rigolotes du style makeMegaTexture. Sauf que jusqu’ici, personne ne semblait avoir réussi à les faire fonctionner.

En programmant un fragment shader qui active le changement de LOD en fonction de la position du joueur, Arne Olav Hallingstad a réussi à activer le support de la megatexture sous Doom 3, Q4 et Prey.


Les différents niveaux de mipmap

Comment ça se passe ?

Pour faire fonctionner le tout, il nous faut :

– Un mesh plat de terrain
Format .lwo – Lightwave (mais le .ase est également supporté)
Ce terrain doit avoir une longueur d’une puissance de 2 supérieure à 128 unités. (ex: 512×512, le maximum étant 32768×32768)

– Un Heightmap
Il va agir comme « displacement modifier » sur le mesh plat pour le déformer et en faire un vrai terrain.
En niveau de gris (8bits / 256 couleurs), peut importe la résolution du moment qu’elle est carrée.

– Une texture de terrain qui correspond au heightmap, mais en version couleur
Format .tga
Cette texture doit être calibrée au format du terrain. (ex: terrain de 512×512 -> texture de 512×512)

– Le bon material qui associe le mesh de terrain à la megatexture
megatexture/terrain
{
qer_editorimage megatextures\terrain_preview
{
blend filter
megaTexture terrain4096_doom3.mega
}
{
map _white
blend diffusemap
}
}

– Un exemplaire de Doom 3, de Prey ou de Q4 pour générer la MegaTexture à partir du TGA de référence

Conception

C’est applicable à Doom 3 pour le moment. Avec quelques modifs au niveau du nom des dossiers, c’est adaptable à Q4 et Prey

– Créez votre mesh plat d’une dimension de 16k x 16k unités. Appliquez-lui le material ‘mon_terrain’
– Appliquez-lui comme « displacement/heightmap modifier » votre image heightmap
– Exportez votre mesh au format lwo ou ase
– Placez le terrain dans le dossier base\models
– Creez l’image de votre terrain. On va l’appeller ‘mon_terrain.tga’. Vous pouvez vous aider d’outils comme WorldMachine ou Terragen pour faire cela. Cette image doit avoir une résolution équivalente au terrain (ici, 16k pixels).
– Placez l’image ‘mon_terrain.tga’ de votre terrain dans le dossier base\megatextures (Créez-le si nécessaire)
– Lancez Doom 3 en mode console, puis tapez makeMegaTexture mon_terrain.tga. Ca génère la MegaTexture (mon_terrain.mega) à partir de votre image de référence.
– Réduisez votre image ‘mon_terrain.tga’ afin quelle ne fasse plus que 2k pixels de côté, puis renommez-la en ‘mon_terrain_editeur.tga’
– Créez le material d’association terrain / texture en vous inspirant des lignes suivantes :
megatexture/mon_terrain
{
qer_editorimage megatextures\mon_terrain_editeur.tga
{
blend filter
megaTexture mon_terrain.mega
}
{
map _white
blend diffusemap
}
}

– Placez le material dans base\materials et changez l’extension .txt en .mtr
– Créez votre map. Une skybox simple suffit, avec l’import du model de terrain, et l’ajout d’une source de lumière.
– Faites une compile.
– C’est prêt.

Conclusion

On constate à la fin de ce tutorial, que le workflow n’est pas trop mal. L’inconvénient réside dans la peinture du TGA de référence, qui est très longue. Cela dit, les tools d’ETQW devraient permettre l’auto-génération de la texture de terrain, et le level artist n’aura plus qu’à ajouter des détails aux endroits qu’il souhaite.

Ressource / Bibliographie
id Dev Network – Format des models
Discussions et expérimentations autour du format (Doom 3 World)
Les spécifications de la MegaTexture (Gamedev.no)

13 réponses sur « Megatexture on air »

oui la megatexture était initialement prévue pour doom 3, d’ailleurs dans la console il y’avait une commande r_megatexture.

Béh, désolé mais, même si ce procédé est revolutionnaire et qu’il apporte un certains gain sur les perfs et (ou) améliore quoi que ce soit, moi quand je regarde les 5 images, je trouve çà surtout "mégamoche".

Mais bon, ca peut avancer dans le bon sens, ca doit juste manquer de maturité je pense, non ?

Quand j’ai matter les screen j’ai de suite pensé à une map de Tribes 2 ^^

C’est "mégamoche" parce que c’est juste une utilisation expérimentale par des gens qui ne connaissent pas l’outil et qui ne disposent pas de toutes les informations nécessaire.
Suffit de jeter un oeil au screen de Quakewars pour contempler ce que ça donne correctement utilisé.

En tout cas avec le moteur de Doom 3 on peut dire que chez ID ils se sont bien débrouillé. Il n’a pas vraiment eu besoin de subir de grosse évolution et des le début il disposait de tout ce qu’il fallait pour s’adapter a de futur jeux (de plus en plus ouvert) et aux gains de puissance des bécanes.

Donc il y aurait bien un système de LOD sur la texture (contrairement au terrain)… Comment le moteur gère les échanges d’une telle quantité d’information entre la RAM et la carte vidéo ? Tout est streamé au fur et à mesure dans la carte ? J’ai du mal à croire que c’est ce dont parlais Carmack à l’époque …

J’ai retrouvé à l’instant les propos qui me gènent :
… just let them [Splash Damage] treat one uniform geometry mesh and have this effectively unbounded texture side on there, and use a more complicated fragment program to go ahead and pick out exactly what should be on there, just as if the graphics hardware and the system really did support such a huge texture.

Je suis le seul à trouver que ça ressemble à de la génération procédurale depuis une texture "de matériaux" ? (et non simplement "juste" une grosse texture diffuse avec 3 niveaux de LOD comme démontré chez Doom3World)

Xfennec : il me semble (j’avais lu ça quelque part) que la megatexture était streamée à partir du disque dur, justement pour éviter de saturer la RAM.

Je suis le seul à trouver que ça ressemble à de la génération procédurale depuis une texture "de matériaux" ? (et non simplement "juste" une grosse texture diffuse avec 3 niveaux de LOD comme démontré chez Doom3World)
Et pourtant c’est le cas : un seul diffuse map (auquel sont censés s’ajouter une map de speculaire et une de normales sous QW) est appliqué sur le terrain.

Les autres : pourquoi c’est moche ?
-> résolution de la texture faible
-> pas de normal maps
-> pas de lightmaps

"Les autres : pourquoi c’est moche ?
-> résolution de la texture faible
-> pas de normal maps
-> pas de lightmaps"

Sur cet exemple bricolé par des gens avec trop de temps de libre. Si vous voulez voir ce que ça donne "en vrai" allez voir des screens d’ET:QW.

Après avoir regardé à droite et à gauche sur le sujet (en particulier les liens que tu donnes channie, merci), je suis plus que dubitatif (ou alors je capte rien, ce qui reste tout à fait possible) … En tout cas j’ai du mal à croire que cette techno est belle et bien celle que l’on voit sur les screens d’ET:QW et celle dont Carmack est si fier.

Plusieurs choses:
– Pourquoi les mecs de Doom3world se contenterait d’une "résolution de la texture faible" pour justifier un rendu aussi flou ? OK, ils sont limités à 16k x 16k là ou Splash arrive à du 32k x 32k … mais la différence de rendu de détails est énorme entre les screens de D3W et ceux d’ET (normal map ou pas) :
regardez cette image, par exemple, et plus particulièrement le sol. Comparez avec le screen de D3W. Je vous le dit pour avoir beaucoup joué (et travaillé) avec des rendu de terrain en TR : il est strictement impossible d’arriver à un tel niveau de détail avec une seule texture appliquée sur l’ensemble du terrain, fusse t-elle en 32k 🙂 Il y a ici clairement une texture de détail … et nulle trace de cette dernière sur les autres screens.

– Pour moi, avoir 3 niveaux de LOD pour la texture et laisser un fragment shader faire le choix du niveau de LOD à appliquer en fonction de la distance du fragment par rapport à la caméra n’a aucun impact positif sur les performances (au contraire !) … Ça rend juste plus joli (comme les mipmaps, tout simplement). Si vous n’êtes pas d’accord avec ça, laisser moi vous rappeler qu’un fragment shader ne peut faire le choix qu’entre des textures déjà chargées dans la carte ! (cf texture2D() et textureRect(), par exemple). Ca signifie ici que l’ensemble des niveaux de LOD doivent êtres chargés en même temps dans la carte. Y a un truc qui cloche, non ? 🙂

– De l’aveu même des découvreurs de cette technique dans Doom3, leurs tests passent leur temps à streamer depuis le disque, ce qui a pour impact direct de plomber fortement les FPS. Et ça malgré les optimisations de la structure du fichier ".mega" (alignements, paddings, …) Hors, rien de tout ça sur les vidéos ingame de ET:QW qui semblaient particulièrement fluides.

– Ensuite, quid des fortes pentes ? Avec un bête plaquage de texture, la texture se retrouve complétement étirée, voire sur 1D si la pente est à pic. Avez vous vu de telles choses sur les screen d’ET ?

– Et enfin le plus frappant pour moi : Carmack avait explicitement décidé que roaming, frustum culling, tiling de texture (ce que fait précisément le MegaTexture découvert dans Doom3) et autres techniques sur lesquels tout le monde creuse depuis 10 ans étaient absolument inadaptés au rendu de terrain dans un jeu moderne. Ca a même été la motivation principale de l’écriture de MegaTexture. Et là on nous dit que le fichier .mega n’est qu’un aggloméra de tiles de 128×128 avec 3 LOD ?! Et ou la "compression ultra spécialisée écrite dans le shader" révolutionnaire tant vantée ? Un bête LOD ?

Définitivement, pour moi (encore une fois, je suis peut être en plein délire) ce MegaTexture là n’est pas celui d’ET:QW … ou alors c’est un très vague brouillon qui à montré à Carmack que ce n’était pas comme ça qu’il fallait faire, et qu’ un minimum de génération procédurale était nécessaire pour arriver à un tel niveau de détails 😉

Ca signifie ici que l’ensemble des niveaux de LOD doivent êtres chargés en même temps dans la carte. Y a un truc qui cloche, non ? 🙂

et personne n’a dit que les chargement de maps nétaient pas longuets. A la dernière quakecon, la présentation s’est effectuée sur un diaporama. ça pourrait très bien être un moyen de cacher au gens que les loadings sont très longs.

Hors, rien de tout ça sur les vidéos ingame de ET:QW qui semblaient particulièrement fluides.

On ne voit pas les loadings de map.

Et là on nous dit que le fichier .mega n’est qu’un aggloméra de tiles de 128×128 avec 3 LOD ?! Et ou la "compression ultra spécialisée écrite dans le shader" révolutionnaire tant vantée ? Un bête LOD ?

Ben pourquoi pas, le but de mega texture
c’est surtout d’éviter d’avoir un sol tout moche car étant une seule texture peinte a la main qui doit être chargée en mémoire en entier. Avec cette méthode il peu se permettre de monter un terrain qui parait n’être qu’une seule texture (choses très difficiles a faire avec les tiles standard a moins d’utiliser du vertex painting), tout en gardant une taille de texture bien supérieure sans mettre a mal les configs.

– Ensuite, quid des fortes pentes ? Avec un bête plaquage de texture, la texture se retrouve complétement étirée, voire sur 1D si la pente est à pic. Avez vous vu de telles choses sur les screen d’ET ?

Alors ça ça a été expliqué: c’est un prb qu’ils ont "résolu" en repeignant avec les outils du sdk par dessus les zones abruptes. Et justement il me semble bien que les outils avec lesquels ils peignent ça c’est des tiles de materiaux qu’ils superposent sur la texture originale, comme on le ferait avec l’outil tampon de duplication dans photoshop.

Et pour la pente verticale a 100% Carmack a dit que megatexture n’était d’aucune aide. Pour celà on utilise des mesh props tout simplement.

Après comme tu le dis, le megatexture de d3 n’est probablement pas celui de quakewars. Faut bien faire ça progressivement, je pense que c’est juste le début du dev. Faut pas s’attendre a avoir la même chose sur d3 (q4 c’est ptet pas pareil le moteur a déjà pas mal été optimisé, on peut s’attendre a quelquechose de plus avancé).

P.S: Je ne considère pas détenir la vérité, je suis surement bien moins calé que toi en programmation ^^.

Pour ceux qui trouvent les images de d3 moches, faut pas oublier que 1: y’a pas les normalmaps
2: y’a pas les height map ("grain de la terre des caillous etc)
3: il n’ya pas sur ces même screens de fog (regardez bien sur les screen de quakewars y’en a toujorus un peu même si c’est pas toujorus trop visible) et surtout y’a pas l’éclairage ambient de quakewars qui fait un boulot sublime: génère les ombres des batiments et autre objets en temsp réel…

Je n’ai jamais parlé de temps de chargements 🙂 Je parle ici du poids monstrueux du streaming sur une telle quantité de données. (Tu charges 3 Go dans une carte vidéo, toi ?)
Et la démo en live à la Quakecon (que j’ai regardé environ 500 fois) est très convaincante sur ce point (framerate très constant, que ce soit au sol ou en l’air).

Du coup le LOD n’explique rien 😉 (LOD = 2 fois plus de mémoire consommée)
Et le problème est même plus conséquent que ça … Selon Gamedev.no, la MegaTexture de Doom3 (si elle pouvait monter en 32k x 32k) est en fait composée de 131072 textures (256*256*2, "chunks" issus du découpage de la grosse texture originale). Une carte vidéo correcte n’a que 8 TMU. Il fait comment le fragment shader ? Il faut faire 16000 passes par frame pour rendre le terrain ? 🙂

Pour les pentes : ça a été expliqué: c’est un prb qu’ils ont "résolu" en repeignant avec les outils du sdk par dessus les zones abruptes. Et justement il me semble bien que les outils avec lesquels ils peignent ça c’est des tiles de materiaux qu’ils superposent sur la texture originale
"Repeindre" par dessus n’est pas possible avec la méthode décrite ici (puisque la "grosse texture" est hors de ses capacités). Cet argument va donc au contraire dans le même sens que mon propos … cette texture n’est pas seule et est donc bien aidée par une génération de matériaux 🙂 (il y a donc aussi forcément une autre map qui contient ces informations)

Non, sérieusement, je capte rien à la bricole de Carmack.

– Pourquoi les mecs de Doom3world se contenterait d’une "résolution de la texture faible" pour justifier un rendu aussi flou ?
Parce que sous toshop, ça leur prend plusieurs minutes rien que pour "filler" d’une couleur unie un tga de 32k de côté.

Je vous le dit pour avoir beaucoup joué (et travaillé) avec des rendu de terrain en TR : il est strictement impossible d’arriver à un tel niveau de détail avec une seule texture appliquée sur l’ensemble du terrain, fusse t-elle en 32k 🙂
Pourtant, c’est théoriquement possible. Sur gamedev.no, ils te disent même que si tu fais une texture de 32000×32000 et non pas de 32768×32768 (puissance de 2), elle est shrinkée en 16k x 16k. A mon avis, là, y’a du détail sur le diffuse map.

Cela dit, le detail map, ca reste probable. Sachant que les type de Splash Damage arrivent a empiler normalmap, specmap, on voit mal pourquoi ils ne rajouteraient pas une detailmap.

Pour moi, avoir 3 niveaux de LOD pour la texture et laisser un fragment shader faire le choix du niveau de LOD à appliquer en fonction de la distance du fragment par rapport à la caméra n’a aucun impact positif sur les performances (au contraire !) …
La on parle d’un fragment shader programmé par un amateur. Le fragment program utilisé pour QW dont parle Carmack est certainement plus élaboré. Faut croire que l’activation du support de la MegaTexture sous Doom 3 ne nécessitait qu’un fragment shader gérant le LOD.

De l’aveu même des découvreurs de cette technique dans Doom3, leurs tests passent leur temps à streamer depuis le disque, ce qui a pour impact direct de plomber fortement les FPS.
Ouais, ça streame. Sauf que ça ne semble pas impacter négativement sur les perfs. J’ai testé chez moi, 60 fps constant (c’est d’ailleurs le cap).
Cela dit, quand on inspecte le poids de la megatexture, on tombe à 80Mo. Ce qui tient aisément dans la ram vidéo. Mais bon, y’a quand même des accès disque constants.

Ensuite, quid des fortes pentes ? Avec un bête plaquage de texture, la texture se retrouve complétement étirée, voire sur 1D si la pente est à pic. Avez vous vu de telles choses sur les screen d’ET ?
Carmack avait dit que c’était réparé dans son build interne. Il me semble que qu’il augmente localement la résolution de la texture. Par contre, je ne pense pas que ça soit implémenté dans QW.

Du coup le LOD n’explique rien 😉 (LOD = 2 fois plus de mémoire consommée)
Et le problème est même plus conséquent que ça … Selon Gamedev.no, la MegaTexture de Doom3 (si elle pouvait monter en 32k x 32k) est en fait composée de 131072 textures (256*256*2, "chunks" issus du découpage de la grosse texture originale). Une carte vidéo correcte n’a que 8 TMU. Il fait comment le fragment shader ? Il faut faire 16000 passes par frame pour rendre le terrain ? 🙂
Ingame, on se rend bien compte que le rendering se fait par chunks puisqu’on les voit changer de mipmap par carrés.
16000 passes, au pire des cas en fait 😀
Mais ça reste bien mystérieux tout ça 🙂
Je mettrais à jour l’article quand une démo de QW (ou une beta publique, sait-on jamais) sortira le bout de son nez 🙂

Répondre à handsome Annuler la réponse

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *