Ordo Ad Chao

Franchement rien a voir désolé sébult, sans les comments ça perd tout intéret.

Oui, là on a juste des gros plans sur la modélisation :(

En gros c’est du sparse virtual texture appliqué aux voxel non?

J’avais pas mal discuté avec Jon Olick à propos de cette techno ( mais sous mon vrai nom plutôt que sous ce pseudo).

Ce thread est une mine d’or aux niveaux des informations sur les SVO. Ajoutés aux slides de la SIGGRAPH disponibles ici, les détails internes du fonctionnement de la techno sont devenus assez publics. Je vais donc plutôt parler de ce que permet de faire cette techno, plutôt que de comment ça marche en interne.

Les SVOs sont une technologie assez particulière, avec certains avantages énormes, mais certaines contraintes les rendants complètement inapproprié à d’autres cas.

Pour aller des plus gros avantages jusqu’aux pires défauts :

- Framerate indépendant de la complexité de la scène. C’est un point assez hallucinant, mais le concept même du SVO est de pouvoir "puiser" dans la scène sans jamais dépasser un crédit alloué de framerate. Ca signifie que les artistes peuvent se faire autant plaisir qu’ils veulent, ils n’affecteront pas le framerate.

- C’est la technique de rendu la plus artist-friendly qui existe. Pour un artiste, il suffit de modeler sous ZBrush, et le résultat est utilisable en tant que tel sous la forme d’un SVO. Pas besoin de transformer le modèle en polygones, pas besoin de normals maps ou displacement maps, pas besoin de level-of-detail. Vous modelez, le SVO se charge de tout le reste.

- Cette technique résouds d’une façon élégante les deux problème du texturing unique et de la géométrie unique. C’est devenu une seconde nature pour les joueurs que de voir des textures qui se répètent ou des modèles 3D dupliqués, et c’est un défaut que tentent de résoudre id Tech 5 ( Rage) et id Tech 6 ( utilisant les SVO). On va bien voir.

- Selon Olick, cette technique permet d’afficher 20 fois plus de détails qu’avec des triangles, sur même technologie ( notamment GTX 280 et plus).

Passons dans les défauts.

- Les SVO sont totalement statiques, et toute tentative de les rendre dynamique est ingérable ( j’ai fait parti des gens qui ont perdus des heures à essayer). Sur id Tech 6 prévu pour 2012 et qui utilisera les SVO, Olick va carrément intégrer l’éclairage dans le SVO : pas de texture diffuse d’un coté et de light map de l’autre, mais juste une seule couleur par pixel ( voxel plus précisément ), cette couleur étant le résultat de la texture originale avec un éclairage précalculée. Pour les personnages et objects dynamiques, Olick utilisera des modèles 3D normaux et les techniques de rasterization classiques.

- Les SVOs consomment *énormément* de place. Il est dur de sortir des affirmations exactes car Olick n’a pas encore définitivement arrêté ses décisions sur le problème de la compression, mais on parle de jeux complets de l’ordre de 300 ou 500 Go. Autant les artistes n’influent pas le framerate, par contre leur travail influe très fortement sur le poids du SVO correspondants. Toute l’idée du SVO étant de pouvoir streamer sans ratages depuis le disque dur jusque la RAM puis la VRAM.

- Enfin, la qualité d’un SVO dépends de sa "taille physique" : il y a un rapport direct entre la précision à l’échelle voxel et la surface couverte pas le SVO. Autant sur un SVO de l’échelle d’un personnage, le résultat est extrèmement précis, on ne sait pas, si on faisait tenir une ville à la GTA dans un SVO, jusqu’à quel niveau de détail on peut descendre sans faire exploser son disque dur 3 fois. Ce problème peut d’autant plus être mitigé par l’ajout de niveaux de détails procéduraux, sur lesquelles taffent Olick en ce moment. Ce point est donc une grosse inconnu.

Les espèces de cubes bizarres qu’il affiche à un moment, ce sont les niveaux de détails de l’octree. Sans rentrer dans les détails techniques, l’aspect clé des SVOs par rapports aux polygones est qu’ils sont intrinsèquement une structure supportant le LOD : il est possible de packer 8 voxels et d’en faire la moyenne pour en obtenir un plus gros, ce qui n’a aucun sens mathématique avec des polygones. Du coup il est possible de streamer sur le disque uniquement les voxels d’une qualité utile. Le nombre de voxels affichés à l’écran étant du coup constant, le framerate constant provient de là.

De mon analyse, c’est l’évolution parfaite pour des engines à la Source, qui ne se focalisent pas sur l’intéractivité totale du décor. Dans ces conditions, on gagne 20 fois plus de détails à l’écran et un framerate constant quel que soit ce que fait l’artiste.

Cependant, l’aspect statique du bouzin ne permet de l’appliquer à *rien* d’autre. J’ai beaucoup gueulé contre Olick à propos de ça ( j’ai notamment sorti "entre id Tech 3 (Q3) et id Tech 6, il n’y aucun nouveau gameplay possible 10 ans après, est-ce vraiment de la next-gen selon vous ?"), mais bon, je suppose que c’est normal que mes reproches ne puisse pas convaincre id Software de larguer 2 ans de R&D dans le vent.

Voila, j’espère que c’était à peu près compréhensible. Les SVOs c’est donc une technologie avec des points forts très forts et des points faibles très faibles.

Un petit rêve que j’ai, ce serait d’utiliser des techniques de captures 3D du monde réel ( Divide tu m’entends ?), et d’utiliser le résultat directement comme un SVO. Ca remplirait toutes les conditions des SVOs ( statique, éclairage embarqué dans les données…), et pour la première fois, on pourrait jouer dans un niveau totalement réel plutôt que modélisé. Si on m’offre ça, j’accepte la staticité des maps de bon coeur :)

