Rage, le jeu
Avant de nous pencher sur la technologie réservons quand même ce paragraphe à la présentation du premier jeu sensé l’illustrer : Rage. Rage a la lourde tâche d’être la première nouvelle licence venant d’id Software depuis plus de dix ans, époque à laquelle Quake est sorti. Et le moins que l’on puisse dire c’est que ce fut douloureux pour la firme texane. En effet, on sait déjà qu’après Quake III id Software a pendant un moment travaillé sur un nouveau jeu baptisé Quest avant que le projet ne soit abandonné, la firme (enfin essentiellement John Carmack) préférant se consacrer à Doom III.
Et l’histoire se répète : en 2004 Doom III vient tout juste de sortir, Carmack commence à travailler sur la technologie de son prochain moteur pendant que le reste de l’équipe est occupé par le portage Xbox. Le jeu basé sur cette technologie est alors appelé Darkness, pendant un an id Software travaille sur ce projet avant de décider dans un éclair de lucidité qu’un nouveau FPS se passant encore dans des couloirs sombres était peut être un peu redondant. La firme entre alors dans une phase de brainstorming au cours de laquelle plusieurs idées sont lancées et notamment celle de pouvoir utiliser des véhicules pour se déplacer dans des paysages post apocalyptiques immenses. Rage était né.
Pas de panique toutefois, id Software n’abandonne pas complètement sa formule classique, on retrouve donc des passages avec des flingues et une vue à la première personne. Le jeu prend peu à peu forme autour d’un univers ouvert dans lequel vous pourrez accomplir des missions comme bon vous semble, au milieu desquelles se déroulent des courses de buggys. L’argent que vous gagnerez dans ces courses pourra être réinvesti dans des boutiques pour acheter des armes ou améliorer votre véhicule.
Inutile de s’attarder plus longuement sur le jeu vu ce qu’id Software a révélé jusqu’ici, si vous souhaitez vous faire votre propre idée n’hésitez pas à vous rendre chez nos collègues de JeuxVideoPC.com pour télécharger la vidéo du trailer si ce n’est déjà fait.
Excellent article. Dommage que le Cry Engine 2 soit à peine mentionné à la fin, alors que techniquement il n'a clairement pas à rougir face au Unreal Engine 3... sans tout le batage marketing qui est fait à coté de ce dernier.
Pour ma part je suis content de voir J. Carmack revenir dans la course. J'ai toujours admiré son talent (et je suis grand fan de Quake devant l'eternel!) mais j'etais déçu par son travail sur DoomIII.
Concernant la partie numero 7 (suppositions sur l'algo)... C'est vraiment totalement farfelu...
Deja ... Faire un rendu de la scene dans une texture 1000x1000 est vraiment loin d'etre gratuit !! Surtout si la scene en question est chargée en vertices, si y'a beaucoup d'animations en vertex shader, etc... Ca irait sur une petite demo, mais sur un vrai jeu bien chargé, ca coute (relativement) cher ! Rajoutons à ça qu'il faut dans bien des cas utiliser la texture elle meme pour faire ce rendu (dans le cas d'un alpha test)... Les jeux modernes font deja beaucoup de rendus (ZPass, Shadow maps, Rendu final, etc...), inutile d'en rajouter encore un...
Recuperer la texture sur le CPU ensuite, c'est encore pire... Il faut plusieurs trames de decalages pour ne pas bloquer le CPU... Pas tres pratique... Obligé d'utiliser des double ou triple buffers, etc...
Quant à parcourir et traiter le résultat (4Mo pour une render target en 32bits., vu que les RTs 8 ou 16bits ça ne cours plus vraiment les rues) sur le CPU.. Ca ne serait qu'un gros gaspillage de temps CPU (Sans parler de la memoire cache) !
(Et puis recuperer l'information de la page de texture ne suffit pas.. il faut aussi connaitre le niveau de mipmap à utiliser, et certainement d'autres paramètres..)
Y'a quand meme 1000 fois plus rapide et beaucoup beaucoup plus simple pour faire tout ça, et sans embeter le GPU qui a certainement des choses bien plus interessantes à faire !
Concernant la partie numero 7 (suppositions sur l'algo)... C'est vraiment totalement farfelu...
Cette partie est pourtant basé sur un algo existant (cf lien dans l'article) farfelu peut être mais fonctionnel en tout cas
Comme tu le dis toi même plus bas les jeux modernes font déjà un nombre conséquent de passes (ne serait ce que pour les shadow maps tu fais un rendu Z par source lumineuse, 6 pour les sources omni !) je ne vois pas en quoi en faire une de plus ferait subitement s'écrouler les performances.
Dans le pire des cas en ignorant le test alpha tu ramèneras des pages qu is'avèreront inutiles, ça n'est pas vaiment rédhibitoire.
je vois pas pourquoi : ces dernières années c'est de ce genre de techniques utilisant de multiples rendus que sont venus les algorithmes les plus intéressants. Les GPU deviennent de plus en plus puissants autant les exploiter.
ça c'est effectivement déjà un problème plus sèrieux, mais avec les PBO en OpenGL tu dois pouvoir rapatrier ça de façon asynchrone avec d'assez bonnes perfs surtout que le PCI-Express améliore les performances en readback depuis la VRAM (enfin... en théorie même si on voit que dans la pratique c'est pas encore vraiment le cas). Sur les consoles tu n'as aucun problème : le rendu peut se faire directement en mémoire principale.
ça pourrait occupper un des cores de nos chers CPU au lieu de se tourner les pouces
Comme indiqué il ne s'agit que de suppositions basé sur une implémentation fonctionnelle, après il ya sans doute d'autres façons de faire, peut être plus efficaces, 1000 fois plus rapides par contre j'en doute
0) J'ai pas dit que ca ne fonctionnait pas.. loin de là.. Mais c'est utiliser un lance roquette pour ecraser un moustique...
1) Je ne dis pas que les performances vont s'ecrouler.. mais juste qu'un rendu supplementaire, c'est toujours du temps perdu.. Il n'est pas rare qu'un rendu prenne plus d'une ou deux milliseconde... c'est quand meme enorme.. Surtout si on vise le 60fps
1.bis) Le truc des alpha test n'est vraiment pas à negliger..
2) Non, les consoles (du moins la Xbox360 ou la PS3) ne peuvent pas faire de rendu dans la RAM principale.. Il faut rappatrier les render target depuis la VRAM.. Et ca prends un certain temps.
3) Occupper un core... ouai, mais y'a quand meme des trucs nettement plus interessant à lui faire faire nan ? ;-)
4) Ben si.. 1000 fois plus rapide... et largement meme... mais je peux pas trop en dire plus... Disons que globalement.. pourquoi s'embeter alors qu'on peut avoir toutes ces infos quasiment gratos ? ;-)
2) Non, les consoles (du moins la Xbox360 ou la PS3) ne peuvent pas faire de rendu dans la RAM principale.. Il faut rappatrier les render target depuis la VRAM.. Et ca prends un certain temps.
Pour la PS3 il faudrait que je revérifie mais il me semble que ça a été spécifiquement mentionné et globalement toutes les puces NVIDIA en sont capables depuis qu'ils ont introduit le Turbocache même si c'est pas exposé par l'API.
Pour la Xbox 360 c'est carrément sûr et certain, enfin ma tournure n'est peut être pas correcte : sur la Xbox 360 le backbuffer est toujours dans l'EDRAM donc certes le rendu ne se fait pas à proprement parler en RAM, mais il y a une copie systématique dans la mémoire principale lors du swap buffers (et effectue un downsample de l'AA par la même occasion si c'est utilisé) et c'est de la RAM que le RAMDAC tire ses données avant de les balancer à l'écran. En fait il doit même y avoir moyen d'utiliser le MEMXPORT pour écrire les données en mémoire directement en économisant une passe et cette discussion m'a permis de me rappeler d'd'une citation de Carmack qui mentionnait quelque chose de similaire sur l'utilisation du MEMEXPORT, après quelques recherches sur Google j'ai retrouvé ce qu'il disait exactement :
John Carmack
En tout cas ça semble bien confirmer qu'il utilise une passe disctincte pour déterminer les pages nécessaires.
Effectivement, on doit pouvoir utiliser le memexport sur la 360..
Mais c'est pas forcement plus rapide qu'un tracé en EDRAM suivi d'un resolve...
Mais, Carmack ou pas, je ne comprends toujours pas pourquoi s'embeter avec le GPU pour ça alors que toutes les infos sont à portée de main du CPU pour beaucoup moins cher (si on sait s'y prendre) ?!?! O_o
PS : toi aussi t'es du "metier" ?! ;-)
edit : oops "triplon" ;-)
edit : oops "triplon"
Du métier ? euh non
enfin si tu voulais dire dans les jeux vidéos, mais je bosse quand même sur du rendu temps réel.
Pour l'écriture du RSX en RAM principale je me souvenais bien que ça avait été indiqué quelque part :
j'suis à la masse de pas avoir retrouvé ça plus tôt : c'est moi qui avais écrit la news
Donc le RSX peut écrire en RAM principale (à 10.6Go/s mesuré deux fois moins que dans la VRAM) mais effectivement ça ne dit pas qu'il peut faire le rendu en RAM directement, ça pourrait être mesuré lors d'une copie de données de la VRAM à la RAM.
J'te reponds par MP ;-)
Tres bon Article... vraiment interessant, et les commentaires valent également le coup.
Juste une question concernant ces "Megatextures".
Comme je l'ai compris, elles permettent de définir "une partie" des décors, une zone. Mais que se passe t'il lorsque l'on doit afficher une autre zone ? une nouvelle Megatexture est adressée je suppose, mais si l'on souhaite avoir une grande distance d'affichage le moteur ne risque t'il pas de saturer bcp plus rapidement qu'avec un moteur "plus classique" ???
J'imagine un rendu type Oblivion et je me demande comment se type d'algo pourrait supporter cela....
PS : Tres bon site que je re découvre avec grand intérêt avec des articles comme ceux là
doublon...
chacun son tour, désolé.....
de même, vraiment intéressant. on en apprend beaucoup
"Après plusieurs années de silence, id Software sort de son mutisme et se relance dans la bataille des moteurs 3D en venant s’attaquer sérieusement à l’Unreal Engine 3"
cough cough. Non mais serieux carmack en ce moment il est serieusement overrated.. on fait mieux dans notre boite que sa merde de megatextures... on devrait lui vendre notre tech..
C'est quoi ta boite nystep par curiosité ? Quantic Dream ?
"Après plusieurs années de silence, id Software sort de son mutisme et se relance dans la bataille des moteurs 3D en venant s’attaquer sérieusement à l’Unreal Engine 3"cough cough. Non mais serieux carmack en ce moment il est serieusement overrated.. on fait mieux dans notre boite que sa merde de megatextures... on devrait lui vendre notre tech..
c'est vrai que les megatextures c'est pas forcément l'idéal, surtout que niveau qualité des filtrages on y perds pas mal, en tout cas c'est moins propre que des textures classiques + aniso...
On a vraiment l'impression que certains ne lisent que le début et la fin des articles. Le but des megatextures n'est pas de créer la solution ultimes pour les rendus 3D sur PC hyper-puissants. Il s'agit d'une solution élégante permettant une bonne qualité d'image et un Framerate correct. Le tout portable sur différentes architectures et surtout qui soit très simple à utiliser pour les concepteurs de niveaux. Il n'y a pas que la technique qui rentre en ligne de compte dans la conception d'un jeu vidéo....
eu, c'est normal qu'un article de 2007 se retrouve a la une du site en 2009? recyclage?
eu, c'est normal qu'un article de 2007 se retrouve a la une du site en 2009? recyclage?
Il faut croire
Ceci dit c'est un très bon article, qui est loin d'être périmé : il faudrait juste une petite mise à jour pour les évolutions depuis 2 ans !
Erreur technique, désolé
ZeJeff,
Pourquoi avoir tant de doutes quand à ses travaux ? Aussi, bien qu'intéressant, je m'étonne de ton raisonnement. Faut-il rappeler que John Carmack a réalisé le premier FPS (Quake) à présenter un environnement totalement en 3D dans l'histoire du jeu vidéo et dont des dizaines de sociétés ont acheté leur moteur ? (dont Valve Software pour réaliser Half-Life par la suite). Il est l'un des plus célèbre développeur indépendant capable de réaliser des moteurs graphiques exploitant au maximum les évolutions du atériel, en particulier des cartes graphiques pour PC. Il a rejoint le panthéon des développeurs de l'Académie des Arts et des Sciences Interactifs. L'année dernière, il fût de nouveau récompensé par l'GDC Lifetime Award. Le moteur de Quake 3 a été également le plus abouti en 1999-2000 (sachant que les cartes vidéos de l'époque n'étaient pas aussi avancées qu'aujourd'hui).
C'est également lui qui a inventé plusieurs algorithmes 3D les plus rapides et les plus avancés, dont celui du "Carmack's Reverse" ou "Robust Stencil Shadow Volumes" pour Doom 3 (calcul des ombres en temps réel dans une scène graphique en 3D utilisé pour la toute première fois dans le monde du jeu vidéo en 2003-2004). Sans compter que pratiquement tous les jeux d'Id Software tournent également sous GNU/Linux et MAC, ce qui est très rare chez les autres développeurs de jeux vidéo ! Par ailleurs, Doom 3 a été le premier jeu à réellement exploiter le potentiel du circuit graphique de la carte vidéo GeForce 3 ! Je citerais le bump mapping, le normal mapping, le specular highlighting, unified lighting et shadowing, shadow volume, megaTexture. Ses travaux sont reconnus depuis fort longtemps comme étant très souvent les plus avancés.
Je pense qu'il est devenu si banale de nos jours avec tous les nouveaux jeux sur PS3, PC et XBOX360 qui ont découler bien souvent de ses travaux, que beaucoup de gens semblent l'avoir oublié. De ce fait, je crois très sincèrement qu'il n'y a aucun souci à se faire, de remettre en cause ses travaux où d'avoir des doutes quand a leurs utilités futures. Et puis, il est suffisamment bien placé pour savoir ce qui sera utile ou non pour les jeux vidéo et pour les cartes vidéos de demain. Il est bon d'avoir un esprit critique ZeJeff, mais il faudrait éviter de ternir cette qualité par un esprit d'immobilisme et de se faire des noeux au cerveau.