Mod Lordgit est de retour pour nous faire découvrir les coulisses de NXT ! Aujourd'hui, il nous en dit plus sur les mises à jour alléchantes à l'étude.
Aujourd'hui, après mon blog précédent sur l'éclairage dans Giélinor, je tiens à vous parler de diverses mises à jour potentielles pour NXT, et des défis que leur implémentation peut nous poser.
Ce blog présentera le même degré de technicité que mon blog précédent, mais en raison du grand nombre de sujets abordés, je n'entrerai pas autant dans les détails. Je vous rappelle aussi qu'aucun de ces développements potentiels n'est encore certain.
Nous y réfléchirons davantage lorsque tous nos joueurs seront passés sur le nouveau client de RuneScape.
Commençons sans plus attendre !
Amélioration des textures normales et résolutions de texture
L'implémentation de textures normales et de textures haute résolution constitue sans doute l'une des améliorations qui nous tient le plus à cœur. Ces améliorations auraient le plus d'impact côté qualité des graphismes après le lancement de NXT.
Grâce aux textures normales, des objets qui, pour l'instant, semblent très plats lorsqu'ils sont éclairés, gagneraient en détails géométriques, sous la forme de normales de surface. Cette technique ferait ainsi ressortir de nombreux détails d'éclairage, notamment parce que les nouvelles fonctionnalités d'éclairage prennent les normales de surface pour données d'entrée (irradiance, occlusion ambiante, lumière spéculaire améliorée, etc.).
Cependant, l'utilisation de ces textures normales pose deux problèmes majeurs. D'abord, elle implique de produire les versions haute résolution de tous les modèles existants dans RuneScape, dont la plupart n'existent même pas ! Ensuite, il nous faudra être extrêmement vigilants lors de leur introduction en jeu afin de ne pas détruire la continuité visuelle. Ces textures posent aussi le problème de l'augmentation de la mémoire GPU, mais seuls les ordinateurs très anciens devraient être concernés.
La deuxième amélioration côté textures serait de pouvoir permettre aux artistes de créer des textures haute résolution. De manière générale, nos artistes peuvent créer des textures d'une résolution 128x128 uniquement, ce qui est extrêmement faible pour un jeu de nos jours, certains jeux prenant en charge les textures 4K ! Doubler la résolution et la faire passer à 256x256 ajouterait un bon niveau de détail de texture, mais personnellement, j'aimerais pouvoir passer à une résolution encore plus élevée. Là encore, le défi est le même qu'avec les textures normales : production de textures haute résolution, augmentation de la mémoire GPU nécessaire, et respect de la continuité visuelle du jeu.
Amélioration du système d'animation
Depuis quelques temps, un nouveau pipeline d'animation est à l'étude. Il devrait nous permettre de pouvoir enfin utiliser des outils standard de l'industrie, comme Maya, pour produire nos animations. De cette manière, nous ne dépendrons plus de nos outils ni de notre pipeline d'animation internes, complexes, lourds et dans l'ensemble inefficaces. Grâce à ce nouveau pipeline, nous pourrons créer des animations dotées d'une véritable ossature. Notre plus grand défi a cependant résidé dans l'automatisation du processus de conversion de toutes nos animations existantes en ce nouveau format : un vrai tour de force !
Ces outils vont considérablement améliorer la qualité de vie de nos animateurs, car pour l'instant, le processus de création des animations est très long et pénible. D'autres améliorations de nos pipelines d'animation seront nécessaires pour garantir une meilleure fidélité des animations de RuneScape.
Cela impliquera par exemple de passer à un pipeline d'animation basé sur les quaternions, qui ne quantifie pas massivement les données de trame lors de leur export, et conserve le format virgule flottante pendant l'export depuis Maya. Les artefacts troubles seront ainsi éliminés, et le processus de création des animations gagnera en fluidité et efficacité.
Ombres émises par une source de lumière ponctuelle et ombres douces PCSS (Percentage Closer Soft Shadows)
Notre système d'ombre et d'éclairage dynamique ne serait pas complet sans l'ajout des ombres émises par une source de lumière ponctuelle. J'ai déjà expliqué pourquoi il nous a été difficile de mettre en place un bon système d'ombres solaires dynamique. Le problème est similaire pour les sources de lumière ponctuelles. En réalité, les choses sont encore plus complexes, car nous allons devoir prendre en charge les ombres émises par plusieurs sources de lumière. Il nous faudra donc peut-être passer à un système d'ombres différé ou à un pipeline de rendu de case haut de gamme (comme Forward+).
Notre filtrage de textures d'ombres actuel pourrait aussi être amélioré. Actuellement, nous utilisons une série de noyaux de filtre lorsque nous échantillonnons les textures d'ombres pour donner l'illusion d'ombres à arêtes douces, mais ce n'est pas suffisant. Les ombres douces PCSS permettent de rendre des ombres dures constituées d'une zone d'ombre et d'une zone de pénombre déterminées par la distance d'occlusion. Cette technique est cependant coûteuse en ressources, et ne pourra être prise en charge que par les processeurs les plus haut de gamme.
Amélioration de l'illumination globale
Comme vous l'aurez sans doute compris dans mon blog précédent, l'ajout de l'irradiance et de l'occlusion ambiante a eu un impact significatif sur l'éclairage dans RuneScape. Ce qui nous intéresse désormais, c'est de savoir si nous pouvons aller plus loin.
Si notre nouveau système d'illumination globale constitue une amélioration majeure par rapport au client Java, il a toutefois repoussé les limites en termes d'améliorations. Nous pourrions utiliser un mélange d'occlusion de type Screen Space Directional Occlusion (occlusion directionnelle dans l'espace de l'écran, ou SSDO) et d'occlusion ambiante à grande échelle, mais les bénéfices seraient minimes.
Le mieux désormais, c'est de passer au niveau supérieur, en utilisant une solution d'illumination globale en temps réel appelée tracé de cônes par voxel, qui s'appuie sur un tracé de rayons extrêmement proche afin d'obtenir un éclairage indirect unique de la scène. Pour l'instant, la meilleure solution sur le marché est proposée par NVIDIA GameWorks, mais elle nécessite des processeurs extrêmement puissants, auxquels peu de joueurs auront accès.
Il existe une autre solution moins coûteuse en ressources, appelée volumes de propagation de la lumière en cascade (LPV), qui serait prise en charge par un plus grand nombre de machines, mais poserait un problème de qualité et de stabilité notamment pour les distances élevées. Certains jeux qui s'appuient sur les volumes de propagation de la lumière ont adopté une approche hybride utilisant l'occlusion SSDO lorsque les volumes de propagation ont atteint leur limite, ce qui pourrait être une solution pour nous.
Amélioration des reflets et de l'éclairage basé sur des images (Image-Based Lighting, IBL)
Les reflets en jeu permettent de simuler un éclairage spéculaire indirect émis par l'environnement, et dans la réalité, tous les objets sont capables de refléter leur environnement jusqu'à un certain point. Un objet reflétera plus ou moins l'environnement en fonction du degré de brillance de sa surface. Les reflets dans l'espace de l'écran et les cubemaps à mappage parallaxe sont deux techniques modernes permettant de contourner les limites des reflets planaires standard et des reflets des sondes placées manuellement.
Notre meilleure stratégie pour commencer serait d'utiliser les reflets dans l'espace de l'écran sur des modèles présentant un mappage d'environnement, afin d'obtenir des reflets sur des surfaces courbes. L'idéal serait d'associer cette méthode à l'utilisation de cubemaps à mappage parallaxe, mais il nous faudrait impliquer nos artistes et apporter des modifications à notre pipeline.
Rendu à base physique (PBR)
Le rendu à base physique (PBR) est une technique utilisée depuis quelques temps déjà dans les jeux vidéo modernes. Elle s'appuie sur des équations d'éclairage amélioré afin de simuler l'interaction de la lumière avec la surface des objets d'une façon qui corresponde bien plus à la réalité que les modèles d'éclairage traditionnels. Elle permet aussi de créer des matériaux et textures capables de fonctionner indépendamment de l'environnement d'éclairage. Un grand nombre de ces techniques nous viennent de l'industrie des effets spéciaux, mais ne sont prises en charge que depuis l'arrivée des processeurs de nouvelle génération.
L'une des faiblesses du modèle d'éclairage actuel de RuneScape, c'est le manque de spécularité : autrement dit, tout semble manquer de brillance. Désormais, le client NXT applique un éclairage spéculaire par défaut aux terrains et modèles (sauf si les artistes lui ont indiqué le contraire), ce qui améliore considérablement l'éclat de l'éclairage. Toutefois, comme cet éclairage est appliqué partout, il doit rester subtil afin d'éviter que tous les éléments n'aient un air de plastique.
Il est possible d'obtenir un rendu à base physique par programmation. Il suffit d'ajouter une fonction de distribution de la réflectance bidirectionnelle améliorée (BRDF) aux équations d'éclairage utilisées par le rendu des modèles et des terrains dans le client NXT. Cependant, sans intervention des artistes, les résultats ne seraient pas visibles. Si nous en avons le temps, nous tenterons d'améliorer les options d'éclairage élevées, maintenant que les nouvelles options graphiques nous offrent une plus grande flexibilité à ce niveau.
Amélioration de l'atténuation de la lumière et des lumières de zone
Le modèle d'atténuation de la lumière utilisé dans RuneScape est peu intuitif pour les artistes, et entraîne la présence d'un grand nombre d'artefacts d'éclairage, visibles dans Java et le client NXT. L'adoption d'un modèle d'atténuation de la lumière ponctuelle standard, voire d'un modèle d'atténuation fondé sur la loi des carrés inverses (Physically based inverse square falloff) comme dans Unreal 4, nous permettrait d'obtenir une atténuation de la lumière plus naturelle, ce qui faciliterait la vie de nos artistes. Le problème qui se pose alors à nous, comme avec de nombreuses autres améliorations, c'est de trouver le moyen de mettre à jour les lumières ponctuelles existantes sans détruire les environnements d'éclairage.
Les lumières de zone (c'est-à-dire les sources de lumière non ponctuelles) offriraient aux artistes un plus grand contrôle sur les zones influencées par les lumières, comme par exemple les lumières d'une surface rectangulaire plane. Les lumières de zone vont de pair avec le rendu à base physique. Le défi résiderait dans l'intégration du pipeline, la prise en charge du moteur et la formation des artistes à l'utilisation de ces outils.
Amélioration de l'éclairage des particules et billboards
J'aimerais beaucoup pouvoir remédier au manque d'éclairage sur les particules et les billboards. L'éclairage de particules réaliste n'est pas encore au point en temps réel, mais il existe des solutions plus évoluées que la simple diffusion lambertienne, qui tentent de prendre en compte la densité des nuages de particules afin de simuler l'auto-ombrage et la translucidité. L'association de cette technique à l'ombrage des particules donnerait un aspect plus cohérent aux scènes et permettrait de réutiliser les mêmes effets de particules dans des environnements d'éclairage différents.
Éclairage volumétrique et rayons crépusculaires
Les jeux vidéo d'ancienne génération ont modelé des aspects d'éclairage volumétrique inspirés des rayons crépusculaires à l'aide d'une technique de post-traitement unique. Si le résultat est joli, il reste peu convaincant, car il présente la plupart du temps de nombreux artefacts et se limite à une seule source de lumière principale.
La meilleure solution unifiée de simulation d'un phénomène naturel (comme les rayons crépusculaire) est la technique de dispersion de l'éclairage volumétrique. Grâce à cette solution plus complète, les rayons crépusculaires peuvent être émis par de nombreuses sources de lumière, et pas seulement par le soleil, et toutes les spécifications de dispersion atmosphérique sont également prises en compte. Comme aucune de ces techniques ne nécessite beaucoup d'investissement de la part des artistes ou du pipeline, elles seraient idéales pour améliorer considérablement notre modèle de dispersion de la lumière et du brouillard.
Vulkan, DirectX12 et Metal : les petits nouveaux débarquent
Trois petits nouveaux viennent grossir les rangs des API de rendu. Ces nouvelles API de bas niveau (en comparaison avec OpenGL et DirectX) aux interfaces plus faciles d'utilisation ont pour but de réduire le traitement de processeur lors des appels d'API et de permettre le rendu multicœur.
Cela vous surprendra peut-être, mais ces nouvelles API n'offrent pas grand avantage par portage simple d'OpenGL ou D3D, si on part du principe que l'ensemble du rendu est effectué à partir d'un seul thread. En revanche, là où elles deviennent vraiment intéressantes, c'est qu'elles permettent aux développeurs de créer des tampons de commandes pour des passes de rendu sur plusieurs cœurs de processeur. Cette fois encore toutefois, si vos applications utilisent déjà le processeur graphique, les gains de performance ne seront pas visibles. Sur la majorité des ordinateurs capables de prendre en charge NXT, nous utilisons principalement le processeur graphique, en particulier sur les ordinateurs de faible puissance.
Cela ne veut pas dire pour autant que nous n'utiliserons pas l'une de ces petites merveilles ! Pour tout dire, nous sommes impatients de pouvoir tester au moins l'une d'entre elles. C'est bien connu, les développeurs graphiques adorent tout ce qui peut les aider à améliorer les performances ! Parmi les trois, Vulkan est sans doute la meilleure, car c'est une API multiplateforme. L'ajout de serveurs principaux supplémentaires à DirectX12 et Metal ne nous apporterait pas grand-chose, et nous prendrait beaucoup plus de temps de développement et compliquerait le processus de couches de rendu.
Cependant, il ne s'agira pas d'ajouter simplement un serveur principal Vulkan : comme je l'ai déjà expliqué, ces API sont particulièrement efficaces en termes de rendu multicœur, et nous devrons donc repenser notre architecture de rendu pour pouvoir nous en servir.
Amélioration de l'utilisation du multicœur
Le client NXT utilise des cœurs de processeur supplémentaires pour la prise en charge de divers éléments, notamment le chargement des éléments, l'irradiance, les opérations de cache de disque et l'audio. C'est pour cette raison que le temps de chargement en jeu a considérablement diminué pour la plupart des joueurs disposant d'un processeur puissant. Tout ceci a cependant été fait de façon très ponctuelle pour des systèmes spécifiques, et la plupart du temps, les cœurs de processeur supplémentaires restent inactifs, notamment lorsqu'aucun élément ne charge.
Comment faire pour utiliser ces cœurs inactifs, me demanderez-vous ? Ce que nous devons à présent développer, c'est un système de travail multicœur. Avec un système de ce genre, nous pourrions effectuer un traitement parallèle affiné pour les systèmes adaptés. Prenons par exemple les mises à jour des animations et des particules, qui demandent beaucoup de ressources côté processeur, et qui sont constituées d'un seul thread même dans le client NXT.
Si nous ajoutons la prise en charge de Vulkan, n'importe quel système de travail jouera un rôle majeur dans la mise en place d'un tampon de commandes parallèle multicœur. Nous pourrions ainsi garantir l'utilisation totale des nombreux cœurs pendant la plupart des frames, ce qui constituerait un formidable gain de performance processeur.
Prise en charge dans le navigateur
Nous n'excluons pas la prise en charge du nouveau client par le navigateur web, mais cela ne sera pas possible lors de sa sortie en raison des limitations actuelles des différents navigateurs (absence de threads réels, pas de prise en charge des instructions vectorielles ni de WebGL 2.0). La bonne nouvelle en revanche, c'est que ces fonctionnalités sont en partie disponibles dans la version bêta de divers navigateurs, et il se pourrait qu'elles soient rendues publiques dans un futur proche (d'ici fin 2016 avec un peu de chance). À ce stade, notre version navigateur de RuneScape NXT devrait être prête, car nous avons déjà accès à ces fonctionnalités en bêta, ce qui nous permet de poursuivre notre développement en attendant leur implémentation.
Interfaces évolutives
Un grand nombre d'entre vous nous ont demandé si les interfaces de RuneScape seraient compatibles avec les affichages en 2, 4 et 8K. Pour l'instant, les interfaces ne sont pas compatibles avec ces affichages haute résolution, car tout est placé en fonction des coordonnées exactes des pixels à l'écran.
Le travail de correction que cela impliquerait serait considérable, et l'utilisation des coordonnées normalisées du périphérique, qui est la solution idéale, ne serait pas viable vu la quantité de composants d'interface conçus spécialement. Nous allons devoir trouver un moyen de concevoir un système qui puisse redimensionner les interfaces en fonction de la résolution.
En conclusion
Nous espérons que NXT ne soit que le début, et qu'après sa sortie, nous puissions nous atteler au développement de ces fantastiques nouvelles fonctionnalités afin de vous offrir une expérience de jeu bien meilleure et plus immersive.
Merci de m'avoir lu !
Mod Lordgit
Programmeur graphiste en chef