Tomb Raider : la configuration requise pour PC dévoilée

Adeptes de la Pomme, passez votre chemin

Le 22 février 2013 à 14h23

3 min

Société numérique

Société

Eidos vient de publier sur son forum officiel les configurations minimales et recommandées pour Tomb Raider, ainsi que les fonctionalités dédiées à la version PC. Au programme : des textures plus fines, l'emploi de la tesselation, mais surtout l'absence de DRM intrusif.

Une utilisation raisonnable des DRM

À première vue, Lara Croft fait partie des bons élèves quand il s'agit de parler du portage de ses prochaines aventures sur PC. Si l'on en croit les déclarations d'Eidos, le studio chargé du développement de Tomb Raider, la version PC devrait profiter d'un certain nombre d'améliorations par rapport aux moutures pour PlayStation 3 et Xbox 360. Mais surtout, Eidos n'est pas tombé dans certains travers comme l'utilisation déraisonnée de DRM.

En effet, le studio annonce que mis à part l'enregistrement de la clé CD sur Steam, aucun autre mécanisme de protection ne sera mis en place. Posséder une version physique de Tomb Raider vous dispensera également de devoir télécharger le titre via la plateforme de Valve. Un mode hors ligne est également prévu, contrairement à Diablo III (pour ne citer que lui) il ne sera donc pas nécessaire de se connecter à Internet pour jouer en solo.

Des améliorations graphiques bienvenues

Eidos promet également des améliorations exclusives à la version PC. Des textures « très haute définition » sont ainsi prévues, et l'éditeur précise qu'elles pourront peser jusqu'à 16 fois plus que celles de la version console. La tessellation sera également de la partie ainsi que la présence d'ombres de meilleure qualité, et d'un champ de vision étendu. Le taux de rafraichissement ne sera pas limité du tout, pas même à 30 ou 60 Hz. « Si votre matériel permet d'afficher 120 images par seconde, il le fera. Nous n'imposons aucune restriction sur le taux de rafraichissement, le jeu affichera autant d'images par seconde que votre matériel le permet », annonce Eidos. Enfin, sachez que les technologies Eyefinity d'AMD et Surround de NVIDIA sont compatibles avec le jeu.

Les possesseurs de machines modestes ne semblent pas oubliés, puisque Windows XP sera supporté, tandis que de nombreux réglages graphiques seront disponibles afin d'adapter la qualité du jeu au matériel disponible.

Une configuration requise accessible

Enfin, Eidos a également révélé les configurations minimales et recommandées pour Tomb Raider. De nombreuses machines devraient pouvoir tenir les recommandations minimales, mais pour profiter du titre dans les meilleures conditions, une mise à jour pourra s'imposer pour certains.

Configuration minimale :

Windows XP SP3, Windows Vista,7,8 (32bit/64bit)
Carte graphique compatible Direct X 9 avec 512 Mo de RAM : AMD Radeon HD 2600 XT ou nVidia 8600
Processeur double coeur : AMD Athlon64 X2 2.1 GHz (4050 +), ou Intel Core2 Duo 1.86 GHz (E6300)
1 Go de mémoire vive (2 Go pour Vista)

Configuration recommandée :

Windows Vista, Windows 7 ou Windows 8
Carte graphique compatible Direct X 11 avec 1 Go de RAM: AMD Radeon HD 4870, nVidia GTX 480
Processeur quadruple coeur : AMD Phenom II X2 565 ou Intel Core i5-750
4 Go de mémoire vive

Certains auront bien sûr remarqué la promotion du Phenom II X2 au rang de processeur quadruple coeur. Faudra-t-il débloquer deux de ses coeurs endormis ? Concernant la présence de la Radeon HD4870 parmi les cartes compatibles DirectX 11 Jay Walker donne une explication plausible : « la 4870 n'est techniquement pas une carte DirectX11 mais elle supporte la tesselation, donc la recommander pour ses performances est logique ». Dernier détail, il n'est pas question pour le moment d'une version pour Mac.

Commentaires (85)

Wikus

Le 22/02/2013 à 14h27

Posséder une version physique de Tomb Raider vous dispensera également de devoir télécharger le titre via la plateforme de Valve

est-ce que ce sera tout de même possible, ou non ?

Ellierys

Le 22/02/2013 à 14h29

FrenchPig a écrit :

est-ce que ce sera tout de même possible, ou non ?

Par la suite sans aucun problème oui.

Anonyme

Le 22/02/2013 à 14h29

En effet, le studio annonce que mis à part l’enregistrement de la clé CD sur Steam, aucun autre mécanisme de protection ne sera mis en place.

Donc pas de revente d’occasion possible pour la version boite.

xxSeize

Le 22/02/2013 à 14h30

Enfin un éditeur un temps soit peu sérieux sur la version dédiée au PC … comme pour Deus Ex, merci Eidos.

Leezi

Le 22/02/2013 à 14h31

" />

J’ai vraiment hâte après avoir lu ça !!

pandaroux

Le 22/02/2013 à 14h32

pafLaXe a écrit :

Donc pas de revente d’occasion possible pour la version boite.

Tu l’actives si ça te chante sur Steam.

Takaï

Le 22/02/2013 à 14h34

La news parle beaucoup de Steam… Ca veut dire que quelque soit la version du jeu (physique ou démat’) il faudra le présence de Steam et d’un compte associé ?

Ou le jeu peut s’en passer intégralement ?

Anonyme

Le 22/02/2013 à 14h34

Le tesselation, ou comment rajouter des polygones par interpolation.

Les économies de bandes passantes du bus sur les données des vertex/primitives sont si intereressantes que ça?? (GROS DOUTES)

Faudrait des chiffres, car sinon autant laisser les 3D designers ajouter les polygones là où ils vont bien.

AnthoniF

Le 23/02/2013 à 16h07

Le nouveau Tomb Raider sera-t-il autant trop assisté pour la nouvelle génération de joueur que l’ancien ? " />

Une belle d’aube en vue…

Une bonne nouvelle, merci bien pour l’option Steamworks ;)

SrBelial

Le 23/02/2013 à 18h24

Reparateur a écrit :

je suis daccord avec toi

je dirais même que la tesselation à l’air d’être un truc inutile

quand ATI à sorti ça au début c’était pour améliorer les jeux déjà existant genre counter strike

sauf que bon ça n’a jamais percé car généralement les poly sont ajouté n’importe comment

je pense que l’avantage c’est le coté dynamique du truc suivant la charge GPU la distance de vue etc

mais dans tout les cas le dev doit surement ce taper tout les modèle poly à la main avant si il ne veut pas un résultat absurde à la fin

en fait l’avantage c’est la diminution des détail et non l’inverse

tu fait un truc high poly et la tesselation se charge de réduire les détail quand ils sont pas nécessaires

mais bon certain moteur savais déjà faire ça sans la tesselation

juste ça doit être plus facile à implémenter maintenant

bref à l’heure actuel j’ai surtout l’impression que c’est du pipo marketing pour activer le mode non dégradé du rendu des poly

sylware a écrit :

Bin voilà… ça résume un peu tout en un peu plus direct sur la forme.

Le truc, c’est que si les polygones ne sont pas placés trop n’importe comment et que c’est fiable dans quasiment tous les cas de figures, avec des maps de relief fines au niveau des vertex shaders, ça en jète, et tout ça sans CPU et au GPU.

Donc prudence et tests vont de mise…

Vous avez en partie raison tous les deux.

On est d’accord sur le point que réduire procéduralement le nombre de polys présente un gros avantage à moindre frais, en revanche son augmentation a l’air encore de faire débat …….. Expliquons quelques trucs.

La tesselation a été vendue comme un remède miracle pour rendre les jeux plus beaux à moindre frais. Sauf qu’effectivement appliquée comme ça sans plus de travail c’est insatisfaisant.

En revanche je prend le cas idéal :

on a admettons une CG qui a une puissance suffisante pour afficher disons …. 1000 000 de polygones dans un contexte donné.

deux cas :

1°) on lui donne à manger 1000 000 de polygones, sans plus de cérémonies

et pour les questions d’optim, on effectue procéduralement une réduction du nombre de polys en fonction de la disance de l’objet par rapport à la caméra.