D’un autre côté même si ce n’est utilisable que pour les objets statiques, vu le gain de performances, ca va directement influencer la liberté au niveau des modeles dynamiques (en polygones, classiques)… Ca serait tout de même super ! Enfin, surtout pour les jeux qui ne jouent pas trop sur les environnements destructibles et sur la physique, ca laisse tout de même beaucop de libertés…

@Sebultura : merci pour le moment de gloire :)

@Iggy : c’est totalement envisageable, bien entendu, je l’ai précisé au milieu de mon pavé. Ca se rapproche donc d’un Source Engine aux amphèts : niveau de détail jamais vu, framerate constant, mais maps statiques et globalement assez peu d’objets dynamiques.

@ng-aniki : l’aspect ironique, c’est que le framerate constant, ça marche dans les deux sens… Un SVO même avec peu de détails ne va pas donner plus de framerate aux personnages. La seule chose qui peut rendre un affichage d’SVO moins gourmand, c’est baisser la résolution. Par contre ce que tu dit devient vrai par rapport au hardware : à chaque fois que la puissance brute augmente, et que l’on garde la même résolution, c’est une puissance qui est inutile au SVO et qui dont peut être utilisée pour les persos. Cependant, si on a trop d’objets dynamiques dans la scène, l’intérêt des SVOs et d’avoir un éclairage précalculé pour le décor devient très discutable… Donc il serait peut être plus judicieux d’augmenter le niveau de détail des personnages existants plutôt que d’en rajouter de nouveaux. M’enfin tout ça est très hypothétique pour l’instant.

je comprend pas ce que tu veux dire par "Les SVO sont totalement statiques, et toute tentative de les rendre dynamique est ingérable" : tu veux dire "non deformables" ? ou encore "il ne peut y avoir deux objets en SVO (ou plus) qui bougent indépendement l’un de l’autre (genre deux aiguilles d’une horloge)" ? parceque le gars il fait bien bouger le model en SVO dans la vidéo (forcement tu me dira vu que c’est un moteur 3d, mais bon je dis ca pour souligner mon incompréhension face à "Les SVO sont totalement statiques")
ou alors ca a à voir avec la lumière ? pas de lumière dynamique sur un objet en SVO ? donc surtout utilisable pour des objets statiques genre décors (enfin sauf dans un environement avec un éclairage global dynamique genre le soleil dans far cry 2)

