Archives pour la catégorie 2D, 3D, jeux

Sortie d’Unreal Engine 4.13

Publié le par
Répondre

L’Unreal Engine nouveau est arrivé, trois mois après le précédent, comme d’habitude. Là où la version précédente se concentrait sur la réalité virtuelle, la version 4.13 s’éparpille plus, même si l’éditeur en réalité virtuelle est toujours l’objet d’une grande attention. Parmi les domaines d’améliorations, on compte cette fois le rendu et l’éditeur de cinématiques, même s’il est impossible de citer toutes les nouveautés en peu de mots.

Éditeur de cinématiques Sequencer

L’éditeur non linéaire de cinématiques apparu dans la 4.12 reste le théâtre d’opérations d’envergure, avec la possibilité d’enregistrer en direct une partie dans le jeu développé. Cette capture n’est pas une vidéo : au contraire, toutes les animations, tous les effets, tous les sons sont mémorisés séparément et peuvent être modifiés dans l’éditeur ! Au moment de cette capture, il est aussi possible de limiter l’enregistrement à une série de composants et de propriétés.

Rendu

Du côté du rendu 3D, les lampes ont vu leur code optimisé : si une lumière ne se déplace pas dans la scène, une bonne partie des calculs déjà effectués peuvent être réutilisés sans problème pour la prochaine image à afficher. Le problème de performance vient surtout du calcul des ombres que crée la lumière (plus précisément, de la carte des profondeurs). Cette optimisation est appliquée automatiquement et ses résultats sont intéressants : pour afficher l’image ci-dessous, avec trente-trois points de lumière, il faut compter 14,89 ms pour l’affichage des ombres ; grâce aux caches implémentés, la même partie prend 0,9 ms d’affichage, ce qui permet d’ajouter d’autres effets (il faut cependant compter deux millisecondes pour l’affichage de la lumière, une contribution qui n’est pas touchée par cette optimisation).

Unreal Engine permet de générer des matériaux de manière aléatoire grâce à des fonctions de bruit. La famille d’algorithmes disponibles s’est agrandie pour recevoir le bruit de Voronoï, très souvent utilisé pour la génération procédurale. Il s’applique notamment très bien à la génération de marbre, le rendu étant très réaliste après un peu de configuration.

Il devient possible de superposer des couches de matériaux sur une topologie statique, ce qui peut avoir un effet de lissage entre les différents calques, sans utiliser de projection.

L’interaction avec des composants d’interface graphique intégrés dans le monde peut se faire avec n’importe quel pointeur laser (pas simplement directement avec la souris). L’action ainsi générée simule celle que pourrait avoir un composant matériel : un clic gauche ou droit… ou toute autre interaction. Cette amélioration vient en support à celles de l’éditeur en réalité virtuelle (voir plus bas).

Les applications mobiles pourront utiliser des effets de type posttraitement, par exemple comme si l’image venait d’une vieille télévision. Ces effets ne peuvent pas encore exploiter toutes les informations disponibles pour le rendu (la profondeur de chaque pixel n’est pas encore accessible), mais cela devrait venir avec une version ultérieure. Ces effets ne sont pas disponibles sur les versions les plus ancestrales d’Android.

Les opérations de pavage des paysages sont maintenant bien plus rapides qu’avant, l’accélération matérielle étant mieux utilisée : cette technique de rendu n’est utilisée que pour les plus hauts niveaux de détail, elle ne l’est plus du tout pour les plus faibles (comme des zones lointaines).

Éditeur en réalité virtuelle

Le nouvel éditeur en réalité virtuelle, apparu pour la 4.12, est toujours l’objet d’une grande attention. Il devient possible de peindre sur des textures existantes, par exemple.

Il permet aussi de peindre rapidement une série d’arbres, en sélectionnant simplement le type de feuillage à créer.

 

Bien évidemment, cette nouvelle version vient avec bien d’autres nouvelles fonctionnalités et optimisations, décrites dans les notes de version.

Source et images : UNREAL ENGINE 4.13 RELEASED!.

Qt Quick et Qt 5.8 : changements pour le rendu