=> On a donc un graphiste qui s’est fait plaisir avec son million de polys, qu’on doit stocker dans un asset très volumineux, long à charger. Le résultat est très joli mais par la suite retravailler sur un tel modèle est juste horrible, et je parle pas du skinning sur lequel les animateurs vont s’arracher les cheveux (sans évoquer les plantages de 3DSMax :P)

ça a donc des avantages mais également des inconvénients.

2°) on lui donne à manger un modèle allégé en polygones, pour les questions d’optim on applique procéduralement le même traitement qu’en 1°). Par contre pour l’affichage en gros on voudrait quelque chose de plus propre => on fait appel à la tesselation.

=> On a donc un graphiste qui a bossé un peu plus sur son modèle, en a fait une version avec un très grand nombre de poly, et grâce à un bake a pu stocker dans une ou plusieurs texture (de façon automatique, sans connaissance particulière nécessaire) les informations nécessaires pour la reconstruction de ces nombreux polys à partir d’un modèle beaucoup moins lourd. C’est cette étape et ces informations qui permettront plus tard d’appliquer les modèles mathématiques évoqués dans les messages précédents. Le graphiste a pu prévoir comment sera fait la montée en résolution de son modèle, c’est la carte graphique qui déterminera ensuite quels polys et à quel moment les ajouter, à partir des infos stockées dans les textures appropriées.

La modification du modèle basse résolution est plus simple que celle du modèle highdef, idem pour le skinning, et le stockage et le chargement des assets contenant la définition du modèle sera incomparablement plus rapide (modèle + texture).

Si c’est bien fait ça présente donc de nombreux avantages en termes de qualité, en revanche effectivement cela a un coût en temps de création. Mais l’inverse est vrai aussi : créer et manipuler des modèles extrêmement détaillés est très coûteux également !!

Enfin pour conclure, je dirais qu’au niveau logiciel, le codage du moteur 3D à proprement parler ne nécessite pas particulièrement plus de travail. Il se contente de charger les assets, de les placer, et de les faire manger à la CG. L’activation de la tesselation ou non ne constitue qu’un paramètre supplémentaire à gérer. Idem pour les shaders : le vertex et le pixel shader prennent en entrée les infos que leur donne la carte. Qu’elle leur donne un poly défini dans le modèle ou interpolé ne change rien pour eux, les calculs s’appliquent de la même façon.

Si des gros studios de jeu utilisent ce genre de techniques, c’est bien que cela présente un intérêt derrière, faites leur confiance ;)

edit : ne pas confondre la tesselation et la réduction du nombre de polys. la tesselation c’est réellement l’opération inverse : on ajoute des polys " />

mancuso85

Le 23/02/2013 à 21h23

Ce qui me déprime (un tout petit peu), c’est que je viens de recevoir ma Radeon HD 7870 avec le bundle Bioshock Infinite et Tomb Raider, et qu’elle remplace justement une HD 4870, qui à servi fièrement et fidèlement pendant plus de 3 ans.

Ah bon, avec ma 4870 sous Win7, dans les benchs/jeux avec tesselation, l’option est toujours grisée chez moi.

Ou alors leur jeu sera plus intelligent et saura proposer la tesselation avec un 4870 sans que les perfs s’ecroulent?

Ouiais tout pareil, j’ etais pas au courant que la mémère supportait la tesselation, tu rends compte ?

Reparateur

Le 25/02/2013 à 09h38

SrBelial a écrit :

Vous avez en partie raison tous les deux.

On est d’accord sur le point que réduire procéduralement le nombre de polys présente un gros avantage à moindre frais, en revanche son augmentation a l’air encore de faire débat …….. Expliquons quelques trucs.

La tesselation a été ve.

………….

réduction du nombre de polys. la tesselation c’est réellement l’opération inverse : on ajoute des polys " />

merci pour ton explication ça tient là route

de toute façon si un studio utilise le truc c’est que ça un interet pour lui

après je me méfie des démo technique ou les gar te disent wé y a de la tesselation à fond et c’est juste un prétexte pour rajouter tout un tas de poly inutiles qui fond ramer et que tu peut sortir exactement la même avec une texture toute simple et des poly tout simple ^^

après j’ai aucune idée comment les poly vont aussi encombrer les buss de transfer de la CG par rapport à une texture qui contient les info de tesselation

j’veut dire je me demande qu’est ce qui est le plus économe en terme de perf

peut être que de ce coté il n’y a aucune différence et que les avantage sont ceux qui tu as cité

Reparateur

Le 25/02/2013 à 09h38

SrBelial a écrit :

Vous avez en partie raison tous les deux.

On est d’accord sur le point que réduire procéduralement le nombre de polys présente un gros avantage à moindre frais, en revanche son augmentation a l’air encore de faire débat …….. Expliquons quelques trucs.

La tesselation a été ve.

………….

réduction du nombre de polys. la tesselation c’est réellement l’opération inverse : on ajoute des polys " />

merci pour ton explication ça tient là route

de toute façon si un studio utilise le truc c’est que ça un interet pour lui

après je me méfie des démo technique ou les gar te disent wé y a de la tesselation à fond et c’est juste un prétexte pour rajouter tout un tas de poly inutiles qui fond ramer et que tu peut sortir exactement la même avec une texture toute simple et des poly tout simple ^^

après j’ai aucune idée comment les poly vont aussi encombrer les buss de transfer de la CG par rapport à une texture qui contient les info de tesselation

j’veut dire je me demande qu’est ce qui est le plus économe en terme de perf

peut être que de ce coté il n’y a aucune différence et que les avantage sont ceux qui tu as cité

Reparateur

Le 25/02/2013 à 09h40

mancuso85 a écrit :

Ce qui me déprime (un tout petit peu), c’est que je viens de recevoir ma Radeon HD 7870 avec le bundle Bioshock Infinite et Tomb Raider, et qu’elle remplace justement une HD 4870, qui à servi fièrement et fidèlement pendant plus de 3 ans.

Ouiais tout pareil, j’ etais pas au courant que la mémère supportait la tesselation, tu rends compte ?

les radeon je sais plus le numéro sortie il y a 10 ans géraient déjà la tesselation ^^

après je crois qu’il avais supprimé cette fonctionnalité pendant quelques années

SrBelial

Le 25/02/2013 à 10h00

Reparateur a écrit :

merci pour ton explication ça tient là route

de toute façon si un studio utilise le truc c’est que ça un interet pour lui

après je me méfie des démo technique ou les gar te disent wé y a de la tesselation à fond et c’est juste un prétexte pour rajouter tout un tas de poly inutiles qui fond ramer et que tu peut sortir exactement la même avec une texture toute simple et des poly tout simple ^^

après j’ai aucune idée comment les poly vont aussi encombrer les buss de transfer de la CG par rapport à une texture qui contient les info de tesselation

j’veut dire je me demande qu’est ce qui est le plus économe en terme de perf

peut être que de ce coté il n’y a aucune différence et que les avantage sont ceux qui tu as cité

plus économe en termes de perfs …. ça dépend de quoi on a besoin et ce qu’on cherche à atteindre :)

tout est une histoire de compromis !

De ce côté je suis pas assez calé pour dire à quel moment faut arrêter de tesseler et remplacer les détails modelés par des détails texturés :)

Anonyme

Le 26/02/2013 à 10h45

SrBelial a écrit :

=> On a donc un graphiste qui a bossé un peu plus sur son modèle, en a fait une version avec un très grand nombre de poly, et grâce à un bake a pu stocker dans une ou plusieurs texture (de façon automatique, sans connaissance particulière nécessaire) les informations nécessaires pour la reconstruction de ces nombreux polys à partir d’un modèle beaucoup moins lourd. C’est cette étape et ces informations qui permettront plus tard d’appliquer les modèles mathématiques évoqués dans les messages précédents.

Je ne suis pas encore versé dans la tesselation hardware (ça arrive… mollo… je viens juste du publier mon assembleur partiel de shader pour GCN d’AMD). Mais ce dont tu parles sont les fameuses map ultra fines d’interpolation des positions des vertex (qui seront lues et appliquées par les vertex shaders). Ce qui me fait un peu peur c’est la pression sur le bus modulo la gestion de la mémoire cache pour que les vertex shaders “tapent” dans cette map à priori costo. Un moteur 3D peut prendre le soin d’abaisser la résolution de cette map pour augmenter l’efficacité de la mémoire cache et par la même occasion alléger la pression sur le bus. Je sais que sur les GCN d’AMD, les vertex shaders ont un contrôle fin sur les niveaux de cache de texture (ceux utilisés par les vertex shaders pour “taper” dans ces maps).

