[MULTI] Comprendre le graphisme (occlusion, Joules...) (Cryengine, Crysis)

[Dawnrouille]

Salut tout le monde. I'm back avec une question sur les graphismes (les DPc'était moi )

Accrochez vous c'est long :/

Tout part de cet article cité dans l'un des nombreux débat créé par l'arrivée de Crysis 2. On évitera de parler de beauté car cette notion dépends de beaucoup trop de choses. Et de toute façon la question est résolu car le plus beau: c'est ma femme!

L'article en question parle de "Joules" sauf que moi à part en physique je ne connais pas cette unité... Donc si Someone a la réponse il est sommé de parler :copain:

Je n'ai pas trouvé ma réponse après quelques recherches. Logique, je tombe sur le joule classique et autrement je ne trouve pas de bon site d'apprentissage des graphismes.

L'article parle aussi d'eRAM??! kesako?

Et le % (pourcent) indiqué sur la capture en haut de page il correspond à quoi?

Il faut bien résoudre/comprendre ce passage pour être éclairé je crois:

"Crysis, built in the CryEngine 2, was capable of a 32.2m pixel spread across a 12 joule range, displayed in a dynamically generated four-part volumetric resource buffer. This meant a broad spectrum resonance in the upper 40s, with significant occlusion. (However, when we perform our benchmark tests on the CryEngine 3, it registers only 32.1m pixels in the 12J, reducing the BSR to a measly 43, with almost negligible ambience.)"

L'unité de "40s" ne correspond évidement pas à seconde je suppose?!

Concernant la qualité des textures présentée, n'étant pas un graphiste, la différence ne m'a pas sauté immédiatement dans mes rétines. Tout d'abord il s'agirait de textures générées (quand? en live (pour le gain de place mémoire), lors du chargement de map, ou lors du développement du jeu?) " the Crysis 2 “cardboard box” barely featuring a fifth of the parametric mesh generation of its predecessor". On aurait un cinquième de la qualité de texture de Crysis 1. Ca manquerait de heurts, ce serait trop lisse, homogène comme texture... Mais j'ai envie de faire remarquer qu'on compare du bois à du carton... Le tout c'est l'effet général obtenu non?

Ils parlent de faiblesse des OpenMP de la PS3... si qqn sait :)

Et Crysis 2 serait moins coloré???! Oui, possible mais j'ai du mal de saisir le gain de puissance que cela peut apporter?! Un pixel reste un pixel alors à moins de le coder avec moins de bits et limiter les degrés colorimétriques je ne vois pas...

Je rappel aussi qu'une comparaison a été faite car certaines textures du 1 (l'herbe, sol) sont reprises dans le 2. Et il a été démontré que leur résolution maximale a été divisée par 2 dans le 2!!! Là on va rire si un DLC haute résolution ou Dx11 sort. Encore que si ce que je dit après sur la tesselation est véridique alors il y a bien un travail supplémentaire à fournir: cqfd, donc mettre la main au porte feuilles... Sachant qu'on a tout de même eu un lancement console et PC simultané là où d'autres jeux sortent des mois après sans augmentation de qualité graphique (le simple changement de FOV, qualité des ombres et antialiasing ne font pas ce que j'appel une version PC! cf assassin's creed 2 par exemple... Je n'ai même pas terminé ou acheté les suites tant ça m'a dégoûté qu'ils puissent sortir quelque chose d'aussi dépassé et baveux. Le 1 était tolérable l'année de sa sortie mais vraiment les portages PC sans amélioration des textures... c'est tout de même un minimum.)