Publié le par
Répondre

À la sortie de Qt 5.0 et de Qt Quick 2, en 2012, l’un des grands changements du côté du rendu était l’utilisation exclusive d’OpenGL 2.0 : OpenGL était vu, à l’époque, comme l’API de choix pour le rendu matériel, peu importe la plateforme (Windows, Linux, macOS, mais aussi sur mobile et dans l’embarqué, avec sa déclinaison OpenGL ES). Cependant, depuis lors, le paysage s’est fortement complexifié.

La solution actuelle ne fonctionne plus

D’un côté, les API de dernières génération ont des concepts radicalement différents (et l’OpenGL nouveau a même changé de nom : Vulkan). De plus, côté embarqué, les processeurs sans GPU OpenGL sont légion, ce qui interdit le déploiement d’applications Qt Quick (à moins d’utiliser une extension autrefois payante, Qt Quick 2D Renderer, compatible avec Qt 5.4 et plus récents). Sur Windows en particulier, l’état des pilotes OpenGL n’était pas toujours excellent (surtout sur les machines où les pilotes graphiques ne sont pas à jour), ce qui impactait directement les applications Qt Quick : dès Qt 5.4, il était possible de choisir, à l’exécution, d’utiliser ANGLE (une implémentation d’OpenGL par-dessus DirectX) ou llvmpipe (une implémentation purement logicielle d’OpenGL).

Ces solutions ne sont en réalité que des emplâtres sur une jambe de bois : un rendu purement logiciel n’est pas envisageable dans bon nombre de situations où la puissance de calcul n’est pas suffisante ; Qt Quick ne peut pas exploiter des API natives, mieux gérées sur chaque plateforme… surtout que le nombre d’API disponibles a fortement augmenté. En effet, le choix ne se porte plus entre Direct3D et OpenGL, notamment puisque les API modernes, de plus bas niveau, sont au nombre de trois : celle d’Apple (Metal), celle de Microsoft (Direct3D 12) et la seule norme multiplateforme (Vulkan). De plus, pour l’ingénierie logicielle, Qt Quick 2D Renderer ne s’intègre pas bien au reste de Qt Quick (il s’agit d’un module séparé).

Une nouvelle génération plus modulaire

Un des objectifs de Qt 5.8 est de refactoriser le code de rendu côté Qt Quick, c’est-à-dire de le découpler d’OpenGL… de le modulariser (c’était le mot clé lors du développement de Qt 5). Ainsi, il devient possible d’utiliser de nouvelles API pour le rendu des scènes Qt Quick, en implémentant une extension qui effectuera la traduction entre le graphe de scène et l’API de rendu. Tout comme il était possible, sous Windows, de passer d’OpenGL à ANGLE à l’exécution, il sera possible de changer d’API à l’exécution. Grâce à l’utilisation d’une représentation assez abstraite de la scène à afficher, chaque extension n’a pas beaucoup de contraintes à respecter dans son implémentation, ce qui permettra de l’utiliser à son plein potentiel.

Cette étape ne fait pas que déplacer des monceaux de code d’un bout à l’autre : des parties de l’implémentation du graphe de scène étaient extrêmement liées à OpenGL. Cela a forcé les développeurs à marquer certaines parties de l’interface publique de Qt comme désapprouvées dès Qt 5.8, de nouvelles API sans ces gênantes dépendances envers OpenGL sont en cours de développement pour les remplacer. Sont notamment concernés les systèmes des matériaux et des particules… mais aussi bon nombre de fichiers d’en-tête dans l’implémentation de Qt Quick : le code C++ incluait ceux d’OpenGL, même si le module Qt Quick 2D Renderer s’occupait de l’affichage (la solution était de définir des fichiers d’en-tête minimaux pour que le code compile — ce qui faisait planter l’application à toute tentative d’appel à OpenGL, forcément impossible).