L’image que tu montre me fait penser à la manière dont se découpent les bsp dans Unreal…
Le procédé n’est pas nouveau certes, ce qui l’est c’est la puissance des machines qui remet en question les méthodes d’affichages en temps réel.
Ce qui est intéressant, je trouves, c’est la diversités des solutions qui se dessinent actuellement, qui proposent toutes des features très intéressantes graphiquement mais qui s’adaptent pas forcément à tous les styles de gameplay.
Entre celui-ci et les systèmes qui calculent complètement la lumière en temps réelle (sans avoir à faker les rebonds de lumières) on sent que les techniques vont vraiment devoir êtres réfléchies amont selon le gameplay…
Merci pour le condensé Darkstryder.

Il craque un peu, l’Id Tech 4 (D3 non ?) a permis un nouveau gameplay, basé justement sur le graphisme, c’est à dire les ombres ! Avant ça n’existait pas, ou pas à ce point. L’Id Tech 5 nous a apporté un monde ouvert (qu’on a pu voir, un peu, avec l’Id Tech 4++) et l’Id Tech 6 va… bah on sait pas, eux même ne le savent pas !

Oui enfin ca fait depuis un moment qu’ils ne sont plus leader du moteur graphique temps réel. Meme l’unreal engine ecrase leurs moteurs en terme de portabilité (l’un des points mis en avant pour l’id tech 4).

@Holi : oui, c’est la meme technique à la base des bsp

@Darkstryder : Je n’ai pas dis que c’était nul parce que vieux.
Et SURTOUT ca ne propose pas des perfs supérieures aux polys, étant donné que l’usage est bien trop limité pour s’y substituer ou meme s’y comparer.
Ca ne va pas révolutionner le mode de la 3D temps réel : la méthode est archi connue, rodée, on connait ses limites, je vois meme pas l’interet de l’appliquer en temps réel (des super décors sans moteur physique/lumiere dynamique derriere ? Alors qu’on va vers environnements hautement descructibles dans tout les jeux ?).
Gain de temps de calcul ? Peut etre, mais VS temps de chargement et place de stockage (oui parce que là pour des décors, ca peut devenir simplement instockable).
Plus beau décors ? Encore une fois, il faut une place de malade pour autoriser le joueur à s’approcher tres pret d’une brickmap. Et quid des ombres portées des persos dessus ?

On pourrait peut etre les deplacer spatiallement (mais bonjour le process derriere), mais les deformer, c’est carrement inimaginable.

Encore une fois, l’analogie avec des briques legos est tres bonne. Tu as des duplos (http://courses.marshall.edu/~hamilton/public/DuploWeek/07280005b.jpg les enormes blocs pour bébés), et des legos normaux. Mais carrés. De 6×6 à 1×1 disont.

Tu vas utiliser les duplos pour remplir l’espace là où c’est peu detaillé ( /!\ faut prendre en compte la texture /!\), et mettre des briques de plus en plus petites dans les details.
(c’est automatique t’inquiètes, et généré à partir d’un nuage de points uniformes)

Donc :
- Tu n’as pas droit de faire de belles diagonales. Pour cheater, tu fais des escaliers avec les briques les plus petites possibles (et c’est réellement comme ça que ça se passe, avec une interpolation derriere quand meme).
- Les briques sont collées. Tu peux plus les bouger.
- De loin ca peut donner quelque chose de tres detaillé

Mais de pres, tu vois toutes les briques et les effets d’escalier. Si tu veux reduire l’effet, faut faire avec des briques plus petites, il en faut plus, et ca prend plus de place.
- Tes legos, ils marchent pas bien avec tes playmobils (comprendre : les polys et les brickmaps vivent chacune de leur coté, tu vas jamais pouvoir calculer une ombre portée avec des polys sur les legos ou vice versa)

Si on pouvait deformer dynamiquement les brickmaps ca serait génial. Mais déjà il faudrait repenser tout les softs 3d pour gérer ça, et faudrait inventer une nouvelle technique similaire mais completement differente, parce que la base des brickmaps ne permettra JAMAIS ca.

Et étant donné que c’est impossible de générer une brickmap directement à partir de polys (faut passer par un nuage de point), meme un soft comme zbrush ne pourra jamais fonctionner avec ça pour l’affichage : la création serait trèèèèèèès loin d’etre temps réel :)

