Come get some !

Un nouveau blog sur Wefrag le blog de Jerc.

Rage ou pourquoi le Virtual Texturing à outrance c’est mal

Il y a quelques années, Carmack annonçait en grande pompe sa dernière trouvaille, le “MegaTexturing”, promettant une liberté totale pour les artistes et une résolution de texture quasi infinie…
Aujourd’hui Rage est sorti et on ne peut que constater que les promesses de l’époque étaient bien loin de la réalité.

Commençons par l’aspect authoring. En effet pour les artistes travaillant sur le jeu, le fait de s’affranchir de toute contrainte technique et de toute réflexion sur l’optimisation du mapping (réutilisation et superposition d’UV, textures à usage multiple, etc.) a pu être très agréable et libérateur d’un coté mais j’ose espérer qu’aucun débutant de ne faisait partie de l’équipe sous peine de devoir tout réapprendre le jour ou il se retrouvera dans un studio favorisant une approche “intelligente” du texturing, à la Deus Ex 3 par exemple.

Un exemple d'abus de la technologie, ces 3 silos sont uniques et pèsent donc 3 fois plus lourd en mémoire vidéo

Ensuite, l’aspect visuel du résultat montre les faiblesses d’un tel système. Les environnements sont superbes en effet, mais id software étant allé jusqu’au bout de leur idée, la moindre cannette, le moindre carton, le moindre détritus sur le sol est unique.
C’est un gâchis de mémoire vidéo monstrueux qui se paye lorsqu’on regarde de près les éléments uniques qui forment ce décor global somptueux. La résolution de ces petits éléments qui sont répétés des centaines de fois dans la map et qui, dans le cadre d’un pipeline classique auraient été de simple decals ou prefabs instanciés, est ici extrêmement faible, souvent réduits a un amas de texels informe.

Ce qui aurait du être un decal d'une résolution correcte et maintenant une bouillie de pixels.

Un autre problème posé par ce système est le packing de toutes ces textures qui semble mal fonctionner. Certains objets se verront allouer un espace texture trop important et d’autres au contraire se retrouveront avec des textures digne de la Wii sans logique apparente. Ainsi on se retrouve avec des textures juxtaposées ayant un texel ratio passant de 1 a 10, il n’y a rien de pire pour casser l’immersion du joueur et provoquer un “rhaa quelle texture dégueulasse”.

Aïe mes yeux le texel ratio !

Dernier problème, quand la mémoire vidéo est pleine, elle est pleine. Lorsqu’on visualise un environnement très ouvert, on arrive rapidement à saturation, le moteur ne sachant plus trop comment afficher toutes ces textures uniques, et on va assister a du flush sauvage de textures en arrière plan parce-que un nouvel objet vient d’apparaitre au premier plan.

Les texture d'arrière plan disparaissent si je baisse un peu le regard.

Bref, je suis convaincu que l’utilisation du virtual texturing sur les environnements et notamment les terrains en extérieur est un atout visuel majeur.

Je pense cependant que son utilisation ne doit pas forcément être globale mais plutôt passer par une cohabitation entre cette technologie et des méthodes plus traditionnelles, notamment pour les props et decals qui n’ont tout simplement PAS BESOIN d’être unique.