Direct3D 12 sera le premier concerné par cette refactorisation en profondeur : une extension expérimentale sera livrée avec Qt 5.8 (à côté de celle pour OpenGL, qui garantit la compatibilité avec le code existant), utilisable tant pour les applications traditionnelles (Win32) qu’universelles (UWP). Même si deux gros développeurs derrière Qt (la Qt Company et KDAB) sont membres du consortium Khronos « pour promouvoir Vulkan », il n’y aura pas d’extension pour le moment.

Un moteur de rendu logiciel aux vitamines

Par la même occasion, le moteur de rendu logiciel (ex-Qt Quick 2D Renderer) est retravaillé, notamment au niveau de la performance. Le point principal qui arrivera avec Qt 5.8 est la possibilité de mettre à jour partiellement chaque image affichée, selon les parties qui ont réellement changé dans la scène. Ainsi, une animation qui était autrefois très coûteuse en CPU (une partie pour l’animation elle-même, une plus grosse encore pour redessiner entièrement l’écran à chaque image) deviendra accessible.

L’intégration avec des interfaces à base de widgets avec QQuickWidget sera aussi possible : des applications comme Qt Creator (qui utilisent la classe QQuickWidget) ne pouvaient donc pas utiliser ce moteur de rendu logiciel. Maintenant que le rendu est implémenté au plus près de Qt Quick, le transfert des images entre Qt Quick et les widgets devient possible.

Source : The Qt Quick Graphics Stack in Qt 5.8.
Merci à Claude Leloup pour ses corrections.

Un nouveau moteur de simulation de liquides pour Unreal Engine 4 : NVIDIA Cataclysm

Publié le par
Répondre

L’annonce n’est pas encore officielle, mais le code source est déjà disponible et les vidéos en ligne : NVIDIA propose un nouveau solveur physique généraliste pour la simulation de liquides dans Unreal Engine (en sus de Flex).

Unreal Engine 4 est un moteur de jeu bien implanté dans le domaine, notamment chez les professionnels, avec un rendu très léché, même si les premiers développements ont eu lieu en 2005 et les premières démos publiques en 2012. De son côté, NVIDIA a une très bonne expérience dans le développement de simulations physiques, notamment avec son moteur physique PhysX ou la suite GameWorks.

Dernièrement, le code source d’une nouvelle démo est apparu sur les dépôts de NVIDIA, intégrant le solveur FLIP dans Unreal Engine 4.12.5. Les calculs s’effectuent sur le processeur graphique et leurs résultats s’intègrent dans la gestion des particules d’Unreal Engine. En temps réel, FLIP peut simuler jusque deux millions de particules.

Le code de simulation utilise une approche hybride (d’ailleurs, FLIP signifie fluid implicit particle) : l’information générée par la simulation est stockée au niveau de particules (comme Flex), tandis que les calculs sont réalisés selon une approche plus classique à base de grille.

Télécharger le code source de la démo. (enregistrement du compte GitHub nécessaire auprès d’Epic).
Source, image et vidéo : NVIDIA presents Cataclysm liquid solver for Unreal Engine 4.

Simulation en temps réel de grandes déformations élastoplastiques

Publié le par
Répondre

La simulation des objets déformables est un problème difficile à résoudre, plus encore quand il l’est en temps réel, par exemple dans un jeu vidéo. Il s’agit d’animer des objets (un ballon, par exemple) qui se déforment quand ils sont soumis à une force — au contraire des objets indéformables, comme un mur, sur lequel on peut s’appuyer sans qu’il se plie de manière perceptible. Dans le cas où ces déformations sont relativement limitées, la situation est gérable de manière relativement efficace — nettement moins pour des déformations importantes, où les résultats ne sont pas visuellement plausibles. Cela limite actuellement la créativité des développeurs, notamment de jeux vidéo, lorsqu’ils veulent intégrer des matériaux comme de la mousse ou de la pâte — ô combien utiles.

On distingue deux catégories de déformations : d’abord élastiques, le matériau se déforme puis revient à sa position d’origine (comme un élastique ou un ressort) ; puis plastiques, il ne revient pas à sa forme initiale (comme une latte en plastique que l’on plie). La simulation concerne surtout les matériaux qui passent d’un comportement à l’autre : ils s’appellent élastoplastiques. La simulation, actuellement, peut se faire pour des déformations élastiques importantes, mais pas dans le régime plastique.