Une des chose qu'il m'importe de comprendre pour chaque chose, c'est la puissance de calcul requise, la facilité à réaliser ou non le calcul de nos jours... cf l'explication classique de la tesselation qui m'a toujours fait rire puisqu'on explique en général que ça ne coûte rien et que cela permet d'augmenter la géométrie... Ainsi on se doute bien que ce n'est pas si anodin. Autrement ça aurait peut-être été utilisé depuis la Belle Lurette et nVidia ne pourrait devancer AMD . J'imagine qu'il y a un coût de développement car ces nouveaux polygones discounts ne poussent pas n'importe comment je trouve (en voyant les démos genre Unigine, et endless city machintruc de n'vidia...). Donc un petit gars a dû travailler, définir tout ça et donc il doit y avoir un impact mémoire quelque part du même coup non?! Le gain viendrait qu'éventuellement les calculs sur les pixels (ombrage...) sont réalisés avant l'ajout de la géométrie supplémentaire?

J'aimerai aussi comprendre le displacement mapping si j'ai bien compris car il me turlupine. Aaaaaaaaah je viens de chercher plus d'infos et deux nouvelles questions: il semblerait que les consoles actuelles (Xbox360/PS3) ne disposent pas de cela, mais surtout que cette technique étant si gourmande qu'aucune carte graphique n'en fait vraiment mais qu'on a plutôt droit à du bump mapping boosté (bon j'ai espoir que ces dernières infos soient périmées car le poste où j'ai vu ça dâ'tu saignes?! ) ( rien d'haineux dans ce dernier pseudo jeu de mot rassurez vous j'aime tout le monde, mais surtout ma femme).

En gros une texture de displacement mapping n'est pas plane mais en relief?! Mais ça doit prendre une place supplémentaire de dingue en mémoire non? Heureusement que toutes les textures ne sont pas besoin de l'être si j'ai bien compris.

Ca va vous tenez? Parce qu'en revoici une dose

D'autres questions viennent avec le PDF d'informations sur Crysis 2:

Bon clairement pour le moment le gain de qualité sur PC ne joue quasiment que sur la charge de calcul de la lumière (pas trop de changement dans les textures, et de petits gains de qualité des géométries).

Crysis 2 semble particulièrement apprécier les quad core donc si quelqu'un sait pourquoi et comment ils ont fait car je ne vois pas trop d'éléments supplémentaires à calculer par rapport au 1 (la physique est quasiment désactivée quand on compare à son prédécesseur et l'IA ne se casse pas trop la tête...).

Ils parlent de LDR dans le document pour contraster avec HDR. Et ohhhh éh bien je crois que je viens d'avoir une réponse en live wiki français sur le HDR (je n'avais pas lu ce paragraphe les autres fois): "L'image numérique classique est codée sur 256 valeurs (entre 0 et 255) sur chaque plan rouge, vert et bleu, c'est-à-dire avec 24 bits par pixel (3 × 8 bits). L'écart d'intensité lumineuse entre le pixel le plus lumineux et le pixel le plus faible, non noir, n'est donc que de 255. Or, dans la réalité, il est courant que la dynamique entre les zones les plus lumineuses et les plus sombres d'une scène soit plus grande. Les images HDR utilisent plus de bits par pixel que les images classiques et permettent de stocker une dynamique largement supérieure. La technique la plus courante est de stocker les images avec un nombre flottant par couleur (96 bits par pixel) mais il existe aussi des images HDR avec 32 bits par pixel"

On a donc la réponse à la question émise plus haut: Crysis 2 est probablement moins coloré et moins de différence/d'écart de couleur entre les pixels permet un gain de puissance. Alors ils se vantent de leur HDR dans leur document et je ne doute pas que le cryengine2 soit capable de travailler sur une large gamme colorimétrique; Le 3 est peut-être limité volontairement, peut-être juste sur les consoles à une gamme moins importante. Ce serait intéressant de savoir s'il travail en 24 ou 32 ou 96bit/pixel (euh là j'ai un doute, le système d'exploitation influe là dessus non? cf avant d'avoir les OS 32bit, les OS 16bit tout ridicule niveau couleurs... non?? )

Va falloir faire parler Crytek (sans qu'ils ne dévoilent de secret professionnel) car je n'aime pas les documents qui font mine d'expliquer et en disent finalement peu. Leur pdf est destiné à un public non averti (pour un connaisseur les informations me semble franchement light*) mais regorge de terme peu explicites.

*c'est le cas de le dire vu la part importante tenu par la gestion de la luminosité

J'ai du mal à comprendre ce que signifie déféré (deffered) qui est régulièrement utilisé. Specular c'est pas beaucoup mieux. Bref, il faut quasiment expliquer tout le paragraphe 3 sur le pipeline de luminosité. J'aimerai bien savoir ce qui est calculé réellement en temps réel et ce qui ne l'est pas réellement. Si j'ai bien compris ils ont des textures appliquées à chaque surface pour leur luminosité classique. Puis ils voient/calculent la diffusion de lumière et l'ajoutent à la scène. Reste la partie specular lighting accumulation ou je ne sais pas à quoi cela correspond. Serais-ce ce que j'appelerai plutôt l'occlusion ambiante (arg ça c'est le diffuse lighting accumulation )?

Quelqu'un voit des fonctionnalités supplémentaires au Cryengine 2 (ou des manières de calculer qui sont des régressions)?

Hahaa moins de sources lumineuses sur console!! PC powa

Pouah le nombre de filtres lumineux c'est impressionnant, le nombre d'effets qui se superposent.

GI (general illumination) semble corriger les zones trop sombres lorsqu'on se trouve dans un environnement lumineux.

Quand au SSAO... je ne sais quoi dire. Ce n'est plus nouveau et ça consomme pas mal à ce que je sache. Tous ces calculs d'ombres qui sont proches du raytracing pour une partie d'entre eux tout de même. De ce que je sais on est encore très loin de disposer de la puissance nécessaire mais là j'ai l'impression qu'on passe un temps fou à en faire du partiel; Alors sommes nous si loin de ce type de rendus et est-ce que la rastérisation a encore de si beaux jours devant elle? Une fois qu'on fait du lancé de rayon ce qui ferra la qualité ce sera le nombre de renvois de rayons calculés et le nombre de sources lumineuses affichables. Inutile (ou presque, je pense à des effets comme le bloom) d'ajouter des filtres en tout genre.

Qu'entendent-ils par deferred decals??? C'est tellement spécial? Ce sont juste des textures appliquées sur d'autres textures, un peu comme du bump mapping non?

Ah ben pour l'eau ils peuvent causer et dire que c'est dû à l'environnement urbain, mais c'était bien moins fameux que dans le 1.

J'ai pu jouer à la version leaké pour le moment où l'utilisation de la luminosité, du bloom ou autre était vraiment abusée au point de dégoûter de certaines scènes, fatiguantes, éblouissantes alors même qu'avec de la logique rien ne destinait tel ou tel objet à pouvoir réfléchir autant de lumière sans être aux caraïbes. M'enfin il faudra que je vois le résultat final car il semble que les critiques soient très bonnes pour la qualité des éclairages de la version finale.

Ils ont amélioré le motion blur dans le 2 d'après ce qu'ils disent? Est-ce aussi votre avis ou on a là un exemple de régression pour une technique moins coûteuse (ils utilisaient un flou en sphère avant)?

Pour l'antialiasing là je suis un peu trop fatiguer pour y penser Mais n'hésitez pas à commenter comment ça se passe et ce qui a été fait.

-en résumé vous pouvez m'expliquer ce que sont les ... ohhh sheet , 36 truc à actualiser à chaque fois donc... ben bon courage et merci, non, bisouuuu((x) pour les femmes), schmoutz à tous ceux qui voudront bien me faire partager leur savoir afin que toutes ces questions trouvent leur dulcinée Raiponce.

Sorry je me suis encore lâché là j'espère que vous avez survécu

[foetus]

Ouhhh lalala il y a beaucoup d'imprécisions:

1) OpenMP: librairie Intel qui permet de faire du multi-threading plus ou moins automatique et qui nécessite la complicité du compilateur

2) Bump Mapping -> On va réafficher l'objet avec un petit décalage horizontal et vertical (pense aux ombres)

3) Parallax Mapping -> On va utiliser une carte de "distances" pour savoir de combien un point de la texture va être déplacé (en fonction du point de vue) afin de donner un effet de relief.

3) Displacement mapping -> Là la grosse différence, la géométrie va être carrément modifiée. L'avantage c'est l'éclairage qui sera nickel.

