Les contenus liés au tag GDC

Epic était également de la partie au niveau des démos présentées à la GDC. Après Samaritan basé sur une version très évoluée de l'Unreal Engine 3, Epic présentait une nouvelle démo basée sur la dernière évolution en date de son moteur : l'Unreal Engine 4.

Cette démo est annoncée comme tournant en temps réel sur une seule GeForce GTX 680 et montre donc ce qu'il est possible de faire avec l'UE et le matériel actuel, à condition bien entendu de mettre les moyens au niveau artistique ! Concevoir des mondes, des objets, des personnages, des éclairages, etc., aussi travaillés représente un investissement énorme dont la croissance exponentielle pose problème pour les studios de développement.

Après FaceWorks à la GTC, Nvidia présentait une nouvelle démo à l'occasion de la GDC, dans un registre différent puisqu'il s'agit de mettre en avant l'évolution de ses travaux au niveau de la destruction dynamique des environnements. Dénommée Real-Time Dynamic Fracture, la démonstration tourne à 30 fps sur une GTX 680 et se base probablement sur un prototype d'une future évolution de ses librairies PhysX dédiées à la simulation des corps solides.

La simulation n'est pas encore physiquement parfaite et Nvidia travaille à ajouter notamment la prise en compte de l'intégrité des structures pour leur permettre de s'effondrer sous leur propre poids lorsqu'elles sont endommagées.

Le niveau de détails, la possibilité d'une destruction complète, les poussières, rendent cependant la scène plutôt impressionnante et on ne peut qu'espérer pouvoir retrouver un jour ces possibilités dans un jeu. Pour cela, de nombreux défis se posent puisqu'il s'agit de permettre à des personnages, contrôlés au niveau du CPU, de se déplacer dans des structures dont la destruction est simulée sur le GPU.

Activision présentait à la GDC l'aboutissement de ses travaux concernant l'amélioration du rendu des personnages dans les jeux vidéo, dans le but de faire passer plus facilement des émotions. Cela passe bien entendu tout d'abord par le visage et Activision se base pour sa démonstration sur les mêmes données que Nvidia pour FaceWorks. Fournies par l'Institute for Creative Technology de l'USC, elles sont tirées d'une technologie de capture de mouvements extrêmement précise qui permet de donner vie au visage d'une manière très réaliste. La démonstration d'Activision et FaceWorks utilisent cependant deux techniques de rendu différentes.

Activision indique que cette démo tourne à 180 fps sur une GeForce GTX 680. Elle a été développée sur base des travaux de Jorge Jimenez, qui fait maintenant partie de ses employés, un développeur bien connu dans le monde du rendu 3D temps réel notamment pour sa contribution dans le développement du MLAA et du SMAA. Différentes techniques sont utilisées pour améliorer subtilement le rendu de la peau et surtout des yeux, un des éléments les plus importants pour éviter la sensation poupée de cire des personnages. Voici 2 exemples de screenshots, sans puis avez les petits raffinements apportés par Activision :

Exemple 1 Exemple 2

[ Rendu simple ]  [ Rendu avancé ]   [ Rendu simple ]  [ Rendu avancé ]

Vous pourrez obtenir plus de détails sur le blog de Jorge Jimenez .

Lors de la GDC, dont l'édition 2013 s'est terminée vendredi dernier à San Francisco, les plus importants fournisseurs de technologies graphiques (les GPU Radeon, Mali, PowerVR, HD Graphics, GeForce, Adreno) étaient présents avec notamment pour but de convaincre les développeurs de jeux vidéo d'exploiter toutes les possibilités de leurs produits récents à travers des techniques de rendu toujours plus évoluées que ce soit sur PC ou dans le monde mobile, qui progresse à vive allure.

En plus de diverses présentations, AMD, ARM, Imagination, Intel, Nvidia et Qualcomm étaient présents à travers des stands principalement exploités pour mettre en avant leurs outils maisons : AMD GPU PerfStudio, ARM Mali Graphics Debugger, Imagination PVRTune, Intel Graphics Performance Analyzers, Nvidia Nsight, Qualcomm Adreno Profiler…


Ici en exemple, l'Adreno Profiler de Qualcomm qui permet d'observer assez facilement le comportement des GPU Adreno et d'appliquer des modifications à la volée pour identifier des bugs ou des goulots d'étranglement (bottlenecks). Il est ainsi possible de modifier un shader, de désactiver la synchronisation verticale, de réduire la taille de toutes les textures, etc., et d'observer l'impact en temps réel sur le smartphone ou sur la tablette.

Les outils de tous les acteurs cités proposent des possibilités similaires, chacun ayant des petits avantages ou inconvénients par rapport à la concurrence. Ils sont en général autant adapté au débogage et à l'optimisation de la partie graphique que de la partie "compute" éventuellement exposée pour les GPU.

