FF XV sort dans moins d'un mois et demi sur PC WINDOWS. Pour la sortie console, les joueurs avaient eu droit à une démo. Les PCistes devront se contenter d'un benchmark pour voir comment le jeu de Square tourne sur leur chère bécane.

Au final, la config requise est loin d'être délirante si on excepte les 100 Go d'espace disque requis pour la version normale. Cela monte même à 155 Go si on veut les textures haute résolution. La version PC comportera tous les DLC sortis, toutes les mises à jour et sortira le 6 mars sur Steam, Origin et Windows Store.

Lire la suite sur le site : Un outil de mesure pour Fantaisie Finale Quinze : édition Fenêtres..

Le windows au lieu de PC, c'est pour éviter que les linuxiens ramènent leur fraise ?
Sinon, si c'est 155Go le benchmark, ce sera sans moi. (edit : 155Go, c'est pour le jeu complet mais le benchmark pèse quand même ses 3,4Go)

Le bench fait 4 Go. 100/155 Go c'est pour le jeu.

"windows store"

C'est quoi ? :)

Vivement les disques durs FF XV ! j'ai du sel dans mes mots avec ma connexion à 1.3 Mbit/s. seulement 11 jours 24/24. Vive les jeux indés à moins d'un 1 Go.
quand je pense qu'Edith Finch fait moins de 3 Go ou Dragon Ball FighterZ moins de 5, etc... ça fait réfléchir. Qui peut répondre en tant que programmeur ?

Ptet que l'optimisation est pas au poil, mais aussi d'un autre côté c'est un FF, y'a des masses de textures et de modèles, c'est pas vraiment comparable avec un edith finch ou un jeu de baston...

Sinon dommage mais vu que FF12 vient de sortir sur steam je sais lequel je me paierai en premier.

Dans le temps, les artistes optimisaient à fond les textures et leur utilisation. On arrivait à ce genre de résultat.

Mais le manque de temps et la complexité des projets a fait que Substance Painter et la photogrammetry sont devenus rois. Tu peux texturer des objets super vite et avec un r♪0sultatr épatant. Mais du coup c'est limite si chaque object n'a pas sa texture unique.

Aussi pour des raisons de perfomances, on utilise des modeles 3D low poly et on compense avec trente-six couches de textures: normal/displacement map, une specular map, une AO map,...

CBL a écrit :

...Tu peux texturer des objets super vite et avec un résultat épatant. Mais du coup c'est limite si chaque object n'a pas sa texture unique.

Aussi pour des raisons de perfomances, on utilise des modeles 3D low poly et on compense avec trente-six couches de textures: normal/displacement map, une specular map, une AO map,...

merci, on en demandait pas temps niveau textures mais il n'y aurait pas s'autre solutions que d'appliquer une quinzaine de couches de shaders ?
au delà du jeu, il est certes beau mais ne pèse t-il pas 45 Go (je n'ai pas trop confirmé mes sources) sur PS4 ? pourquoi l'alourdir à ce point alors q'un framerate 30/60 fps suffirait sur PC ?
nous devrions avoir le choix et comme cela ça nous économiserait de la bande passante. Par exemple, les textures Hi-res de Fallout 4 sont très Lol par rapport au résultat final.
C'est con mes questions car au final (Fantasy), je m'en fiche un peu de ce jeu.

Ça préfigure la taille que prendront les AAA dans 4-5ans quand même, va falloir changer les DD de 1 ou 2To...

Ils ont intérêt à développer d'ici là la fibre dans nos campagnes, sinon ça va gueuler...

ignatius, compare ce qui est comparable, genre GTAV console VS PC Windows. (et j’imagine qu'il doit y'avoir masse de MàJ sur FF PS4)
Et ne parle plus JAMAIS d'Edith Finch, ou tu finiras comme sa famille, électrocuté par ton grille pain, ou la tête coincée dans une grille d'arbre.

CBL a écrit :
Dans le temps, les artistes optimisaient à fond les textures et leur utilisation. On arrivait à ce genre de résultat.

Héhé énorme que tu aies posté ça, j'y pensais justement :) Son breakdown sur Polycount est assez instructif.

Pour en revenir sur le besoin d'espace disque du à la memoire, meshes.. Comme dit plus haut c'est un gloubigoulba de plusieurs paramètres.
Si je devais faire un raccourcis, bien que les CG soient de plus en plus puissantes et les moteurs 3D riches, y aura toujours le facteur humain.
Le moteur va devoir etre scalable selon la plateforme et meme selon les outils/ressources dispo en interne.
Il est plus simple actuellement de scaler une texture que de scaler une mesh avec tout ce que cela implique (retravailler un peu les UV) quoique l'UE4 possede un process de LOD assez efficace. Le tiling est une excellente mais necéssite tjs du temps et de l'organisation.
Une 1ere solution serait de s'éloigner du rendu "realiste" ce qui permettrait plus d'économies (cf. HW2 avec son combo low texture et vertex painting pour les background).
Un autre serait d'inventer un nouvel algo miracle de packtage/décompression de textures ou de switcher vers du SVG.... Mais à ma connaissance, à mon petit niveau, aucun moteur 3D ne le fait vraiment manière complexe ( faut pas s'attendre a des trucs fins).
-> http://www.valvesoftware.com/publications/2007/SIGGRAPH2007_AlphaTestedMagnification.pdf