Cela signifie que le modeleur (blender), sait comment le vertex shader va interpoler la position des vertex des polygones pour “baker” cette fameuse map. Or cela est directement dépendant du code de vertex shader qui varie d’un moteur à un autre. C’est donc au programmeur des vertex shaders d’un moteur 3D de fournir les infos ou carrément les plugins pour blender (ouaip, je suis open sourcer et j’assume " />, même si je n’aime pas du tout le c++).

SrBelial

Le 26/02/2013 à 11h14

sylware a écrit :

Je ne suis pas encore versé dans la tesselation hardware (ça arrive… mollo… je viens juste du publier mon assembleur partiel de shader pour GCN d’AMD). Mais ce dont tu parles sont les fameuses map ultra fines d’interpolation des positions des vertex (qui seront lues et appliquées par les vertex shaders). Ce qui me fait un peu peur c’est la pression sur le bus modulo la gestion de la mémoire cache pour que les vertex shaders “tapent” dans cette map à priori costo. Un moteur 3D peut prendre le soin d’abaisser la résolution de cette map pour augmenter l’efficacité de la mémoire cache et par la même occasion alléger la pression sur le bus. Je sais que sur les GCN d’AMD, les vertex shaders ont un contrôle fin sur les niveaux de cache de texture (ceux utilisés par les vertex shaders pour “taper” dans ces maps).

Cela signifie que le modeleur (blender), sait comment le vertex shader va interpoler la position des vertex des polygones pour “baker” cette fameuse map. Or cela est directement dépendant du code de vertex shader qui varie d’un moteur à un autre. C’est donc au programmeur des vertex shaders d’un moteur 3D de fournir les infos ou carrément les plugins pour blender (ouaip, je suis open sourcer et j’assume " />, même si je n’aime pas du tout le c++).

aucun souci copain opensourcer ! " />

Sauf erreur de ma part, on a deux process différents qui s’imbriquent en fait :

Le modeleur (quel que soit l’outil qu’il utilise), ne sait pas précisément comment son objet sera tesselé, et il n’a aucun avantage à savoir ça.

il sait juste exploiter ses outils (création highpoly / lowpoly / unwrap / bake)

c’est un procédé plus ou moins automatique, qui lui permet en sortie d’avoir sa map. Il ne peut faire confiance qu’à ses outils pour qu’avec cette map la tesselation permette à son objet lowpoly d’être le plus fidèlement possible extrapolé vers l’objet highpoly.

En gros bien sur que le modeleur sait ce que contient la map, non pas parce qu’il sait en détail comment se passe l’interpolation, mais parce que les infos générées pendant le bake seront calculées pour représenter le diff entre Highpoly et Lowpoly :)

Le process suivant c’est au niveau du runtime, et là je connais beaucoup moins finement comment ça se passe au niveau mise en cache, quels sont les pipes utilisés, le parallèle avec un P ou un V Shader est vite fait.

Ce que je sais c’est simplement qu’à partir de là, la quantité d’informations à traiter est beaucoup moins grosse que s’il s’était agi d’utiliser uniquement le Highpoly. Derrière c’est de la cuisine interne à la CG, du tuning de paramètres pour déterminer les mécanismes et les niveaux de mise en cache des maps.

Il me semble que les V et P Shader sont appelés après seulement, sur le modèle déjà tesselé, donc muni ou non de ses nouveaux polys.

Anonyme

Le 26/02/2013 à 11h35

SrBelial a écrit :

…

Bin le truc, si j’ai bien compris, la tesselation hw est faite avant l’étape du vertex shader. Le truc, c’est que le modeleur n’aura aucun pb pour générer la map si c’est de la tesselation à plat, par contre pour de la tesselation, genre “algo qui améliore” les arrondis (pour les ombres portés, etc…), c’est une autre histoire, car le modeleur devrait être capable d’approcher très finement ce que saura faire le GPU pour “baker” les maps qui vont bien. De plus, il faut espérer que le hw place bien ces nouveaux polygones dans tous les cas de figure, ce qui ne serait pas franchement le cas (je présume pour les cas de figures hors du plan).

Comme d’hab: prudence et tests… allez… faut que j’aille faire le désassembleur pour les shaders des GCN d’AMD.

SrBelial

Le 26/02/2013 à 14h01

sylware a écrit :

Bin le truc, si j’ai bien compris, la tesselation hw est faite avant l’étape du vertex shader. Le truc, c’est que le modeleur n’aura aucun pb pour générer la map si c’est de la tesselation à plat, par contre pour de la tesselation, genre “algo qui améliore” les arrondis (pour les ombres portés, etc…), c’est une autre histoire, car le modeleur devrait être capable d’approcher très finement ce que saura faire le GPU pour “baker” les maps qui vont bien. De plus, il faut espérer que le hw place bien ces nouveaux polygones dans tous les cas de figure, ce qui ne serait pas franchement le cas (je présume pour les cas de figures hors du plan).

Comme d’hab: prudence et tests… allez… faut que j’aille faire le désassembleur pour les shaders des GCN d’AMD.

tout l’intérêt du bake est là ! générer les infos qui permettront une bonne tesselation. c’est au GPU de s’approcher du travail fait par l’artiste sur le highpoly, pas au modeleur de s’approcher de ce que fera le GPU ;)

le bake c’est juste un precalc de ce qui sera fait plus tard par le GPU, c’est pour ça que les ingrédients du bake sont faits par le graphiste et constituent les seules informations vraiment indispensables.

Et effectivement de toute façon sur des faces planes il est plus judicieux de supprimer des polys que d’en rajouter " />

bon courage pour ton désassembly ;)

Anonyme

Le 27/02/2013 à 17h28

SrBelial a écrit :

Et effectivement de toute façon sur des faces planes il est plus judicieux de supprimer des polys que d’en rajouter " />

bon courage pour ton désassembly ;)

Euuuuh… sauf si tu interpoles la positions des vertex des polygones ajoutés par tesselation avec une map de relief… (c’est ce que montre la majorité des démos sur la tesselation).

Ayé… assembleur/désassembleur dans la boite… partiel, mais le gros de la plomberie est là… je vais maintenant faire le lien entre mon compositeur wl_shell wayland et mon driver de GPU GCN d’AMD.

SrBelial

Le 28/02/2013 à 06h41

sylware a écrit :

Euuuuh… sauf si tu interpoles la positions des vertex des polygones ajoutés par tesselation avec une map de relief… (c’est ce que montre la majorité des démos sur la tesselation).

Ayé… assembleur/désassembleur dans la boite… partiel, mais le gros de la plomberie est là… je vais maintenant faire le lien entre mon compositeur wl_shell wayland et mon driver de GPU GCN d’AMD.

on s’est bien compris, je parlais de surfaces qui au rendu devaient être planes " />

Ellierys

Le 22/02/2013 à 14h36

Takaï a écrit :

La news parle beaucoup de Steam… Ca veut dire que quelque soit la version du jeu (physique ou démat’) il faudra le présence de Steam et d’un compte associé ?

Ou le jeu peut s’en passer intégralement ?

Q: If I purchase a boxed copy of Tomb Raider, does that mean I’ll still be able to play it using Steam?

“Every copy of Tomb Raider will integrate with Steam and use the Steamworks features; it does not matter where you bought it.”

Q: Will the game require the disc to be in the computer or is it able to directly download from Steam?

“Yes, when you buy the game in a store you will get a CD-Key for Steam. Just entering this code on your Steam account will allow you to download the game, so you do not necessarily need the disk. The disk is just there so you do not have to download all that data.”

Takaï

Le 22/02/2013 à 14h36

sylware a écrit :

Le tesselation, ou comment rajouter des polygones par interpolation.

Les économies de bandes passantes du bus sur les données des vertex/primitives sont si intereressantes que ça?? (GROS DOUTES)

Faudrait des chiffres, car sinon autant laisser les 3D designers ajouter les polygones là où ils vont bien.

C’est peut-être aussi un moyen de toucher des config plus modeste avec des modèles 3D moins aboutis tout laissant les plus grosses bécane avoir un meilleurs rendu.

bombo

Le 22/02/2013 à 14h40