Lors de plusieurs rencontres avec des développeurs, nous avons voulu savoir quels outils ils préféraient et pourquoi. La réponse de nos interlocuteurs a été unanime : aucun ! Pourquoi ? Tout simplement parce que la multiplication de ces outils devient problématique et que peu importe leurs qualités ou leurs défauts, devoir utiliser un outil spécifique à chaque marque de GPU est tout sauf pratique, d'autant plus quand il faut en supporter bon nombre comme c'est le cas sous Android.


Même avec seulement 3 acteurs, c'est un problème dans le monde PC comme le rappelle Crytek en parlant des opportunités et défis à venir. Il serait ainsi intéressant que Microsoft et Google proposent des outils de développement plus évolués qu'actuellement et dans lesquels les concepteurs de GPU pourraient venir s'interfacer pour proposer autant de détails que dans leurs propres outils mais d'une manière plus ou moins unifiée.

Notez au passage que Crytek en profite pour rappeler à Microsoft qu'il serait peut-être bon de travailler sur la documentation de DirectX !

Intel profite de la GDC pour annoncer deux nouvelles extensions graphiques dédiées au GPU intégré des processeurs Core de 4ème génération (Haswell). Celles-ci permettent de passer outre les limitations des API graphiques et ont pour but de rendre l'utilisation du GPU plus efficace, principalement en économisant de la bande passante mémoire, une denrée rare pour les GPU intégrés.


PixelSync

La première technologie se nomme Pixel Shader Ordering, ou PixelSync en langage commercial. Elle permet de garantir l'ordre d'écriture en mémoire des pixels affectés par une transparence. Traditionnellement, ce sont les ROP qui s'en chargent aidés par un principe qui consiste à rendre les surfaces transparentes en dernier lieu, une fois que toutes les surfaces opaques ont été traitées.

Si le mélange (blending) est personnalisé et traité via un pixel shader, ce qui est nécessaire avec des formats de données personnalisés ou avec plusieurs niveaux de transparences, cet ordre n'est plus garanti et dès qu'un pixel est terminé, il est écrit en mémoire, peu importe si un pixel précédent, peut-être plus lourd à calculer est toujours en cours de traitement. Ce côté aléatoire dans l'ordre d'écriture des pixels en mémoire pose problème dans le cas du traitement des surfaces transparentes, d'autant plus si elles sont multiples : puisqu'elles doivent être mélangées à la surface qu'elles laissent entrevoir, cette dernière doit avoir été traitée avant.

A droite, un exemple de rendu sans technique de respect de l'ordre des pixels lors d'un mélange. Aléatoirement, la face inférieure du phare peut être rendue par-dessus la partie supérieure. A gauche, PixelSync évite ce problème.
Une solution à ce problème a été présentée par AMD avec les Radeon HD 5000 et se nomme Order Independant Transparency (OIT), une technique utilisée pour les cheveux TressFX dans Tomb Raider. Elle consiste, pour les zones affectées par des transparences multiples, à retenir en mémoire tous les pixels qui correspondent à une même coordonnée à l'écran. Une fois la scène passée en revue, ils sont triés et mélangés dans le bon ordre. Cette approche est lourde puisqu'elle peut décupler le nombre de pixels écrits en mémoire. Avec PixelSync, Intel en propose une version simplifiée : si le moteur graphique s'arrange pour soumettre les triangles transparents au GPU dans le bon ordre, cet ordre sera respecté.

Le coût en performances de Pixel Sync sera en général nettement moindre que celui de l'OIT, et simplement lié au fait que le traitement de certains pixels devra se mettre en pause pour garantir l'ordre d'écriture en mémoire. C'est cependant moins flexible et moins passe-partout mais cette approche peut avantageusement remplacer l'OIT dans certains cas simples (ce n'est pas utilisable pour TressFX bien entendu). Codemaster a d'ores et déjà annoncé mettre en place cette optimisation pour GRID 2, tout comme Creative Assembly pour Total War Rome 2.

Vous pourrez retrouver une démo de PixelSync par ici .


InstantAccess

La seconde extension proposée pour Haswell, Direct Ressource Access (DRA) ou InstantAccess, représente la version Intel de la technologie Zero Copy d'AMD. Attendue depuis des lustres, elle permet d'éviter des transferts presque surréalistes entre le CPU et le GPU. Bien que cela paraisse naturel puisque ceux-ci partagent une même mémoire centrale, le problème est que les API graphiques ne sont pas prévues pour ce cas de figure et qu'elles demandent le transfert inutile de certaines données d'une zone mémoire réservée au CPU à une autre zone mémoire réservée au GPU.


InstantAccess tout comme Zero Copy permettent d'éviter ce cas de figure à travers un mécanisme qui donne au CPU un pointeur vers certains buffers présents dans la mémoire réservée au GPU, tout en protégeant ces espaces mémoire lorsque cela est nécessaire, typiquement quand le GPU doit y accéder. De quoi éviter de perdre du temps et de gaspiller de la bande passante mémoire avec des copies inutiles.

Vous pourrez retrouver une démo d'InstantAccess par ici .