Il y a deux types de anti-aliasing: le super-sampling et le multi-sampling. Mais bon, si je ne dis pas de bêtises plus ta résolution est élevée, moins tu as besoin d'anti-aliasing.

Peut être à cause du HDR, mais les couleurs ne sont plus des entiers, mais des réels (flottants). C'est John Carmark qui avait demandé cela en 2000/ 2001. C'est pour cela qu'il a une précision plus grande que 32 octets.

[Dawnrouille]

Et UN warrior merci, en plus rapide

1) Concernant OpenMP le pépin vient donc d'Intel pas franchement copain avec Sony/IBM. Mais alors ce problème ne touche pas que la génération de texture mais tout ce que doit exécuter la PS à la noix. Par contre il y a tout de même eu de sacrés progrès depuis la sortie de la PS3 -les développeurs avaient bien râlé quand à la difficulté de programmer dessus- IBM ou autres n'ont pas sorti d'autres solution que Crytek auraient pu utiliser?

La suite je répondrai demain, il faut que j'aille dodoter sinon je vais écrire encore plus de merde que d'hab.

[foetus]

Et UN warrior merci, en plus rapide

1) Concernant OpenMP le pépin vient donc d'Intel pas franchement copain avec Sony/IBM. Mais alors ce problème ne touche pas que la génération de texture mais tout ce que doit exécuter la PS à la noix. Par contre il y a tout de même eu de sacrés progrès depuis la sortie de la PS3 -les développeurs avaient bien râlé quand à la difficulté de programmer dessus- IBM ou autres n'ont pas sorti d'autres solution que Crytek auraient pu utiliser?