Takaï a écrit :

C’est peut-être aussi un moyen de toucher des config plus modeste avec des modèles 3D moins aboutis tout laissant les plus grosses bécane avoir un meilleurs rendu.

Et puis rajouter tout plein de polygones à la main, c’est peut être juste méga fastidieux et onéreux ? :-)

Kahyo

Le 22/02/2013 à 14h40

Moi j’ai hâte mais peur d’être déçu, j’ai vue des vidéo et ça ressemble à du “Far Cry3/Splinter Cell”. Ce que j’attent d’un Tomb Raider c’est que ce soit un Tomb Raider et ça semble pas très bien parti (malgré que ça a l’aire d’un très très bon jeux hein)

Takaï

Le 22/02/2013 à 14h40

Ellierys a écrit :

Q: If I purchase a boxed copy of Tomb Raider, does that mean I’ll still be able to play it using Steam?

“Every copy of Tomb Raider will integrate with Steam and use the Steamworks features; it does not matter where you bought it.”

Q: Will the game require the disc to be in the computer or is it able to directly download from Steam?

“Yes, when you buy the game in a store you will get a CD-Key for Steam. Just entering this code on your Steam account will allow you to download the game, so you do not necessarily need the disk. The disk is just there so you do not have to download all that data.”

Ok Steam et compte associé obligatoire dans tous les cas.

Merci. " />