C’est là qu’intervient une équipe de chercheurs (travaillant chez NVIDIA pour leur moteur PhysX), en poursuivant leurs travaux sur la dynamique par positions (PBD), déjà appliquée avec grand succès sur des fluides. Les problèmes de déformation élastoplastique sont souvent résolus par correspondance des formes, un algorithme dont les racines sont très géométriques : à partir d’une position initiale et de points objectifs qui minimisent l’énergie, la méthode déplace, à chaque pas de temps, les points en direction des objectifs.

Les apports de l’équipe font le lien entre cette technique et leur cadre de dynamique par position. Dans cette dernière, tous les objets sont représentés comme une série de points liés par des contraintes. Par exemple, un objet solide comme une brique pourra être représenté par une série de points, avec des distances imposées entre chaque paire de points de la brique : elle restera solide et ne se déformera pas. Ici, les solides déformables sont également représentés par un nuage de points. Cependant, les contraintes ne porteront pas sur des distances à conserver, mais une forme plus légère qui garantit une certaine cohésion de la forme. Les particules sont alors filtrées et redistribuées pour continuer la simulation.

De par le formalisme employé (dynamique par positions), cette technique permet des interactions faciles avec d’autres éléments simulés, comme des corps rigides, des fluides, des tissus. Cependant, l’approche n’a pas forcément un sens physique : elle ne cherche pas à conserver la masse totale des objets déformés, mais seulement le volume visible par l’utilisateur — ce qui est une approximation raisonnable pour bon nombre de cas.

Sources : Real-time Simulation of Large Elasto-Plastic Deformation with Shape Matching, Meshless Deformations Based on Shape Matching.
Merci à Claude Leloup pour ses corrections.

Unreal Engine 3.12

Publié le par
Répondre

La nouvelle version de l’Unreal Engine, numérotée 4.12, est sortie cette semaine. Bon nombre de nouveautés concernent la réalité virtuelle, avec notamment un éditeur dédié. Ceci se fait sans oublier de nouveaux effets et un tout nouvel outil de création d’animations et de cinématiques (qui permet d’importer les réalisations Matinee). Sur le plan technique, Vulkan fait aussi son arrivée, avec une première adaptation du moteur de rendu, même s’il n’est pas encore achevé ; sous Windows, la seule version de Visual C++ pour laquelle la compatibilité est assurée est maintenant la 2015 (y compris les éditions gratuites, Express et Community).

Animations avec Sequencer

Ce nouvel outil est prévu pour combiner la puissance d’éditeurs non linéaires avec des techniques d’animation 3D. Ainsi, l’édition ne doit pas se faire exclusivement selon la ligne du temps, tout en permettant de visualiser le résultat en permanence à n’importe quel moment de l’animation. Une autre fonctionnalité importante est l’édition en simultané entre plusieurs utilisateurs.

La gestion des caméras a été améliorée depuis Matinee, facilitant la création de plans plus réalistes. Notamment, il est possible de gérer finement les détails de l’optique utilisée pour générer une vidéo (notamment la longueur focale).

Éditeur pour la réalité virtuelle

Le nouveau mode d’éditeur VR permet de naviguer dans la scène et d’éditer les niveaux tout en étant immergé dans la réalité virtuelle, bien à l’aise dans son casque. Ainsi, il est bien plus naturel de déplacer des objets, grâce aux contrôleurs intégrés aux casques. La bibliothèque de contenus est aussi accessible, avec les outils de placement précis. Cette fonctionnalité est encore assez expérimentale et ne fonctionne, à présent, qu’avec un HTC Vive ou un Oculus Rift avec un contrôleur, afin de détecter précisément les mouvements de l’artiste aux commandes.

Effets liés à la réflexion

Dans les nouveaux effets, on compte les réflexions planaires calculées en temps réel. Celui-ci fonctionne en effectuant le rendu de la scène depuis les directions de la réflexion : elle est donc assez coûteuse en temps.

Cependant, la qualité est bien meilleure qu’avec la version précédente (screen space reflections, à gauche dans l’image).