Tonolito_ a écrit :
Un autre serait d'inventer un nouvel algo miracle de packtage/décompression de textures ou de switcher vers du SVG.... Mais à ma connaissance, à mon petit niveau, aucun moteur 3D ne le fait vraiment manière complexe ( faut pas s'attendre a des trucs fins).
-> http://www.valvesoftware.com/publications/2007/SIGGRAPH2007_AlphaTestedMagnification.pdf

Un peu ce que fait Allegorithmic quoi ?
Sauf que l'espace de stockage reste toujours moins cher que la décompression de taré en mémoire (et oui convertir des maths en bitmap ça pompe pas mal)...
Bref... le future c'est le déporté... mais ouais faudrait se bouger pour la fibre quoi.

Et ouais les distance field c'est pas mal intéressant... y'a des cas technologiques ou ça pourrait bien remplacer tout le workflow.. le seul soucis c'est que l'output c'est toujours du bitmap

BeatKitano a écrit :

Tonolito_ a écrit :
Un autre serait d'inventer un nouvel algo miracle de packtage/décompression de textures ou de switcher vers du SVG.... Mais à ma connaissance, à mon petit niveau, aucun moteur 3D ne le fait vraiment manière complexe ( faut pas s'attendre a des trucs fins).
-> http://www.valvesoftware.com/publications/2007/SIGGRAPH2007_AlphaTestedMagnification.pdf

Un peu ce que fait Allegorithmic quoi ?
Sauf que l'espace de stockage reste toujours moins cher que la décompression de taré en mémoire (et oui convertir des maths en bitmap ça pompe pas mal)...
Bref... le future c'est le déporté... mais ouais faudrait se bouger pour la fibre quoi.

Et ouais les distance field c'est pas mal intéressant... y'a des cas technologiques ou ça pourrait bien remplacer tout le workflow.. le seul soucis c'est que l'output c'est toujours du bitmap

Oui comme tu dis, en finalité on a toujours un bitmap.
Cependant y a pas mal de recherches ces derniers temps grace aux dernieres avancées en WebGL. Vu les limitations du support en terme de mémoire, ça "pousse" l'utilisation du SVG.
https://css-tricks.com/rendering-svg-paths-in-webgl/

On oublie souvent aussi la soundbank, qui selon le jeu peut facile représenter un tier de la taille du jeu. Dépendement si il y a du voice acting, beaucoup de dialogues, la fréquence d'échantillonage etc.
Pour le cas de FF, ca m'étonnerait pas qu'elle soit bien bien grosse.

Le taf sur l'audio est aussi quelque chose qu'ils font de moins en moins aujourd'hui.

Sur Space Hulk par exemple, lors que je faisais un bounce du son, je faisais systématiquement des tests à des fréquences inférieures à 48khz en partant de 22.5, puis je prenais la fréquence la plus clean en terme de rendu. Certains sons ont indéniablement besoin de fréquences plus élevées parce qu'ils perdent vite en détail. Mais quand tu peux, tu peux descendre pour optimiser l'espace et surtout la taille en mémoire.

Je mets ma main à couper que beaucoup de studios bouncent du 48k "parce que qualité" sans se soucier de l'impact que ça a sur l'espace disque, la réelle différence audible ou le gain que ça peut faire en mémoire pour le laisser à d'autres priorités.