Navré d’avoir posé la question mais le forum officiel m’est inaccessible. (proxy du boulot à tendance paranoïaque toussa… " />)

sniperdc

Le 22/02/2013 à 14h43

ça va c’est pas trop gourmand " />

Je vais recycler ma conf’ avec Intel QX9650 (775) en HTPC pour un Intel Core i7 3930K.

Avec Battlefield et cela même avec une bonne carte graphique, ma carte mère et mon CPU donnent tout ce qu’il leur reste pour un résultat somme tout correcte cependant je suis trop juste dans certains jeux.

Edit je viens juste de constater que la base de ma conf à 7 ans " />

Anonyme

Le 22/02/2013 à 14h44

pandaroux a écrit :

Tu l’actives si ça te chante sur Steam.

Je pense pas que ça soit facultatif.

DorianM

Le 22/02/2013 à 14h50

Même si je l’ai précommandé sur PS3, bravo pour les améliorations PC ! " />

Anonyme

Le 22/02/2013 à 14h50

Takaï a écrit :

C’est peut-être aussi un moyen de toucher des config plus modeste avec des modèles 3D moins aboutis tout laissant les plus grosses bécane avoir un meilleurs rendu.

C’est le niveau de détail du jeu (les curseurs) qui est supposé définir le nombre de polygones.

Personnellement, je me sens nettement plus à l’aise (c peut-être infondé) avec des polygones ajoutés là où il faut par un designer 3D qu’interpolés un peu magiquement par le GPU…. ahem… la question mérite d’être sérieusement tournée dans tous les sens, car je me doute bien que la tesselation n’est certainement pas donné en “coût silicium”.

On va me dire “mais y a des ingénieurs qui ont super réfléchi au bouzin et blablabla…”. D’expérience y a surtout beaucoup d’ingénieurs qui subissent les caprices du marketing.

Et attention aux benchmarks qui sont conçus pour mettre en valeur au mieux l’intelligence d’interpolation du silicium… qui sera loin de marcher bien dans tous les cas de figure.

Blood_Man

Le 22/02/2013 à 14h56

sylware a écrit :

[…]

Il y a au moins l’avantage de ne pas avoir à créer tous les LODs.

Tu peux même imaginer un gros modèle, où seule la partie proche de toi est détaillée, alors que la partie plus loin l’est de moins en moins.

SrBelial

Le 22/02/2013 à 14h57

sylware a écrit :

Le tesselation, ou comment rajouter des polygones par interpolation.

Les économies de bandes passantes du bus sur les données des vertex/primitives sont si intereressantes que ça?? (GROS DOUTES)

Faudrait des chiffres, car sinon autant laisser les 3D designers ajouter les polygones là où ils vont bien.

comme dit avant moi, y a plusieurs avantages à la tesselation autres qu’économiser la BP.

Moi j’en vois surtout un autre : réduire le besoin d’utiliser des modèles multirés.

Il n’y a pas que l’ajout de polygones par interpolation, j’ose espérer que leur moteur d’affichage contient également de la simplification des géométries en fonction de la distance dans le frustum (ça y est j’ai placé un terme technique bien pourri).

La multirésolution ça a surtout un sacré coût en termes de création des modèles, et de poids des géométries, et donc de temps de chargement nécessaire. Gérer procéduralement sa simplification ou sa complexification c’est plutôt bien ressenti quand on est dans la peau du joueur.

edit : caramba ! encore grillé !!!

:(

SrBelial

Le 22/02/2013 à 14h57

edit : auto reply

Jean_Peuplus

Le 22/02/2013 à 14h59

mis à part l’enregistrement de la clé CD sur Steam, aucun autre mécanisme de protection ne sera mis en place.

Forcément, ça suffit pour éviter le piratage, ce qui est l’objet même des DRM. Pas la peine d’en rajouter une couche.

mamath7

Le 22/02/2013 à 15h00

Par contre WTF le phenom II x2 ?! " />

SrBelial

Le 22/02/2013 à 15h00

sylware a écrit :

C’est le niveau de détail du jeu (les curseurs) qui est supposé définir le nombre de polygones.

Personnellement, je me sens nettement plus à l’aise (c peut-être infondé) avec des polygones ajoutés là où il faut par un designer 3D qu’interpolés un peu magiquement par le GPU…. ahem… la question mérite d’être sérieusement tournée dans tous les sens, car je me doute bien que la tesselation n’est certainement pas donné en “coût silicium”.

On va me dire “mais y a des ingénieurs qui ont super réfléchi au bouzin et blablabla…”. D’expérience y a surtout beaucoup d’ingénieurs qui subissent les caprices du marketing.

Et attention aux benchmarks qui sont conçus pour mettre en valeur au mieux l’intelligence d’interpolation du silicium… qui sera loin de marcher bien dans tous les cas de figure.

c’est pas faux ce que tu dis, sauf qu’il y a niveau de détail pour s’adapter à ta config et niveau de détail pour s’adapter à la taille de l’objet dans le champ de vision de la caméra.

Objet en gros plan et objet vu de loin c’est mieux de pouvoir adapter le nombre de polys envoyés à la CG, ou de lui demander de faire le boulot " />

Edtech Abonné

Le 22/02/2013 à 15h01

La tesselation ne fait pas un bête ajout de polygone au hasard ! C’est directement indiqué dans le modèle comment la tesselation doit s’appliquer. C’est donc exactement comme si le designer l’avait fait lui-même !

Par contre, il faudra m’expliquer pourquoi dans Batman AC, les visages sont nickels mais les épaules toutes carrées…

SrBelial

Le 22/02/2013 à 15h03

Edtech a écrit :

La tesselation ne fait pas un bête ajout de polygone au hasard ! C’est directement indiqué dans le modèle comment la tesselation doit s’appliquer. C’est donc exactement comme si le designer l’avait fait lui-même !

Par contre, il faudra m’expliquer pourquoi dans Batman AC, les visages sont nickels mais les épaules toutes carrées…

il est possible que ce soient pas les mêmes personnes qui font les visages et le reste des modèles.

ou alors c’est les animateurs qui ont loosé sur le skinning

Takaï

Le 22/02/2013 à 15h04

sylware a écrit :

C’est le niveau de détail du jeu (les curseurs) qui est supposé définir le nombre de polygones.

Personnellement, je me sens nettement plus à l’aise (c peut-être infondé) avec des polygones ajoutés là où il faut par un designer 3D qu’interpolés un peu magiquement par le GPU…. ahem… la question mérite d’être sérieusement tournée dans tous les sens, car je me doute bien que la tesselation n’est certainement pas donné en “coût silicium”.

Simple hypothèse que j’émettais vis à vis de ce que tu disais. ^^

Du peu que j’ai vu avec un début de tuto blender il y a bien longtemps, plus le modèle est complexe, plus la machine a du mal à le générer.

Donc un modèle moins complexe permet au petites machines de le lever et la tesselation permet aux grosses machines, qui lèvent le même modèle 3D d’une main en se grattant le nez de l’autre, d’utiliser cette seconde main pour affiner le tout.

Tel que je le vois ça permet plus ou moins de ménager le choux et la chèvre :

le jeu passe sur un éventail plus grand de machines (marché mieux exploité) et les plus grosses bécanes affichent malgré tout des modèle détaillés.

Maintenant comme je l’ai dit ce n’est pas du tout mon domaine donc je peux tout aussi bien me faire un film et raconter de grosses âneries. " />

Leezi

Le 22/02/2013 à 15h04

Takaï a écrit :

Navré d’avoir posé la question mais le forum officiel m’est inaccessible. (proxy du boulot à tendance paranoïaque toussa… " />)

Ah ?! Toi aussi " />

sylware a écrit :

Faudrait des chiffres, car sinon autant laisser les 3D designers ajouter les polygones là où ils vont bien.

Aucune allusion à la poitrine de Lara ?

" />

TheSlider

Le 22/02/2013 à 15h07

Eidos, c’est l’éditeur c’est bien ça ?

Takaï

Le 22/02/2013 à 15h07

Leezi a écrit :

Ah ?! Toi aussi " />

Ouai entre la pléthore de sites bloqués et le quotas de 250Mo hebdomadaire (que j’explose allégrement chaque semaine XD), je suis servi. " />

Anonyme

Le 22/02/2013 à 15h08

Edtech a écrit :

La tesselation ne fait pas un bête ajout de polygone au hasard ! C’est directement indiqué dans le modèle comment la tesselation doit s’appliquer. C’est donc exactement comme si le designer l’avait fait lui-même !

Et même si c’était le cas, les algos sont déjà très performants et omniprésents dans le pré-calculé.

Wikipedia

Toorist

Le 22/02/2013 à 15h09

<3 merci Eidos (dans tout les cas la version collector était déjà commandée depuis belle lurette " /> )

snoopy1492

Le 22/02/2013 à 15h09

TheSlider a écrit :

Eidos, c’est l’éditeur c’est bien ça ?

Oui c’est Crystal Dynamics le dev ;)

John Shaft

Le 22/02/2013 à 15h12

Edtech a écrit :

Par contre, il faudra m’expliquer pourquoi dans Batman AC, les visages sont nickels mais les épaules toutes carrées…

Bin je crois que tu as toi-même donné la réponse à cette question dans ton post " />" />

Ellierys

Le 22/02/2013 à 15h17

TheSlider a écrit :

Eidos, c’est l’éditeur c’est bien ça ?

C’est square Enix l’éditeur.

Crystal Dynamics a bossé sur le multi, et Eidos sur le solo… ou l’inverse

trash54

Le 22/02/2013 à 15h18

Leezi a écrit :

Aucune allusion à la poitrine de Lara ?

" />

" /> les souvenirs de Tomb Raider 1" /> " />

Anonyme

Le 22/02/2013 à 15h19

SrBelial a écrit :

Moi j’en vois surtout un autre : réduire le besoin d’utiliser des modèles multirés.

Il n’y a pas que l’ajout de polygones par interpolation, j’ose espérer que leur moteur d’affichage contient également de la simplification des géométries en fonction de la distance dans le frustum (ça y est j’ai placé un terme technique bien pourri)

Le plus grand intérêt serait dans le cas inverse alors? Abaisser le nombre de polygones par interpolation matérielle quand le LOD (Level Of Detail) nécessaire baisse par l’éloignement du modèle 3d.

D’un point de vu technique cela signifierait que les besoins pour le transfère des vertex/primitives restent les mêmes, et sachant que la tesselation ne concerne par les polygones, les textures conserveraient leur qualité (mais seraient samplées nettement moins du au nombre de polygones inférieur).

Par contre interpoler “vers” le bas, signifie qu’il faut plusieurs polygones pour le faire (on va de N polygones vers moins de N), et donc exploiter cette tesselation ne doit pas être “out of the box” et imposer des contraintes aux modèles 3D.

Je me doute bien que ces contraintes, si elles existent doivent être moins lourdes à mettre en œuvre pour le designer 3D… par contre si les contraintes se démultiplient pour chaque gamme de GPUs. c’est perdu car il sera plus intéressant que le designer se coltine un seul modèle pour un LOD qu’un modèle haute résolution pour chaque moteur de tesselation matériel qui existe.

On en retombe bien sur le côté discutable du coût silicium de cette tesselation matérielle.

Y répondre nécessite une analyse sacrément fine, mais la perspective des gains de boulot pour le designer 3D est diablement intéressante… donc ça vaut vraiment le coup d’y regarder de plus près.

Qui s’y colle? " />

JohnCaffey

Le 22/02/2013 à 15h29

Ah ben, je pourrais y jouer sur mon vieux MSI GX 720, cool ! Ça me coûtera moins cher que de l’acheter sur PS3. " />

Et Lara sort quand que je puisse la pécho ? " />

azedrummer

Le 22/02/2013 à 15h34

sylware a écrit :

Le tesselation, ou comment rajouter des polygones par interpolation.

Les économies de bandes passantes du bus sur les données des vertex/primitives sont si intereressantes que ça?? (GROS DOUTES)

Faudrait des chiffres, car sinon autant laisser les 3D designers ajouter les polygones là où ils vont bien.

oui quand même, la tesselation permet de générer des centaines des milliers de polygones (des triangles en l’occurrence) rapidement. Stocker chacun de ces triangles (leur vertices en fait) en mémoire centrale serait très lourd, par exemple, en supposant qu’il faille juste stocker leur position 3D (c’est pas le cas en vrai mais simplifions) avec chaque coordonnée (x, y ,z) sur un flottant de 4 octets, cela représente 36 octets par triangle dans le pire des cas, soit 34,33 Mo pour un modèle d’un million de triangle. En affichant au bas mot 100 modèles 3d avec autant de triangles, il faut 3.43 Go de mémoire…. et je suis gentil avec 100 modèles, une scène 3d moderne en affiche bien plus à l’écran, et tout ça au moins 30 fois par seconde…. je te laisse imaginer la bande passante monstrueuse qu’il faudrait :) sans parler des unités de calcul nécessaire pour effectuer tous les calculs liés à ces vertices, etc. Bref aujourd’hui, il est plus rentable en terme de ressources CPU/GPU/Mémoire de calculer à la volée des millions de triangles avec des unités dédiées (tesselation) plutôt que de les stocker et les envoyer bêtement à travers le bus qui relie cpu et gpu

azedrummer

Le 22/02/2013 à 15h36

bombo a écrit :

Et puis rajouter tout plein de polygones à la main, c’est peut être juste méga fastidieux et onéreux ? :-)

Même pas puisque les modélisateurs travaillent sur des modèles dits “high poly”, autrement avec à taquet de polygones, et ils génèrent après des versions “low poly” + normal map et cie pour être utilisables en jeux. En gros, les high poly permettent de modéliser les détails qui seront retranscrits sur des textures afin de créer un leurre à l’écran avec des normal map, du parralax mapping, tesselation et tout ce qu’on peux imaginer :)

Anonyme

Le 22/02/2013 à 15h41

Edtech a écrit :

La tesselation ne fait pas un bête ajout de polygone au hasard ! C’est directement indiqué dans le modèle comment la tesselation doit s’appliquer. C’est donc exactement comme si le designer l’avait fait lui-même !.

Ah? Donc ça voudrait dire que le modèle 3D doit être enrichi de “meta” data d’interpolation à la modélisation? Genre des paramètres de courbes mathématiques bien connues (Je regarde wikipédia sur les algos de tesselation “interpolants” et “approximants”). Perso, ça veut dire que le designer 3D va devoir monter en compétences pour être capable de maîtriser ces outils mathématiques qui semblent nettement plus pointues que la 3D polygonale classique.

Oulala… c’est de plus en plus acrobatique!

Est-ce que le boulot des designers 3D à monter en compétences/expérience sur la tesselation économisera les modèles 3D supplémentaires nécessaires au LOD et au dimensionnement du au GPU? On peut parier que chaque GPU à sa façon de faire de la tesselation matérielle, ce qui n’arrangerait rien, car les paramètres de tesselation devraient être démultiplier par le nombre de GPU (vieux, courants ou pas encore sortis?)