D’autres nouvelles fonctionnalités configurent finement le moteur de rendu pour une réflexion sur des surfaces bien plus réaliste que précédemment, avec une très haute qualité, notamment pour la visualisation de voitures pour les mettre en évidence.

Vulkan sur mobile

Le moteur de jeu se met aussi à la nouvelle API Vulkan, exploitée pour le moment exclusivement sur les plateformes mobiles. Les fonctionnalités nécessaires pour les autres plateformes ne sont pas encore implémentées. Cette première version n’est qu’un aperçu de ce qui attend le moteur, elle n’a pas été particulièrement optimisée.

Source et images : Unreal Engine 4.12 Released!.

CryENGINE V : de la simulation de fluides et des particules sur GPU

Publié le par
Répondre

Disponible depuis peu sur GitHub, la nouvelle version de CryENGINE, notée V, vient avec un nouveau système de simulation des particules sur le GPU, nommé Wavicle. Il s’agit d’un mouvement global, qui vise à déporter sur le GPU autant de calculs que possible, quand il n’est pas occupé à gérer les graphismes.

Wavicle s’organise exclusivement autour du GPU, en allouant et gérant les ressources nécessaires aux effets demandés, avec un impact sur le CPU à peu près nul. Puisque toutes les données sont déjà sur le GPU, elles peuvent être affichées très rapidement — tout comme la simulation des particules peut exploiter le tampon de profondeur utilisé pour le rendu, ce qui permet d’effectuer des calculs de collision avec les éléments affichés. L’avantage du GPU est qu’il peut traiter plus de particules qu’un CPU, simplement parce que ces calculs se prêtent mieux à la puissance de calcul disponible.

Le système est d’ores et déjà avancé, Wavicle permet de tester de nouveaux types d’interaction avec les données sur le GPU. Par exemple, il a permis le développement d’un système de simulation de fluides, avec une méthodologie SPH : le fluide est simulé comme une série de particules qui se déplacent, chacune modélisant une partie de la masse qui se déplace. En augmentant le nombre de particules utilisées, la simulation est plus précise, mais elle prend plus de ressources de calcul : il est alors possible de déterminer un compromis en performance assez précisément.

L’implémentation actuelle profite de DirectX 12 et de ses améliorations au niveau du calcul sur GPU. Cette passe de simulation s’intègre bien dans la nouvelle architecture de la partie affichage, spécifiquement repensée pour DirectX 12 : elle s’articule autour d’étapes bien définies, notamment pour s’occuper d’une partie de la géométrie de la scène ou pour traiter toute l’image, mais aussi pour effectuer des calculs plus généraux… et bientôt aussi asynchrones.

Actuellement, le prototype fonctionne assez bien. Les prochains travaux porteront principalement sur la gestion des collisions : les structures de données pour accélérer les recherches, notamment dans un voisinage données, ne fonctionnent pas toujours aussi bien dans le contexte d’un affichage, de la physique ou encore de l’intelligence artificielle. La limitation principale de l’effet, actuellement, est qu’il est gourmand en temps de calcul ; cependant, un nombre réduit de particules peut déjà créer un rendu suffisant dans pas mal de cas, même si les cas d’utilisations doivent encore être définis plus précisément.

Source : Looking ahead: GPU Fluid Dynamics for Particles.

NVIDIA GameWorks : du code source libéré, de nouveaux modules

Publié le par
Répondre

Comme NVIDIA l’avait annoncé il y a peu, de grandes nouvelles traversent son programme GameWorks, avec de l’ouverture de code source sous licence libre et la mise à disposition de nouveaux modules. Cette boîte à outils est composée d’une série d’effets utilisables très facilement par les développeurs dans leurs jeux.

De nouvelles technologies