Oui

Je retire 2 choses que j’ai dites : on peut les utiliser avec des shadows maps ET on peut les translater/scaler/rotater (j’avais tenté ca avait pas marché, mais là on dirait que oui)

MAIS la rotation se passe mal.

Donc si on réalisait un jeu video (par exemple un FPS) avec cette techno là pour des personnages, ceux ci auraient un aspect de lego au fur et à mesure qu’on se rapproche d’eux?

Parce que là pour la taille de fichier pour le personnage, en gros plan ce n’est clairement pas joli à voir.
x_X

Cela rappelle le premier DOOM dans le principe, où plus la caméra joueur se rapprochait de l’ennemi ou du décor, plus celui ci était pixellisé. De mon point de vue. ce serait clairement un régression si le but principal est de faire un jeu lourd en affichant des super graphs qui -en réalité- n’en sont pas.

Au niveau de l’animation, ça m’a l’air sacrément merdique. Comment est ce que l’on peut faire pour déformer le mesh correctement ?

Ben tu peux le voir dans la video youtube d’ailleurs : quand il se rapproche, ca commence à pixeliser.

Dans mon exemple rapide, le resultat n’est pas interpolé donc pas au maximum de la qualité pour la taille de la brickmap.
Mais effectivement, je le redis, ca prend une place enorme sur le disque dur.
Comme c’est des octrees, en mémoire ca prend rien, ca gère en plus le mipmapping, et il n’est pas obligé de lire tout le fichier d’un coup. Mais oui, ca prend une place gigantesque.

C’est effectivement un sprite 3D. Pour un element, tu peux te permettre de faire du tres highrez (200-300 mb jusqu’à 1 go pour le genre de perso de la video s’il était texturé - Ben oui, chaque couche de texture prend de la place, de plus en plus que le mesh est defini), un décor complet auquel le perso peut se cogner, avec texture, map de spec/refl, j’imagine mal. Le decor seul prendrait un bluray double couche (et je parle d’une map genre hl2, pas de crysis). Maintenant ils ont peut etre integré un systeme de compression qui m’est inconnu où une autre façon de gérer les textures…

On peut pas deformer. Je suis déjà surpris qu’il prenne le scale correctement (au detriment de la qualité - c’est pas comme quand tu scales un mesh, c’est plus comme quand tu scales une image 2d).
Ca voudrait dire mettre des matrices de transformation sur chaque point du fichier, ce qui va à l’encontre du système d’octree (déjà parce qu’il devrait lire TOUT le fichier pour calculer un point).

En precalculé, on utilise ça pour stocker des données lourdes (des infos volumetriques, particules, densités,.. par exemple) ou comme un bake3d ultra-leger en mémoire et en mise en place. pour calculer de l’irradiance ou de l’occlusion, ou des données de subscattering aussi. Quasiment jamais comme geometrie 3d.

Et pour ça, je vois tres bien l’usage pour du temps réel : baker les maps d’irradiance en brickmap doit etre particulierement efficace.

Pas vraiment pareil mais la voie avait déjà été explorée à l’epoque :) (voxel mais sans octree ni mipmapping)

@WOLFREIM : oublie l’idée d’appliquer ça sur des persos. Son exemple est mal choisi. Ce sur quoi il a souhaité mettre l’emphase, c’est le coté "ZBrush ready to go" : alors que d’habitude tu as un énorme travail annexe à faire ( création d’un hiugh poly et d’un low poly, génération de normal map et displacement map en tant que différence entre les deux, différents LODs selon la distance à laquelle est vue le personnage…) ici tu modélises aussi détaillé que tu veux, tout ces trucs sont pris en charges par le SVO.