32 commentaires pour “Rage ou pourquoi le Virtual Texturing à outrance c’est mal”

  1. Blade_Runner dit :

    Les deux silos de la première images ont l’air d’être identiques, en plus.

  2. Thermostat dit :

    C’est surtout une perte de temps incroyable niveau texturing. Personne ne regarde deux rochers à 10m de distance, s’ils sont parfaitement identiques, ca ne choquera personne, même dans une image fixe.

  3. sw1tch dit :

    Ne le dites à personne, mais en voyant le premier screen je me suis demandé de quel niveau de Borderland ça pouvait sortir…

  4. drloser dit :

    A part ça, c’est le FPS le plus beau et le plus fluide jamais sorti sur console.

  5. Jerc dit :

    On est d’accord, j’expose simplement les défauts et limites de la techno utilisée. Mais au final je trouve le jeu très joli dans son ensemble.

  6. ezechiel dit :

    Une question qui n’a presque rien à voir avec le sujet :

    J’ai le choix entre Rage Pc (mais je ne suis pas sur d’y jouer de façon confortable) et Rage 360 (sachant qu’un pad ne me dérange pas trop). Tu as un avis sur la question ?

  7. drytaffin dit :

    L’article est intéressant par contre je le trouve un peu trop court et pas assez technique. Peut être qu’il n’y a rien d’autre à savoir mais je reste un peu sur ma faim (ce qui est un compliment, d’un sens).
    Ce qui me choque dans les screen c’est que c’est très inégal, c’est du décors de “vidéo”, ils ne faut pas trop que la caméra s’attarde et tout parait sublime.
    Et c’est clair que les rendus de paysages sont sublimes.

  8. divide dit :

    En même temps les paysages de Rage, c’est comme les skybox de Doom: c’est beau, mais tu peux pas test.

  9. Ze_PilOt dit :

    Blade_Runner a dit :
    Les deux silos de la première images ont l’air d’être identiques, en plus.

    Ce n’est pas parce que le jeu ne gère que des textures uniques que le mec qui les peint va en sortir une nouvelle à chaque fois. C’est ça qui est débile dans son moteur, il retire une contraire technique qui existe toujours comme contraire temporelle et humaine.

  10. Lork dit :

    Ze_PilOt a dit :

    Ce n’est pas parce que le jeu ne gère que des textures uniques que le mec qui les peint va en sortir une nouvelle à chaque fois.

    Ah d’accord donc autant ne pas du tout en avoir la possibilité. Quel drôle de raisonnement.

    Edit avec tentative de recuperation du commentaire perdu en résumé:

    “Je ne comprends pas la notion de contrainte humaine. Si un humain est trop fainéant pour faire 2 textures différences ce n’est pas à Carmack de limiter les possibilités de son moteur”.

  11. Lork dit :

    doublon.

  12. Ze_PilOt dit :

    Fainéantise ? Tu imagines le boulot que ce serait de faire réellement une texture unique pour chaque boulon du jeu ?
    A un moment, tu as un budget, du temps et un certain nombre de personnes sur ton projet. Tu ne peux pas te permettre de passer 3 mois à texturer différemment chaque bout de papier qui traine sur le sol.

    Je ne vois pas en quoi le raisonnement est bizarre : Si tu as la capacité de faire deux textures différentes pour le même objet, t’as pas besoin de l’id tech 5 pour les afficher. N’importe quel moteur en serait capable.
    Bref, les “autres” moteurs de jeu t’en laisse la possibilité.

    L’inverse n’est pas vrai : Ce n’est pas parce que tu n’as que des textures uniques dans le jeu que chaque texture le sera.

  13. Lork dit :

    Humfr désolé j’ai niqué mon commentaire avec mon net erratique, je tente de le remettre pour que le tien reste logique.

    Rage a bénéficié d’énormément de temps meme pour un jeu AAA.

  14. divide dit :

    Je trouve la texture des 2 silos assez symptomatique: c’est la même chose à 95%, mais l’artiste a changé 2-3 détails histoire de dire “ouai bon il fait chier John, voila la texture est uniquement maintenant, on pourra pas dire que le megatexture sert à rien”.

  15. Nooky dit :

    Le plus embêtant c’est qu’a trop se focaliser la dessus, ils ont oublié que le level design c’est pas seulement une tonne de détails et un style graphique, c’est aussi l’interaction avec le décors, le dénivelé, la destruction, le placement des objets, la physique. Franchement les niveaux de Rage sont plutôt minable à ce niveau. Même jackal’s canyon qui est le niveau le plus beau, en terme de structure ça reste extrêmement limité.

    Au final le moteur sert les graphismes, mais pas du tout le gameplay et encore, il ne le fait pas parfaitement.

  16. epsylon dit :

    C’est quoi la méthode “Deus Ex” de gestion des textures ? (Source ?)

  17. LeGreg dit :

    Il y a beaucoup de challenges (notamment sur PC où la latence est super variable et les APIs ne sont pas vraiment adaptées) mais je n’irais probablement pas jusqu’à dire que le virtual texturing c’est le mal. Le monde du rendu temps réel est suffisamment complexe pour qu’il puisse y avoir plusieurs approches.

  18. Jerc dit :

    @espylon

    Ils font des textures multi-usage dont ils vont réutiliser des petits éléments sur de nombreux meshes et urfaces en changeant leur taille, leur placement etc. Utiliser beaucoup de petits decals pour rajouter des détails a des textures génériques, etc.
    La source est interne a Eidos mais je n’ai malheurseusement pas d’exemple concret à te montrer.

  19. skaven dit :

    Un artiste sur polycount qui a fait 1 superbe envirronement avec UNE texture 256×512…

    A titre d’info, une texture de cette taille, compressée en DXT doit faire environ 128Ko.

  20. Ttask dit :

    Jerc a dit :
    @espylon
    Ils font des textures multi-usage dont ils vont réutiliser des petits éléments sur de nombreux meshes et urfaces en changeant leur taille, leur placement etc. Utiliser beaucoup de petits decals pour rajouter des détails a des textures génériques, etc.

    C’est une technique hyper standard ça, pratiquement tous les studios font ça pour ajouter de la diversité visuelle.

    Sinon comme le dit Nooky, c’est très joli, mais dans Rage c’est au détriment de l’interactivité. C’est un cas d’école des graphismes qui viennent entraver le gameplay. Sur PC, je pense que la latence vient plus des APIs utilisées (on ne contrôle pas directement le command buffer du GPU dans DX ou OpenGL, il peut y avoir de fortes latences) que de la bande passante, et c’est pourquoi je pense qu’il peut être viable d’utiliser cette technique sans forcément tout baker dans la diffuse (et ainsi permettre de rajouter de l’intéractivité sans avoir les ombres style PS2). Après, c’est vrai qu’en dehors du terrain, cette technique ne facilite pas nécessairement la production pour les artistes. Raisonner avec des décals est extrêmement intuitif conceptuellement pour apporter de la diversité, et c’est beauciup plus robuste.

  21. Jerc dit :

    Pas si standard que ça en fait, c’est du best practice on est d’accord mais je vois défiler les assets de beaucoup de studios au taff et j’hallucine vraiment sur le manque de réflexion et d’optimisation de beaucoup d’entre eux (surtout chez les studios asiatiques à vrai dire).

    Et de la modularité poussée à l’extrême, comme dans l’exemple de Skaven, je suis pas sur que tant de studios se lancent dedans, c’est pourtant vachement gratifiant et efficace, même si ça demande un poil plus d’effort d’ingéniosité.

  22. __MaX__ dit :

    Ca m’étonne pas que les studios asiatiques n’optimisent pas, vu a la vitesse à laquelle les jeux sortent là bas. Et même dans d’autres pays, c’est comme dans toutes les boites : les process et l’optimisation des techniques de travail, “on le fera quand on aura le temps”…majoritairement, ce temps n’arrive jamais.

    Je suppose que Bethesda a l’intention de garder le moteur en interne. Mais du coup, avec une techno pareille et le temps de travail que ça demande, c’est un moteur qui ne pourra de toute façon jamais voir le jour comme l’UDK ou le Cryengine qui eux permettent à n’importe qui de se plonger un peu dedans et de sortir direct un environnement potable sans avoir une équipe de graphistes et intégrateurs AAA.

  23. channie dit :

    Ca m’étonne pas que les studios asiatiques n’optimisent pas, vu a la vitesse à laquelle les jeux sortent là bas. Et même dans d’autres pays, c’est comme dans toutes les boites : les process et l’optimisation des techniques de travail, “on le fera quand on aura le temps”…majoritairement, ce temps n’arrive jamais.

    Les bons graphistes optimisent quand ils produisent, sinon les tech artists leur tombent sur la gueule dès que la version ne tourne plus au framerate désiré =)

  24. Plagman dit :

    Ce billet est quand meme franchement sensationnaliste. Le moteur te permet d’avoir plusieurs zones backées par la même page de mémoire texture. Ca veut dire que si l’artiste decide de réutiliser des assets il est libre de le faire, et l’éditeur est assez malin pour factoriser les parties des layers utilisées plusieurs fois quand tu utilises le système de stamps. Pour ton screenshot c’est le même silo et celui de droite a juste un stamp de rouille dans le layer detail, donc c’est juste un poil d’overhead en mémoire, pas une duplication complète.

    Niveau technologie c’est bien plus évolué que les paradigmes actuels et c’est incontestablement le futur. Pour l’authoring c’est le jour et la nuit et les techniques “intelligentes” que tu décris c’est justement fait pour avoir un peu le même workflow tant bien que mal.

    Comme toute nouvelle technologie, y’a un petit pas en arriere nivequ détail mais un grand pas en avant artistique et flexibilité. A la sortie de Quake tu aurais pu faire le même genre d’article expliquant que les modèles sont pas assez détaillés et stretchent leur textures comme des fous comparés aux super sprites 192×192 des boss de Doom.

  25. Ttask dit :

    channie a dit :

    Ca m’étonne pas que les studios asiatiques n’optimisent pas, vu a la vitesse à laquelle les jeux sortent là bas. Et même dans d’autres pays, c’est comme dans toutes les boites : les process et l’optimisation des techniques de travail, “on le fera quand on aura le temps”…majoritairement, ce temps n’arrive jamais.

    Les bons graphistes optimisent quand ils produisent, sinon les tech artists leur tombent sur la gueule dès que la version ne tourne plus au framerate désiré =)

    Exact, la plupart des “gros” moteurs ont plein d’outils de profiling des assets qui permettent de voir immédiatement quand il y a des abus: mips non utilisés, shaders trop lourds, etc. Ça devient heureusement de plus en plus difficile de faire n’importe quoi dans ces environnements, et tout peut se détecter très tôt.

    Plagman: je ne suis pas expert sur le virtual texturing dans Rage, mais ce que tu dis sur les stamps est intéressant: il me semblait avoir compris que dans ce cas particulier (Rage) absolument tout était baké dans une unique texture. Il y a déjà plusieurs layers donc (un pour la diffuse+light, un pour les decals, etc) ? Si c’est le cas, pourquoi ne pas avoir dissocié la diffuse de la lightmap, et ainsi éviter les ombres super cheap pour les dynamic meshes ? Uniquement pour des raisons de bande passante ?

  26. Plagman dit :

    Je suis pas sur de comment ca a evolue mais quand j’ai touche au moteur y’a 3 ans, je suis quasi sur qu’il y avait au moins 2 layers; c’etait concu pour pouvoir factoriser les pages memoire du layer diffus si besoin etait tout en ayant du detail unique sur un layer detail de moindre profondeur / plus compresse. Pour la lightmap c’est une decision reflechie de s’eloigner du dynamique; comme tu le dis les ombres dynamiques sont clairement secondaires. Un layer different pour la lightmap aurait permis d’unifier les ombres statiques et dynamiques pour le rendu final et d’avoir un resultat un peu moins moche, mais aurait coute beaucoup plus cher niveau memoire dans un environnement deja assez bottlenecke. Carmack nous avait clairement dit que tech4 etait trop avant-gardiste sur le dynamisme et que c’etait pas scalable et qu’il ne voulait plus mettre l’accent la dessus pour la prochaine mouture. On peut dire que c’est les deux bouts du spectre a ce niveau, tech4 et tech5.

  27. Jerc dit :

    Du coup ,comment le moteur peut il factoriser les textures identiques, chaque mesh ayant une lightmap propre si la lightmap est bakée dans le diffus ?

  28. Plagman dit :

    De toute facon meme si c’etait pas le cas, une page de texture c’est 128×128 ou 256×256. C’est vraiment pas la fin du monde niveau coarseness meme si t’as pas de bol et que ton stamp en overlap 2-4. L’approche virtuelle complete est saine niveau design. Les limitations de la version console viennent du manque de memoire mais c’est mitige par la facilite du streaming asynchrone vu que le soft controle la memoire directement. Les limitations de la version PC viennent du manque de flexibilite des deux grosses API graphiques niveau upload de texture (c’est encore adapte au vieux paradigme, mais on travaille sur des solutions) mais c’est mitige par la grosse memoire. Dans quelques annees les deux problemes seront regles et tout le monde virtualisera tout, c’est l’avenir.

    EDIT: je viens de verifier et tout est bake dans le meme layer actuellement, ce qui empeche en effet de factoriser les pages. Je suis quand meme convaincu de ce que j’ai dit plus haut; je crois a 100% en cette approche et je suis pret a parier que quand les deux aspects problematiques que j’ai decrit auront converge tout le monde se mettra a la sauce progressivement.

  29. divide dit :

    Je ne sais pas à quel point tu connais l’id Tech 4 mais j’ai l’impression que tu t’avance beaucoup quand même, le calcul de factorisation serait monstrueux si le moteur devait comparer/compresser chaque pattern de toute taille possible sur l’ensemble de toute la megatexture d’un niveau.
    D’autant que comme le souligne Jerc ce ne serait guère efficace avec le baking lumière.

    Niveau technologie c’est sur que le principe du megatexture est dans l’absolue une évolution, mais qui arrive beaucoup trop tot par rapport aux capacités de stockage actuelles: pour un jeu qui reponde aux critères graphiques de 2011 il faudrait des textures 4 fois plus détaillés, des environnements au moins 2 fois plus grand/ouvert, et au moins une couche de texture supplementaire pour les caracteristiques des materiaux (et sans baking lumière dans la couche diffuse donc).
    On se retrouverait avec un jeu qui prendrait plus de 300Go pour que le megatexture ne soit pas un bond en arrière par rapport à toutes les avancées technologiques de ces cinq dernières années.
    Et pour la comparaison avec l’évolution/regression de Quake, le gain du megatexture est beaucoup moins évident que l’apport de la full 3D, qui suffisait à compenser le léger recul de détail par rapport aux sprites.

  30. Plagman dit :

    Cf mon edit au dessus. En pratique je suis d’accord que cette mouture a quelques aspects pas optimaux, mais je pense quand meme que c’est l’approche a retenir.

    Un de mes gros problemes avec l’argumentation initiale c’etait l’argument “gachis de memoire video”. C’est un detail d’implementation et je pense que se bloquer la dessus releve de la mauvaise foi en tant qu’artiste, vu que tout est fait dans ce systeme pour que cet aspect ne te concerne absolument pas. D’ailleurs, la quantite de memoire video n’est pas du tout un probleme sur PC actuellement.

  31. Jerc dit :

    Justement, ça me dérangerait en tant que tech. artist de ne pas avoir le contrôle sur les ressources que j’utilise. Ça me ferait grandement chier d’utiliser 2 256*256 pour deux silos identiques alors qu’a cote la grosse vanne métallique va se retrouver avec un 64*64 ignoble.
    Après je ne crache pas sur la techno en elle même, cf. ma conclusion, je pense par contre qu’elle se doit d’être plus flexible que l’utilisation qui en est faite dans Rage.

  32. SethDeNod dit :

    divide a dit :
    On se retrouverait avec un jeu qui prendrait plus de 300Go pour que le megatexture ne soit pas un bond en arrière par rapport à toutes les avancées technologiques de ces cinq dernières années.

    Je pense que ça résume le problème, il me semble bien que quelqu’un de chez id avait expliqué que leur version (sans aucune compression) était de l’ordre non pas de la centaine de gigas mais carrément du téraoctet.

    Leur version était forcément plus détaillé (suffit de voir les screens communiqués vs les vrais screens c’est pas seulement photoshop) mais après faut bien que ça rentre sur un support commercial (DVD double couche, Blu-ray, ou Steam etc. Imaginez vous télécharger un To de données. Surtout pour ceux qui ont des quotas) ce qui donnerait le résultat “beau mais moche”.

Laisser un commentaire

Vous devez être connecté avec votre compte Wefrag pour publier un commentaire.