Trois nouvelles bibliothèques font maintenant partie du programme GameWorks, après avoir été testées dans des jeux déjà en vente, principalement pour l’éclairage et la gestion des ombres (toutes sont d’ores et déjà disponibles au téléchargement) :

  • NVIDIA Volumetric Lighting simule le trajet de la lumière et sa dispersion dans l’atmosphère et l’air, un effet utilisé dans Fallout 4, plus particulièrement dans les rayons crépusculaires ;
  • NVIDIA Hybrid Frustum Traced Shadows (HFTS) traite plus particulièrement les ombres et assure une transition plus douce entre les ombres bien droites à proximité de l’objet qui bloque la lumière et les ombres bien plus douces au loin, un effet utilisé dans Tom Clancy’s The Division ;
  • NVIDIA Voxel Accelerated Ambient Occlusion (VXAO) gère l’éclairage au niveau d’une scène avec une occlusion ambiante en temps réel : la différence par rapport aux techniques plus traditionnelles est l’utilisation de toute la géométrie de la scène, pas seulement la zone visible par la caméra ; cet effet a été utilisé dans Rise of the Tomb Raider.


NVIDIA Volumetric Lighting pour le rendu d’un rayon crépusculaire dans Fallout 4


NVIDIA Hybrid Frustum Traced Shadows pour le rendu des ombres dans The Division


NVIDIA Voxel Accelerated Ambient Occlusion pour l’éclairage global dans Rise of the Tomb Raider

De nouveaux solveurs physiques

À un autre niveau, dans la simulation physique pure, de nouvelles extensions ont été annoncées (des préversions privées sont actuellement disponibles) : l’une pour les corps rigies, NVIDIA PhysX GRB (GPU rigid body) ; l’autre pour les fluides combustibles, NVIDIA Flow.

NVIDIA PhysX GRB simule des corps rigides sur des processeurs graphiques, mais peut aussi exploiter le processeur principal en simultané (sans aucun écart en fonctionnalité selon la combinaison de processeurs choisie) : par rapport au code traditionnel, les calculs peuvent être accélérés d’un facteur six pour des simulations relativement lourdes ; une préversion privée est actuellement disponible, une version plus avancée devrait être rendue disponible dans les semaines à venir.

L’accélération sur le GPU concerne toutes les étapes du solveur, répliquées par rapport à la version CPU : les contraintes, les contacts, les phases de recherche. Cependant, au niveau de l’implémentation, la version GPU a été optimisée à certains points, comme la gestion d’îlots d’objets, pour gérer des scènes encore plus grandes. L’API est très similaire à celle de PhysX, ce qui facilitera l’utilisation de ce nouveau solveur ; cependant, tout le code GPU utilise NVIDIA CUDA, ce qui empêche son utilisation sur du matériel de fabricants concurrents mais devrait être compatible Linux et OS X.

NVIDIA Flow simule l’écoulement de fluides combustibles, ce qui modélise notamment le feu et la fumée ; la différence par rapport aux techniques précédentes est que ce solveur n’est pas limité à un volume prédéfini de simulation, puisqu’il adapte la grille de calcul aux nouveaux besoins. Contrairement à NVIDIA PhysX GRB, cette bibliothèque n’a pas de parti pris au niveau du matériel : elle utilise directement DirectX 11 et 12 et fonctionne donc sur du matériel AMD (mais pas sur des systèmes d’exploitation autres que Windows).

Toujours au niveau physique, la première version finale de FleX est maintenant disponible pour le grand public, un solveur GPU généraliste que NVIDIA a commencé à montrer en 2013, mais aussi intégré à Fallout 4 pour la gestion des débris.

Du code libéré

Il y a un an, NVIDIA montrait les premiers signes d’ouverture du programme GameWorks en mettant gratuitement à disposition les sources de PhysX, son moteur physique, à l’exception des parties GPU — mais pas sous une licence libre ; de plus, l’accès au dépôt GitHub est soumis à un enregistrement.

Cette semaine, d’autres composants ont été libérés de la sorte : NVIDIA Volumetric Lighting, récemment annoncé et détaillé plus haut ; NVIDIA HairWorks, pour la simulation et le rendu de cheveux et poils ; ainsi que NVIDIA HBAO+, un effet similaire au VXAO utilisé dans Rise of the Tomb Raider.