@Ze Pilot :
Les SVOs ne sont pas une méthode d’affichage révolutionnaire, non. Par contre ils révolutionnent totalement la pipeline de création d’un jeu : boulot divisé par deux pour les artistes, framerate non dépendant de la complexité de ce qu’ils ont fait.
Rien que pour tout ça, c’est une méthode qui vaut le coup d’oeil. Comme disait Olick " quand on est Epic ou id et qu’on a assez d’argent pour ouvrir sa propre banque, ce serait stupide de ne pas au minimum explorer cette solution".

De plus, personne n’a réellement vu tourner id Tech numéro 5, mais le crédo de ce moteur, c’est de pouvoir faire tourner les mêmes assets sur les 3 plateformes sans travail aucun. Si c’est bien le cas, même l’UE3 ne sait pas faire ça. ( je t’accorde par contre que l’id Tech 4 est une catastrophe en multiplateforme).

Ensuite oui, comparer les SVOs et les brickmaps ont la même théorie sous jacente, mais une fois dans un cadre d’ingénierie, ça n’a plus rien à voir. Lis les slides de SIGGRAPH ( sans oublier le commentaire des slides, important) que j’ai posté dans mon premier commentaire, tu verras que c’est tout de même assez complexe et assez étudié.

Il y a par exemple toute une étude sur l’évolution de l’espace disque, qui lui permet de penser que le problème de l’espace disque devrait être résolu d’ici là. Celui des temps de chargement est un faux problème, car tu peux streamer très rapidement la plus basse qualité, et préciser ta scène au fur et à mesure.
Il y a une autre étude ou il affirme que à niveau de détail égal, les SVOs compressent *mieux* que les triangles et sont plus rapides à afficher. En gros parce que les triangles perdent tous leurs intérêts une fois qu’ils sont passés en dessous de la taille d’un pixel. Mais lis, les explications de première mains valent mieux que les miennes.

Le fait que tous les jeux migrent vers des environnements destructibles, c’est malheureusement pas si vrai. Il y a définitivement de l’espace pour un gameplay sans, ça c’est sûr. La question, c’est de savoir si ce n’est pas trop se fermer le marché que de ne pas pouvoir dynamiser ses scènes.

@Divide : aussitôt que le SSDM gère le displacement provenant de pixel hors champs ou occultés :o)

En conclusion, l’argument des SVO, c’est que la tesselation + displacement, le per pixel displacement mapping, tout ça c’est une catastrophe à gérer pour les artistes qui doivent multiplier le taff qu’ils ont à faire sur chaque modèle.
Un modèle qui tessèle bien est vraiment hyper difficile à faire correctement, c’est d’ailleurs pour ça que jusqu’ici c’est une technologie qui n’émerge pas, le jeu n’en vaut définitivement pas la chandelle en matière de qualité / investissement.

Les SVOs prennent toute cette classe de problème, et les suppriment complètement. Tu modélises sous ZBrush, tu peints, tu exportes dans ton SVO, pouf, c’est utilisable.

Le tout pour des perfs à peu près équivalentes à du rendering classique. C’est en ça que je trouve que cette techno vaut le coup d’oeil.

ce n’est pas obligé de pixeliser les voxels mais ça coûterait plus cher en calcul..

Moteur de terrain par voxel avec bilinear filtering

@Darkstryder,
je remettais juste en question que tu déboules sur un forum sans savoir quoi que ce soit de ce que fait id et tu leur fais des leçons (sur un jeu que tu n’as pas vu ?) genre "oh les gars". Ça va bien dans ta tête ? Aux dernières nouvelles la présentation voxel octree était basé sur une expérimentation technique de Jon Olick et pas une présentation de id tech6 ni de leur prochain jeu.
La seule techno dont on est sûr et qui a été montré c’est id tech 5 qui est basé sur une version généralisée de mégatexture (donc textures uniques partout pas uniquement sur le terrain) et qui sera utilisé dans Rage notamment. Là tu peux critiquer à la rigueur ..si tu as joué au jeu..

En gros, l’idée c’est de la compression adaptative, qui du coup permet des modèles beaucoup plus détaillé.