Donc re… la perspective des gains de charge de boulot pour les designers 3D seraient tels qu’il faut vraiment faire une étude poussée, très poussée! Car si au final le gain est proche de rien dans la pratique, autant réutiliser ce silicium pour des compute units supplémentaires.

Ellierys

Le 22/02/2013 à 16h24

TheRarePearl a écrit :

La Radeon HD 4870 s’arrête à Direct X 10.1, non?

Tout a fait, et l’explication d’Eidos se trouve dans l’article…

John Shaft

Le 22/02/2013 à 16h28

Jean_Peuplus a écrit :

Eh bé vous êtes chaud dans la technique pour un Vendredi soir " />

Ellierys a écrit :

Je m’attendais à ce que ça parle de boobs et que ça trolle sur les DRM de Diablo III " />

Oui. Si on parlait de Surface Subdivision et de tesselation sur les boobs de Lara ? " />

Ou encore, on pourrait parler du dernier patch de Dead or Alive 5 qui comprend une option pour bouger les boobs des filles du cast avec le SixSense (rebaptisé SixSein du coup) " />" />

Zenedore

Le 22/02/2013 à 16h37

une video montrant les effets de la tesselation avec différents moteurs

le gain est surtout visible sur les objets “ronds”

YouTube

Anonyme

Le 22/02/2013 à 16h38

azedrummer a écrit :

Oui… et non ! ça marche dans les deux sens : les moteurs de jeux s’adaptent aux architectures GPU existantes pour en tirer le meilleur. Les drivers arrivent derrière pour optimiser ce qui l’a déjà été, c’est à dire qu’ils viennent optimiser leurs calculs en fonction de la façon dont les moteurs de jeux utilisent les GPU .Par exemple, l’UE4 et le CE3 n’utilisent pas le même code et par conséquent n’utilisent pas les mêmes optimisations au niveau du GPU, les drivers spécifiques permettent de pousser plus loin cette optimisation en d’adaptant au fonctionnement de chaque moteur.

C’est effectivement un constat. Je le perçois comme une forme d’échec d’opengl et de directx, qui ne sont maintenant que des couches de compatibilité, le “fall back” (ce qui ne veut pas dire que ça marche mal et que c’est pas beau)

Là où ça fait le plus mal, c’est qu’opengl n’expose pas une interface suffisamment bas niveau (plus simple et fine, mais plus bourrine) pour éviter que les drivers soient carrément optimisés (avec tous les problèmes que ça implique). Mais d’un autre côté, quand on voit que les instructions machines des GPUs vont jusqu’au contrôle fin des mémoires cache… instructions qui semblent nettement plus expressives que les instructions machines des CPUs… les compilos glsl peuvent crever pour optimiser une telle finesse (en tout cas c’est l’impression que ça me donne).

Anonyme

Le 22/02/2013 à 17h00

Zenedore a écrit :

une video montrant les effets de la tesselation avec différents moteurs

le gain est surtout visible sur les objets “ronds”

YouTube" />

cf les postes précédents où je met en garde contre les “démos” qui sont “taillées” pour vendre la tesselation…

Et l’échange qu’on a eu cette après-midi sur le sujet démontre mien que c’est un domaine bien plus sophistiqué qu’il n’y paraît…

Zenedore

Le 22/02/2013 à 17h12

sylware a écrit :

" />

cf les postes précédents où je met en garde contre les “démos” qui sont “taillées” pour vendre la tesselation…

Et l’échange qu’on a eu cette après-midi sur le sujet démontre mien que c’est un domaine bien plus sophistiqué qu’il n’y paraît…

Si tu as la machine qu’il faut et des jeux directx11, tu peux faire la comparaison toi même, il y a certes une perte de framerate, mais minime par rapport a ce que tu aurais comme chute sans la tesselation mais avec le même nombre de polygones.

Tohrnoriac

Le 22/02/2013 à 17h12

ben moi qui pensait que mon Q9400 et ma 4870 allaient etre a la ramasse… ah ben non, cool :)

Anonyme

Le 22/02/2013 à 17h31

Zenedore a écrit :

Si tu as la machine qu’il faut et des jeux directx11, tu peux faire la comparaison toi même, il y a certes une perte de framerate, mais minime par rapport a ce que tu aurais comme chute sans la tesselation mais avec le même nombre de polygones.

Il me semble dans la démo, on voit du 217 fps qui passe à 67 fps voir d’autres…

Mais je viens de regarder quelques vidéos… la killer feature de la tesselation (montante en nombre de polygones) serait l’affinement significatif de l’effet des map d’interpolation de positions des vertex d’un poly selon les normales (si j’ai bien tout compris… ce dont je doute très fortement). En gros, les reliefs dans ces maps seraient beaucoup plus appuyés et nets. Mais dans ces demos, c’est tranché: “scene intended for hardware tesselation”. En gros pas de tesselation, rendu dégradé voir pourri par rapport à ce que voulait le designer 3D…

Zenedore

Le 22/02/2013 à 17h44

sylware a écrit :

… En gros, les reliefs dans ces maps seraient beaucoup plus appuyés et nets. Mais dans ces demos, c’est tranché: “scene intended for hardware tesselation”. En gros pas de tesselation, rendu dégradé voir pourri par rapport à ce que voulait le designer 3D…

La technologie n’existe pas encore pour rendre en temps réel ce que voudrait un designer 3D.

il ne faut pas oublier que les 3D est faite d’artifice pour palier le manque de puissance, la tesselation en fait partie (bump map, normale map, shader, etc )

Si on avait la puissance, on aurait des modèles HD et rendu en raytracing " />

Anonyme

Le 22/02/2013 à 17h45

sylware a écrit :

Il me semble dans la démo, on voit du 217 fps qui passe à 67 fps voir d’autres…

Mais je viens de regarder quelques vidéos… la killer feature de la tesselation (montante en nombre de polygones) serait l’affinement significatif de l’effet des map d’interpolation de positions des vertex d’un poly selon les normales (si j’ai bien tout compris… ce dont je doute très fortement). En gros, les reliefs dans ces maps seraient beaucoup plus appuyés et nets. Mais dans ces demos, c’est tranché: “scene intended for hardware tesselation”. En gros pas de tesselation, rendu dégradé voir pourri par rapport à ce que voulait le designer 3D…

En gros c’est très convainquant en qualité de rendu… tant que les vertex shaders peuvent accéder à fonds les ballons à ces maps d’interpolation, qui par définition seront costoes à cause de leur finesse. D’ailleurs c’est pas ce qu’utilise l’ID5 de Carmack avec ses gigas maps?

Jonathan Livingston Abonné

Le 22/02/2013 à 17h46

Zenedore a écrit :

une video montrant les effets de la tesselation avec différents moteurs

le gain est surtout visible sur les objets “ronds”

YouTubeEn même temps, ajouter des polygones sur du plat…

Reparateur

Le 22/02/2013 à 17h50

sylware a écrit :

C’est le niveau de détail du jeu (les curseurs) qui est supposé définir le nombre de polygones.

Personnellement, je me sens nettement plus à l’aise (c peut-être infondé) avec des polygones ajoutés là où il faut par un designer 3D qu’interpolés un peu magiquement par le GPU…. ahem… la question mérite d’être sérieusement tournée dans tous les sens, car je me doute bien que la tesselation n’est certainement pas donné en “coût silicium”.

On va me dire “mais y a des ingénieurs qui ont super réfléchi au bouzin et blablabla…”. D’expérience y a surtout beaucoup d’ingénieurs qui subissent les caprices du marketing.

Et attention aux benchmarks qui sont conçus pour mettre en valeur au mieux l’intelligence d’interpolation du silicium… qui sera loin de marcher bien dans tous les cas de figure.

je suis daccord avec toi

je dirais même que la tesselation à l’air d’être un truc inutile

quand ATI à sorti ça au début c’était pour améliorer les jeux déjà existant genre counter strike

sauf que bon ça n’a jamais percé car généralement les poly sont ajouté n’importe comment

je pense que l’avantage c’est le coté dynamique du truc suivant la charge GPU la distance de vue etc

mais dans tout les cas le dev doit surement ce taper tout les modèle poly à la main avant si il ne veut pas un résultat absurde à la fin

en fait l’avantage c’est la diminution des détail et non l’inverse

tu fait un truc high poly et la tesselation se charge de réduire les détail quand ils sont pas nécessaires

mais bon certain moteur savais déjà faire ça sans la tesselation