Ce qui est plus étonnant, cependant, c’est qu’un composant complet a été libéré : FaceWorks, pour le rendu de visages. La licence indique que tout développeur peut créer un travail dérivé et le redistribuer librement, tant qu’il indique qu’il exploite du code source venant de NVIDIA — ce qui ressemble très étrangement à du logiciel libre. Les les modèles 3D ne sont pas concernés par cette licence.

Sources : NVIDIA Advances Real-Time Game Rendering and Simulation With Launch of NVIDIA GameWorks SDK 3.1, GDC 2016: PhysX GPU Rigid Body and NVIDIA Flow (y compris vidéo de NVIDIA PhysX GRB et image de NVIDIA Flow), Fallout 4 Graphics, Performance & Tweaking Guide (image de Fallout 4), Tom Clancy’s The Division Graphics & Performance Guide (image de The Division), Rise of the Tomb Raider Graphics & Performance Guide (image de Rise of the Tomb Raider)

Un premier pilote pour Vulkan

Publié le par
Répondre

NVIDIA vient de rendre disponible ses pilotes en version 364.47, après la 362 la semaine dernière. Cet incrément dans les numéros de version n’est pas si fréquent de leur part, mais il n’indique pas pour autant que cette nouvelle version ait été publiée en toute hâte : elle inclut des améliorations de performance pour une série de jeux (Tom Clancy’s The Division, Need for Speed, pour leur sortie récente ; Hitman, Ashes of the Singularity, Rise of the Tomb Raider) et la gestion du SLI pour d’autres (Hitman, The Technomancer, Zui Shong Bing Qi), en cours de développement depuis plus longtemps, quand la version précédente se focalisait sur la sortie de Far Cry Primal.

Le point le plus important de cette version concerne Vulkan : NVIDIA est le premier à fournir un pilote compatible Vulkan au grand public. Des préversions régulièrement modifiées étaient déjà disponibles depuis l’annonce de la norme, mais ces pilotes étaient prévus pour les développeurs principalement et étaient basés sur une plus vieille branche de développement (la 355, sortie en août 2015). A contrario, Intel propose des pilotes libres pour Linux, parfaitement conformes à la norme mais à compiler soi-même, rien pour Windows ; AMD propose une préversion de pilotes pour Windows.

NVIDIA GameWorks, des annonces à venir en 2016, notamment DirectX 12

Publié le par
Répondre

L’objectif du programme GameWorks de NVIDIA est de fournir une série d’effets graphiques facilement intégrables à des jeux, mais aussi divers outils pour faciliter leur développement : par exemple, des effets de débris utilisés dans Fallout 4, une simulation de cheveux et poils très utilisée, des optimisations de rendu pour la réalité virtuelle intégrées dans Unreal Engine 4. Le moteur physique PhysX fait également partie du programme GameWorks, largement plébiscité : actuellement, pas moins de cent cinquante mille personnes sont inscrites à ce programme, téléchargeant principalement Nsight, Androidworks, PhysX, FleX et HairWorks. Le contenu de GameWorks n’est pas réservé aux développeurs professionnels, les bibliothèques sont également accessibles aux particuliers qui développent des jeux ou des animations dans leur temps libre (comme celle ci-dessous).

NVIDIA GameWorks : depuis les premiers effets

L’affaire GameWorks a commencé sous ce nom en 2013 pour officialiser une équipe qui travaillait depuis le début des années 2000 directement avec les développeurs de jeux : elle cherchait à améliorer leur rendu et optimiser leur performance, pour développer le plein potentiel des processeurs graphiques. Leurs communications passaient par des articles publiés lors du SIGGRAPH (une grande conférence pour l’animation par ordinateur), des codes d’exemple ou encore des démonstration purement technologiques.

Ces efforts ont payé, mais n’étaient pas suffisants : une leçon de cette longue période informelle est qu’une technologie n’est jamais prête avant d’avoir été intégrée complètement dans un jeu. Tel est l’objectif de GameWorks : rassembler des techniques éprouvées dans au moins un jeu et en faciliter l’adoption. Cela signifie aussi s’assurer que l’effet visuel est disponible au plus grand nombre, pas seulement à ceux qui disposent de matériel de dernière génération.