Actuellement les textures dans la carte 3D/GPU ne sont pas compressé en fonction du niveau de détail de la texture et ce niveau de détail n’est pas adaptatif en fonction du volume affiché,.

Aujourd’hui, une texture énorme entièrement verte, qui compressé en png/jpg sur le disque prend 4ko, dans le GPU prendra une taille énorme (au mieux divisé par 4 ou 8 en utilisant une compression par bloc, mais la résolution en pixel de la texture sera toujours linéare avec la taille en mémoire dans le GPU))

Sauf intervention de l’artiste, si un personnage est tout blanc sauf sur un bout de doigt avec un tatouage super détaillé, actuellement la texture a forcement la taille du niveau de détail imposé le tatouage sur toute sa surface… on se retrouve avec un texture toute blanche énorme, avec un petit coin rempli par le tatouage !

Aujourd’hui, l’artiste intervient, soit avec un approche multipasse (une texture blanche + une texture ‘tatouage’ comme un ‘decal’), soit en bidouillant les coordonnées UV (long, fastidieux, pas vraiment LOD-friendly) le tout avec des méthodes qui dépendent fortement du moteur 3D, des shaders, etc.

L’idée du remplaçant de l’uv mapping est que le système doit automatiquement trouver un moyen pour que les informations de texture soit adapté, ici un pixel blanc + le tatouage en haute rés, avec en plus un moyen d’eviter d’afficher/charger le tatouage en full def si on est trop loin du perso.

Il s’agit de trouver le moyen de quantifer/qualifier automatiquement le niveau de détail (Level of detail / LOD) par voxel (et non pas juste par pixel comme on le ferait en 2D) et que cette quantité se reflète dans la taille de la texture (que ce soit une texture de displacement (normal mapping et autre) ou de colorisation) .

C’est le hot-topic sont en jeu dans le Dev 3D pour augmenter le niveau de détail, en adaptant la "compression", Il s’agit tout simplement de remettre pratiquement toutes en cause le bon vieux "UV mapping". Depuis 2003, Il y eu le tiletree texture mapping, octree texture mapping, perfect spatial hashing texture, le pyramidal-toroïdal fractal mapping, etc.

Donc tous ces nouveau modèles de projection de texture propose des textures d’indirection, un peu comme des palettes (cf gif) en utilisant des structures de décomposition de l’espace de projection de la texture (tiletree, octree, etc…)

Le problème c’est que cette palette est lente à construire/mettre à jour… d’ou le coté statique.
Pas facile d’y coller une texture calculé dynamiquement à chaque, comme une texture d’ombre dynamique…
Pour l’animation, vu que la projection stocké dans la texture d’indirection est fonction d’un découpage de l’espace (ici octree), c’est pas simple à mettre à jour/transformer.

Sans parler du cout à l’affichage, pour afficher un pixel, doit parcourir la texture d’indirection selon un algo plus ou moins complexe, qui aujourd’hui font qu’aucune de ces techniques n’est généralisable pour des scènes vraiment complexes (Au contraire, dans les jeux les scènes sont de plus en plus ouvertes…)

@crashy : Cette même idée d’indirection de texture est déjà utilisé pour le ‘megatexture’ / ’sparse virtual texture’ mais de façon plus simpliste, sans réelle prise en compte de LOD par voxel, donc sans projection (pas d’octree/tiletree,etc.) c’est fait à la louche (genre copy de texture par gros blocs, comme dans le ‘clipmapping’), et comme c’est ’simpliste’ on peut même le faire en temps réel. Le mieux est de voir le papier posté "Unified Texture Management for Arbitrary Mesh"), qui mets de facon totalement dynamique toutes les textures de la scène dans une seule grosse texture (sorte de "megatexture" dynamique).

@ par un Anonyme
Mardi 18 novembre 2008 à 18 h 16

Non t’es à l’ouest. Un sprite de doom c’est une texture non apposée sur un polygone, si on veut. Et ce qui empeche qu’une texture apposée sur un poly soit pixellisée, on applique un lissage, bilinéaire, trilinéaire etc. Tu prends crysis, tu vire le lissage : c’est pixellisé.