hello les geeks !
c’est tellement con que ça m’étonne que cette idée ne soit pas inclus dans tous les moteurs de jeu… d’ailleurs, si ca ne l’est pas, c’est qu’il doit y avoir anguille sous roche.
je me souviens que dnas les news parlant du jeu Messiah, on nous promettait un moteur de jeu supra performant qui permettrait d’avoir un jeu toujours fluide, réduisant (ou augmentant) le nombre de polygone des différents modèles suivant ce que la machine pouvait supporter…
j’avoue que l’idée d’un jeu fluide en toute circonstance n’est pas pour me déplaire et je ne pense pas être le seul.
bref, dans les jeux, à la place de gros ralentissments, on aurait un jeu légèrement dégradé de temps en temps…
Deja fait, plus souvent en fonction de la distance que de la puissance CPU, mais deja fait. Puis les algo de reduction de poly c’est pas les plus simples et donc ca pompe aussi du CPU de toute facon…
Y a des gens, qu’on fait des recherches, et qu’on essaye…
Unreal Tournament premier du nom proposais ce genre de tech (enfin c’etait de la degradation)…
Le problem c’est que c’est dur a controle (faut que le mesh reste joli), souvent laid, et sufisament cher en CPU pour que ca vaille pas vraiment le coup avec nos boulevard a poly courrant.
On s’apercois souvent que c’est l’eclairage (shader et compagnie) et le texturage qui font souvent le plus gros d’un ralentissement.
Et pis c’est de la tech pour jeux PC, et ca fait pas d’argent ca, mon bon mossieur
[quote name=‘GloP’ date=’ 14 Apr 2005, 23:12’]Deja fait, plus souvent en fonction de la distance que de la puissance CPU, mais deja fait.[right][post=“350506”]<{POST_SNAPBACK}>[/post][/right][/quote]Exemple : Gran Turismo 1, on voit clairement un changement de qualité lorsqu"on s’approche d’une voiture, par exemple en venant prendre l’aspiration en vue intérieure, les textures de la voiture concurrente sont remplacées soudainement.
[quote name=‹ c0unt0 › date=’ 14 Apr 2005, 22:13’]Et pis c’est de la tech pour jeux PC, et ca fait pas d’argent ca, mon bon mossieur
[right][post=« 350508 »]<{POST_SNAPBACK}>[/post][/right][/quote]
Boaf, ça peut se faire sur console aussi… mais c’est clair que de nos jours, le vrai problème c’est moins le nombre de poly que les shaders qu’on met dessus… actuellement c’est assez « facile » de sortir 1 million de poly par frame à un framerate a peu prés décent sur un gros PC, le plus dur c’est de faire en sorte que ton fillrate tienne la distance Si t’as 400 polys mais qu’ils prennent tout l’écran et que t’es limité en fillrate, ben t’es encore plus dans la merde que si t’as 1 million de poly qui prenne 1/4 de l’écran
Bref, rien n’est simple dans ce domaine, et en effet faire de la réduction de poly pour économiser du GPU coute du CPU… Après c’est un choix et un équilibrage propre à chaque moteur. Cela dit, F1 World Grand Prix & WarmUp, 2 jeux de F1 sur lesquels j’ai bossé, géraient des niveaux de détail pour les voitures, et avaient un mode « automatique » basé sur la puissance de la machine, la résolution, la distance, … et tout un tas d’autres trucs comme l’age du capitaine. Ca marchait pas si mal, on faisait le grand écart entre un P200 avec une Voodoo 1 et une PIII 600 et une Geforce 1 ou 2 à l’époque (eh oui, ça remonte maintenant).
Il y a quoi comme solutions pour mettre ce genre de technique a l oeuvre ?
je voie deux choses
1\ degradation statique: on definie des seuils de distance,framerate, et/ou autres est on switch les mesh les textures et les effets appliques dessus des qu on depasse le seuil. comme ce changement doit etre fait d un frame a l autre les deux doivent etre en memoire en meme temps, c est pas faisable de faire un acces disque a ce moment la.
Deux dans le cas ou on a seulement et low et un high. ca se complique quand on passe a N niveaux de details qui demandent d avoir 3 (ou deux si on est en limite low ou high) en memoire (un cran moins detaillé, actuel, un cran plus detaillé). ca revient cher en memoire.
2\ dynamique
a partir d un model extrapoler un model moins (ou plus) riche en polygones tout en gardant la forme d origine, sans provoquer des textures mal placees etc etc j imagine le procede plutot lourd, alors que le but c est de soulager cpu et gpu
on peut surement trouver des solutions mixtes (transition par palier du mesh mais degradation de la texture dynamique par exemple)
bref si quelqu un passe et a des connaissance en la matiere son point de vue est vraiment le bienvenu
Je parlais pour les solutions dynamique…
En ce qui concerne le “statique”, ou les nartistes creer plusieurs versions du meme mesh, oui ca se fait beaucoup cela dit…
Alors il ya aussi plusieurs techniques (qui sont meme déjà utilisée dans Quake 2, il me semble, Quake 3 c’est sur - jeter un oeil sur les static meshes, statues, etc… -):
dynamic LOD: c’est un truc qui calcule en temps réel, suivant l’éloignement d’un modèle les triangles qui souffriront le moins d’une réduction. En gros, on a 3 triangles, et suivant l’éloignement du sommet commun par rapport au plan formé par les 3 points extérieurs, on supprime ce point ou pas.
Et ceci on le fait récursivement. Souvent, pour économiser du CPU, précalcule le mesh a différents états (par exemple, l’état actuel -1 -2 -3 -4 triangles) quand on a du temps CPU dans les scènes légères pour décharger le CPU dans les scènes lourdes et pouvoir toujours rétrograder ‘en catastrophe’ le nombre de triangles.
Seul problème: le popping. On voit clairement des points qui disparaissent quand le mesh est Loddé. Pour cela, certains utilisent une technique de smooth lodding, qui au lieu de faire disparaitre immédiatement le point central, le fait confondre doucement (par déplacement du vertex) avec le point situé sur le plan formé par les 3 autre points extérieurs, ou avec un des sommets (dans ce cas la, il ne faut pas oublier de déplacer l’UV de la texture en conséquence) afin que cela ne choques pas l’oeil. Une fois que le point est confondu, on peut le supprimer sans problème.
Le Roaming: cette technique est utilisée surtout pour la gestion de terrains énormes, et était déjà utilisée en 1992 pour le jeu Frontier (suite de Elite). Le fonctionnement est approximativement le même.
Je me suis toujours demandé pourquoi, sur les cartes graphiques récentes, on utilisait pas un ultra low poly avec un displacement map? Les cartes directX 9 gèrent le displacement map, mais est ce que c’est plus effectif?
Ca permettrait d’avoir beaucoup de détails, sans pour autant sacrifier le framerate a cause du nombre de polygones…
Le LOD continu pour ce qui n’est pas procédural, à ma connaissance c’est pas gagné. Déjà c’est lourd en CPU, mais en plus concevoir un modèle pour lequel ce genre d’algo ne bousille pas les UV, c’est la joie.
Et puis comme déjà dit, le problème ce n’est plus le nombre de polygones. C’est les shaders (mais on peut limiter les dégâts en faisait du Z-prepass, vivent les buzzwords) et surtout le nombre de “primitive call”, en gros le nombre d’objets. Afficher 50 objets de 2000 polys c’est plus coûteux que 5 objets de 20000.
Ah oui, sans oublier tout ce qui est géométrie dynamique qui malmène le bus. Heureusement le skinning en hardware grâce aux vertex shaders aide pas mal là aussi.
edit : et pour répondre à pere[cil], le displacement mapping n’aide pas au niveau du nombre de polygones, la différence est qu’une partie des polygones est créée au niveau de la carte vidéo, et n’est donc pas transféré par le bus agp (principal bottleneck) et prend moins de mémoire aussi.
Les système de LOD dynamique ont tendance à demander du CPU, et aussi étonnant que ça puisse paraitre, sur PC beaucoup de jeux sont déjà limités par le CPU… Autrement dit, vouloir gagner du GPU en sacrifiant du CPU n’est qu’assez rarement un bon choix à l’heure actuelle. Du coup, la plupart des jeux se contentent de LOD statiques, avec ou sans fade in/out pour les faire apparaitre, et voila.
Pour ce qui est du displacement, il faut savoir qu’actuellement il y a peu de cartes qui peuvent sampler une texture au vertex, donc ça ne vaut pas le coup de se faire chier à développer un moteur qui gére ça pour un public aussi restreint. D’autre part l’interet (a mon avis) du displacement serait plutot de pouvoir modifier la topologie d’un objet en ne modifiant qu’une (relativement) petite texture. Ca permettrait par exemple de faire des dégats sur des objets sans avoir besoin de modifier “pour de vrai” l’objet, une simple mise à jour de texture (peut etre meme via un pixel shader directement, pourquoi pas), et le tour est joué.
Cela dit, tu peux attendre encore un moment a mon avis avant que ça ne soit démocratisé dans les jeux…
Juste pour dire, si tu veux faire ‘mumuse’ avec, Maya vient avec un plugin pour les progressive meshs, et tu peux les charger tel quels avec directX 9 (et peut etre avant, le 9 c’est le premier que j utilise vraiement). sur msdn
[quote name=‹ KiniK › date=’ 16 Apr 2005, 19:28’]Juste pour dire, si tu veux faire ‹ mumuse › avec, Maya vient avec un plugin pour les progressive meshs, et tu peux les charger tel quels avec directX 9 (et peut etre avant, le 9 c’est le premier que j utilise vraiement). sur msdn
[right][post=« 350901 »]<{POST_SNAPBACK}>[/post][/right][/quote]
Les progressive mesh sont dispo depuis DX8 dans D3DX Basés sur un papier de Microsoft Research.