Une attention pour les développeurs de jeux

Un autre problème, en passant d’exemples de code à des bibliothèques complètes, est le besoin d’acceptation de la part des développeurs : les bibliothèques GameWorks sont prévues pour être simples à intégrer (et le sont déjà pour une série de moteurs de jeux)… mais ne viennent pas directement avec le code source. Ce mode de fonctionnement convient très bien à certains développeurs, alors que d’autres ont besoin de mettre les mains dans le cambouis : au fil du temps, ces bibliothèques ont été adaptées pour laisser une plus grande flexibilité au développeur et en distribuant les sources à la demande.

Pour le moment, les composants de GameWorks sont principalement disponibles pour Windows, plus spécifiquement DirectX 11. En effet, cette version est la plus utilisée pour les jeux actuels et ne limite pas le développement des effets (plus particulièrement ceux qui exploitent la physique). Cependant, DirectX 12 gagne du terrain du côté des jeux et les bibliothèques GameWorks verront des versions compatibles avec cette nouvelle version, selon la demande des développeurs de jeux.

Bien que rien ne soit actuellement prêt pour annonce, selon les gens de NVIDIA, pas mal d’annonces auront lieu en 2016, entre GameWorks et DirectX 12. Elles suivront une année 2015 relativement chargée, avec l’inclusion de technologies dans des jeux comme Fallout 4 ou The Witcher 3, mais aussi la première inclusion de WaveWorks pour la simulation d’océans dans Just Cause 3 et War Thunder. Sans oublier les controverses.

Source : Nvidia Talks GameWorks And DirectX 12 Plans For 2016.

Qt rejoint le consortium Khronos

Publié le par
Répondre

La Qt Company, la filiale de Digia qui produit Qt, a rejoint le consortium Khronos, qui regroupe bon nombre d’industriels de l’informatique pour le développement en commun de normes, la plus connue étant sans doute OpenGL. De manière générale, le groupe Khronos développe des normes pour le calcul parallèle (OpenCL), les graphismes (OpenGL et maintenant Vulkan), y compris pour le Web (WebGL), la vision par ordinateur (OpenVX) et bien d’autres.

La norme Khronos la plus utilisée dans Qt est bien sûr OpenGL, en tant qu’interface de relativement bas niveau pour accéder à la carte graphique. Qt a longtemps permis d’accéder facilement à cette API pour faciliter le développement d’applications 3D et, depuis Qt 5.0, l’utilise même de manière préférentielle pour tout l’affichage, ce qui permet d’exploiter au mieux le matériel actuel pour tout type d’interface (y compris en 2D). Depuis peu, Qt donne aussi accès à WebGL à travers le module Qt Canvas 3D pour intégrer du contenu 3D dans des interfaces Qt Quick.

L’objectif de la Qt Company est bien sûr de participer au développement de nouvelles versions des normes de Khronos, en particulier OpenGL et Vulkan. Pour le moment, les plans dévoilés sont de fournir un accès aux API Vulkan « les plus pertinentes » pour Qt. Les premiers résultats ne devraient pas tomber avant Qt 5.8, en fin d’année (puisque Qt 5.7 est déjà en cours de stabilisation). La migration du cÅ“ur de Qt d’OpenGL vers Vulkan ne devrait pas arriver rapidement, étant donné que ce choix limiterait le caractère multiplateforme de Qt (Apple n’envisage pas d’implémenter Vulkan, lui préférant son API propriétaire Metal), même si cela pourrait apporter quelques gains en performance (bien que pas forcément suffisants pour justifier l’investissement en temps).

La Qt Company rejoint ainsi KDAB, autre grand contributeur à Qt et membre de Khronos depuis l’année dernière. Entre Qt et la 3D, KDAB est bien connu pour le développement de Qt3D, un moteur 3D complet qui arrive prochainement dans Qt (des préversions technologiques sont d’ores et déjà disponibles dès Qt 5.5, améliorées pour Qt 5.6).

Source : The Qt Company joins Khronos Group and promotes Vulkan.