La suite je répondrai demain, il faut que j'aille dodoter sinon je vais écrire encore plus de merde que d'hab.

En fait, la PS3 utilise le processeur CELL qui est un processeur totalement différent des autres processeurs.

Tous les consoles/ PCs/ etc sont soient multi-cores ("plusieurs processeurs dans une puce" en gros), soient multi-processeurs (plusieurs processeurs): tous les algorithmes de découpage de tâches, de partage de mémoire, d'exécution en parallèle etc... existent depuis des années. Mais, pour l'instant c'est aux développeurs de faire la tâche (et en plus, c'est plus ou moins spécifique à chaque système d'exploitation): rien n'est à 100% automatique.

Par contre le processeur de la PS3 : c'est 1 processeur et 8 co-processeurs (pense aux GPUs par exemple: ce sont des puces spécialisées pour faire une tâche spécifique). Et là, tous les algorithmes de multi-threading ne peuvent pas être appliqués.

Et en plus, si je ne me trompe pas, les co-processeurs sont bêtes et les développeurs doivent leurs donner des données d'une taille très précise sinon les co-processeurs soient travaillent dans le vide soient ont du travail en plus (découper les données pour avoir la bonne taille).

Donc oui et non:

[psikobare]

in the upper 40s, with significant occlusion. (However, when we perform our benchmark tests on the CryEngine 3, it registers only 32.1m pixels in the 12J, reducing the BSR to a measly 43, with almost negligible ambience.)"

L'unité de "40s" ne correspond évidement pas à seconde je suppose?!

c'est pas une unité

40s = forties = quarantaine

in the upper 40s, dans la partie haute de la quarantaine, soit, à peu près 47-48 selon mon garagiste

je regarde le reste plus tard, j'ai de la route à faire

[Dawnrouille]

c'est pas une unité

40s = forties = quarantaine

excellent, je ne l'avais même pas envisagé, entre la théorie de l'anglais qui prends ses premières années de vieillesse et un doc où le moindre terme bizarre est censé être technique... Bien trouvé , j'ai bien ri de moi

Pas d'urgence, je suis le poste. Je dois encore répondre à foetus mais plutôt quand j'aurai un peu plus de temps et les yeux en face des orbites.

Bonne route