juste ça doit être plus facile à implémenter maintenant

bref à l’heure actuel j’ai surtout l’impression que c’est du pipo marketing pour activer le mode non dégradé du rendu des poly

Anonyme

Le 22/02/2013 à 18h00

Reparateur a écrit :

sauf que bon ça n’a jamais percé car généralement les poly sont ajouté n’importe comment

je pense que l’avantage c’est le coté dynamique du truc suivant la charge GPU la distance de vue etc

mais dans tout les cas le dev doit surement ce taper tout les modèle poly à la main avant si il ne veut pas un résultat absurde à la fin

en fait l’avantage c’est la diminution des détail et non l’inverse

tu fait un truc high poly et la tesselation se charge de réduire les détail quand ils sont pas nécessaires

mais bon certain moteur savais déjà faire ça sans la tesselation

juste ça doit être plus facile à implémenter maintenant

bref à l’heure actuel j’ai surtout l’impression que c’est du pipo marketing pour activer le mode non dégradé du rendu des poly

Bin voilà… ça résume un peu tout en un peu plus direct sur la forme.

Le truc, c’est que si les polygones ne sont pas placés trop n’importe comment et que c’est fiable dans quasiment tous les cas de figures, avec des maps de relief fines au niveau des vertex shaders, ça en jète, et tout ça sans CPU et au GPU.

Donc prudence et tests vont de mise…

Berillions

Le 23/02/2013 à 06h47

Moi qui hésitais à l’acheter… Vu que XP est supporté, le jeu sera mien.

XP + Dx9 = Linux/Wine " />

chikenkilr

Le 23/02/2013 à 07h59

la 4870 n’est techniquement pas une carte DirectX11 mais elle supporte la tesselation, donc la recommander pour ses performances est logique

Ah bon, avec ma 4870 sous Win7, dans les benchs/jeux avec tesselation, l’option est toujours grisée chez moi.

Ou alors leur jeu sera plus intelligent et saura proposer la tesselation avec un 4870 sans que les perfs s’ecroulent?

josagama

Le 23/02/2013 à 12h24

Une utilisation raisonnable des DRM

Ils ont peur que je jeu plante a chaque utilisation comme à une époque Sony avec ses CD qui ne pouvaient meme pas etres lu dans une platine de chaine HIFI " />

azedrummer

Le 22/02/2013 à 15h48

sylware a écrit :

Ah? Donc ça voudrait dire que le modèle 3D doit être enrichi de “meta” data d’interpolation à la modélisation? Genre des paramètres de courbes mathématiques bien connues (Je regarde wikipédia sur les algos de tesselation “interpolants” et “approximants”). Perso, ça veut dire que le designer 3D va devoir monter en compétences pour être capable de maîtriser ces outils mathématiques qui semblent nettement plus pointues que la 3D polygonale classique.

Oulala… c’est de plus en plus acrobatique!

Est-ce que le boulot des designers 3D à monter en compétences/expérience sur la tesselation économisera les modèles 3D supplémentaires nécessaires au LOD et au dimensionnement du au GPU? On peut parier que chaque GPU à sa façon de faire de la tesselation matérielle, ce qui n’arrangerait rien, car les paramètres de tesselation devraient être démultiplier par le nombre de GPU (vieux, courants ou pas encore sortis?)

Donc re… la perspective des gains de charge de boulot pour les designers 3D seraient tels qu’il faut vraiment faire une étude poussée, très poussée! Car si au final le gain est proche de rien dans la pratique, autant réutiliser ce silicium pour des compute units supplémentaires.

Le designer 3D n’a pas forcément besoin de monter en compétence, quand un designer travaille pour un grand compte du jeu vidéo, c’est que c’est pas le dernier venu :). En plus, la tessellasstion apparaît aujourd’hui dans nos jeux vidéos parce que les API de dev (comprendre par là DX et OpenGL) et les cartes graphiques le permettent, mais c’était déjà utilisé dans les films de synthèse. J’imagine aussi que leurs outils de modélisations sont adaptés pour ce genre de choses.

Pour ce qui est des GPU, ils ont probablement chacun leur façon de faire, mais ils font la même chose et se programment de la même manière (à peu de choses près). En gros (pour simplifier), c’est les mêmes lignes de codes, peu importe le GPU

Anonyme

Le 22/02/2013 à 15h53

azedrummer a écrit :

…

cf nos posts précédents.

Tu parles de tesselation “montante” et des gains du bande passante sur le bus.

Dans les posts précédents, c’est justement ça qu’il faudrait regarder de bien plus près. Car le profile de charge d’un GPU est compliqué (c’est pas du streaming vidéo quoi).

Donc, dans le plan technique et la tesselation “montante” (vers plus de polygons), la question est:

Est-ce que le gain visuel dans la majorité des cas de figure (pas les benchmarks faits pour que justement ça marche au mieux) est significatif grâce à cette réduction de pression sur le bus mémoire?

Je ne parle pas d’estimation grossière à priori, car comme je l’ai dit, c’est pas du streaming video, mais d’analyse fine et concrète (de terrain).

azedrummer a écrit :

…

Pour ta réponse précédente… le code générique ne suffit plus, sinon on n’aurait pas des news en permanence sur les optimisations des drivers spécifiques pour certains jeux…

Toorist

Le 22/02/2013 à 15h58

azedrummer a écrit :

[…] parce que les API de dev (comprendre par là DX et OpenGL) […]

Juste pour faire mon relou, directX est plus un Framework qu’une API " />

A part ca rien a rajouter, moi les modèles j’les utilise je sais pas les faire " /> (chaqu’un son taff merde ! " /> )

Anonyme

Le 22/02/2013 à 16h04

Toorist a écrit :

Juste pour faire mon relou, directX est plus un Framework qu’une API " />

A part ca rien a rajouter, moi les modèles j’les utilise je sais pas les faire " /> (chaqu’un son taff merde ! " /> )

Le “framework” (" />) pour opengl c’est là:http://www.khronos.org/

SrBelial

Le 22/02/2013 à 16h05

sylware a écrit :

Ah? Donc ça voudrait dire que le modèle 3D doit être enrichi de “meta” data d’interpolation à la modélisation? Genre des paramètres de courbes mathématiques bien connues (Je regarde wikipédia sur les algos de tesselation “interpolants” et “approximants”). Perso, ça veut dire que le designer 3D va devoir monter en compétences pour être capable de maîtriser ces outils mathématiques qui semblent nettement plus pointues que la 3D polygonale classique.

Oulala… c’est de plus en plus acrobatique!

Est-ce que le boulot des designers 3D à monter en compétences/expérience sur la tesselation économisera les modèles 3D supplémentaires nécessaires au LOD et au dimensionnement du au GPU? On peut parier que chaque GPU à sa façon de faire de la tesselation matérielle, ce qui n’arrangerait rien, car les paramètres de tesselation devraient être démultiplier par le nombre de GPU (vieux, courants ou pas encore sortis?)

Donc re… la perspective des gains de charge de boulot pour les designers 3D seraient tels qu’il faut vraiment faire une étude poussée, très poussée! Car si au final le gain est proche de rien dans la pratique, autant réutiliser ce silicium pour des compute units supplémentaires.

Souvent les information nécessaires sont issues d’un modèle très haute résolution (un nombre de polygones indécent) qui est ensuite appliqué à un autre modèle, plus économe en polygones. Ce genre d’informations peut être stocké dans une texture ou une pseudo texture, d’une façon un peu similaire au stockage des éclairages précalculés : au lieu de stocker une couleur dans un pixel d’une texture on peut y stocker un éclairage, un vecteur normal au plan “théorique”, etc …

ne pas oublier que le rendu 3D c’est avant tout de l’illusion " /> avec les bon shaders, les bon calculs, les bonnes textures, on pourrait presque modéliser un cube et donner l’impression lors du rendu qu’il s’agit d’une sphère.

en l’occurence, on laisse la main à des artistes, qui même s’ils ne maitrisent pas la théorie, savent l’appliquer pour obtenir le résultat qu’ils veulent. pas besoin de transformer les graphistes en mathématiciens " />

Jean_Peuplus

Le 22/02/2013 à 16h11

Eh bé vous êtes chaud dans la technique pour un Vendredi soir " />

Khalev

Le 22/02/2013 à 16h11

sylware a écrit :

Pour ta réponse précédente… le code générique ne suffit plus, sinon on n’aurait pas des news en permanence sur les optimisations des drivers spécifiques pour certains jeux…

Sauf que se sont les drivers qui s’adaptent, pas les jeux, et donc le code devient générique. Ce que tu dis c’est un peu comme dire que le html ne suffit plus puisque la norme évolue pour s’adapter aux usages.

Après pour a décision de la tesselation, il faut aussi voir l’état du parc de PCs.

La différence entre le PC moyen et le PC puissant est assez énorme. Niveau GPU on passe d’une CG moyen/haut de gamme à une double CG haut de gamme (tu vas pas faire du SLI sur 2 cartes médiocre, ça vaut pas le coût).

Et c’est pareil pour les CPU, la ram,… en général tu as un trou vide de configs entre la config moyenne et la config haut de gamme.

En gros les PC qui vont utiliser la tesselation sont “beaucoup” plus puissant que le PC moyen. La puissance de calcul ils l’ont déjà.

Mais la cible d’un dev de jeux vidéos c’est le plus grand nombre c’est à dire le PC “moyen”, pour lequel il faut une expérience optimisée.

Tu vas pas donner à ce PC moyen des textures trop détaillés qu’il ne pourra pas gérer, qui vont saturer ses bus et qui vont en plus lui demander des calculs supplémentaires. Le pauvre il est déjà limite, on va pas en plus le punir pour ça.

A moins de proposer des textures pour chaque config possibles, il vaut mieux proposer une texture “moyenne”, des moyens de l’optimiser, puis permettre de paramétrer le niveau de détail en fonction de la puissance de la machine.

Ellierys

Le 22/02/2013 à 16h12

Jean_Peuplus a écrit :

Eh bé vous êtes chaud dans la technique pour un Vendredi soir " />

Je m’attendais à ce que ça parle de boobs et que ça trolle sur les DRM de Diablo III " />

azedrummer

Le 22/02/2013 à 16h12

sylware a écrit :

…

Le gain visuel est subjectif et surtout dépendant de ce que feront les dev et les designer des ressources gagnées :). T’as beau économisé toutes les ressources matérielles que tu veux, si tu fais des modèles moches ben… ce sera moche.

Mais dans la théorie, les ressources que ça peut libèrer niveau BP, unités de calcul GPU, CPU, mémoire GPU et centrale peuvent être (et de mon point de vue doivent être) utilisées pour enrichir graphiquement le jeu avec de nouveaux effets, plus de variétés à l’écran ,etc… Mais ça reste de la théorie ;). Dans la pratique, on peut raisonnablement penser que les studios trouvent de bon compromis entre l’optimisation et les coûts qui y sont liés.

Effectivement, le code générique ne suffit plus, mais à peu de choses près on retrouvent les mêmes lignes de code (dans le meilleur des cas, on trouve des shaders compilés suivant ta configuration et ce que ta CG est capable de faire, dans le pire des cas c’est la même chose pour tout le monde).

Edtech Abonné

Le 22/02/2013 à 16h13

Il me semble que justement, ce n’est pas le designer qui donne les infos de tesselation directement. Comme dit par d’autres, il bosse sur un modèle sur-polygonné. Et c’est le logiciel qui ensuite garde les informations de ce modèle en les transformant en données de tesselation.

Je vois mal un graphisme faire de la géométrie à très haut niveau " />

Khalev

Le 22/02/2013 à 16h14

Ellierys a écrit :

Je m’attendais à ce que ça parle de boobs et que ça trolle sur les DRM de Diablo III " />

Comme quoi, on peut avoir de bonnes surprises sur PCI :)

Ceci dit moi Lara, tesselation ou pas, je lui rajouterai bien des polygones là ou je pense.

(Faut bien faire redescendre le niveau)

pandaroux

Le 22/02/2013 à 16h15

pafLaXe a écrit :

Je pense pas que ça soit facultatif.

Ben si, c’est comme les jeux des humble bundle.

Tu as payé le jeu, tu l’actives sur steam juste pour profiter des avantages de la plateforme (achievements, mise à jours…).

Il parle d’un code d’activation pour la version CD, donc moi je vois plutôt ça comme ça, en regardant ce qui s’est déjà fait.

Sinon je vois pas l’intérêt de ne pas l’acheter directement en dématérialisé.

Et je vois pas Steam faire un système automatisé comme ça avec des boites CDs. On est plus sur CS1.6.

Anonyme

Le 22/02/2013 à 16h18

pandaroux a écrit :

Ben si, c’est comme les jeux des humble bundle.

Tu as payé le jeu, tu l’actives sur steam juste pour profiter des avantages de la plateforme (achievements, mise à jours…).

Il parle d’un code d’activation pour la version CD, donc moi je vois plutôt ça comme ça, en regardant ce qui s’est déjà fait.

Sinon je vois pas l’intérêt de ne pas l’acheter directement en dématérialisé.

Et je vois pas Steam faire un système automatisé comme ça avec des boites CDs. On est plus sur CS1.6.

Le dernier Deus-EX (Eidos également) ne fonctionne pas sans Steam, même en version boite.

Khalev a écrit :

Comme quoi, on peut avoir de bonnes surprises sur PCI :)

Ceci dit moi Lara, tesselation ou pas, je lui rajouterai bien des polygones là ou je pense.

(Faut bien faire redescendre le niveau)

Tu veux matter sous sa normal map ? :bave:

azedrummer

Le 22/02/2013 à 16h18

Khalev a écrit :

Sauf que se sont les drivers qui s’adaptent, pas les jeux, et donc le code devient générique. Ce que tu dis c’est un peu comme dire que le html ne suffit plus puisque la norme évolue pour s’adapter aux usages.

Oui… et non ! ça marche dans les deux sens : les moteurs de jeux s’adaptent aux architectures GPU existantes pour en tirer le meilleur. Les drivers arrivent derrière pour optimiser ce qui l’a déjà été, c’est à dire qu’ils viennent optimiser leurs calculs en fonction de la façon dont les moteurs de jeux utilisent les GPU .Par exemple, l’UE4 et le CE3 n’utilisent pas le même code et par conséquent n’utilisent pas les mêmes optimisations au niveau du GPU, les drivers spécifiques permettent de pousser plus loin cette optimisation en d’adaptant au fonctionnement de chaque moteur.

Mithiriath Abonné

Le 22/02/2013 à 16h21

Carte graphique compatible Direct X 11 avec 1 Go de RAM: AMD Radeon HD 4870, nVidia GTX 480

La Radeon HD 4870 s’arrête à Direct X 10.1, non?

Anonyme

Le 22/02/2013 à 16h22

SrBelial a écrit :

Souvent les information nécessaires sont issues d’un modèle très haute résolution (un nombre de polygones indécent) qui est ensuite appliqué à un autre modèle, plus économe en polygones. Ce genre d’informations peut être stocké dans une texture ou une pseudo texture, d’une façon un peu similaire au stockage des éclairages précalculés : au lieu de stocker une couleur dans un pixel d’une texture on peut y stocker un éclairage, un vecteur normal au plan “théorique”, etc …

ne pas oublier que le rendu 3D c’est avant tout de l’illusion " /> avec les bon shaders, les bon calculs, les bonnes textures, on pourrait presque modéliser un cube et donner l’impression lors du rendu qu’il s’agit d’une sphère.

Yope, ça me fait penser au studio où ils ont dev God Of War III (santa monica?). Le pipeline de design graphique avait 3 étages: le premier=les designers 3D de base, le second=les designers 3D avec compétences techniques avancées, et le dernier=les codeurs.

SrBelial a écrit :

en l’occurence, on laisse la main à des artistes, qui même s’ils ne maitrisent pas la théorie, savent l’appliquer pour obtenir le résultat qu’ils veulent. pas besoin de transformer les graphistes en mathématiciens " />

Certes… mais est-ce qu’il y a réellement un gain visuel et/ou en charge de travail?

Pour les gain de charge de travail: designer 3D pour la conception de différents modèles avec un nombre différents de polygones (j’imagine que pour la tesselation “descendante” y a des super outils pour accélérer le boulot) au profit du programmeur du moteur 3D qui a nettement moins de boulot à faire sur le LOD et la gestion de puissance des GPUs (ce que nintendo évite avec un seul hardware pour ses jeux " />).