[News] Maj, infos & nouveautés sur le forum Kerbal Space Program 2 - 24-02-2023 11:27:40 (2024)

11/03/23 - News 1 :

Developer Insights #18 - Graphiques de l'accès anticipé KSP2

Source officielle : Le forum Officiel ;

https://forum.kerbalspaceprogram.com/index.php?/topic/214806-developer-insights-18-graphics-of-early-access-ksp2/

Je vous le traduis :

______________________________________________________________________________________________________

Bonjour à tous,

Je suis Mortoc, le nouveau programmeur graphique de l'équipe. Je voulais prendre un peu de temps pour parler des graphismes et des performances de KSP2 - où nous en sommes aujourd'hui, quel est notre processus et quels sont les objectifs de l'équipe.

Comme beaucoup d'entre vous l'ont remarqué, les performances de KSP2 ne sont pas extraordinaires au début de l'Early Access. Dans un jeu aussi complexe que KSP2, il y a un nombre vertigineux de domaines sur lesquels nous pourrions concentrer nos efforts et les retours que nous recevons sont inestimables pour nous permettre de concentrer notre temps sur les problèmes qui affectent le plus les joueurs.

Il y a plusieurs raisons pour lesquelles le framerate peut souffrir. Si l'on demande au CPU d'en faire trop pendant la simulation ou si l'on demande au CPU d'envoyer trop de données au GPU de manière organisée, cela peut faire chuter le framerate sans que le GPU soit au maximum de ses capacités. Dans la plupart des cas, les performances de KSP2 sont bloquées par le GPU, et comme je suis ingénieur graphique, c'est ce que nous allons étudier dans cet article. D'autres ingénieurs travaillent d'arrache-pied sur des améliorations au niveau du processeur que vous verrez apparaître dans les prochaines mises à jour.

Avertissem*nt de plongée en profondeur : chiffres à venir SpoilAfficherMasquer(Ouais pour le coup y a pas d'équivalent FR)

Avant de nous pencher sur les chiffres, commençons par expliquer ce que nous recherchons ici. Les développeurs de jeux ont tendance à penser au framerate en termes de millisecondes plutôt qu'en FPS, car il est plus facile de budgétiser le temps de jeu de cette façon. La conversion des FPS en ms est simple, il suffit d'utiliser la formule 1 000 / FPS = ms (par exemple : 100 FPS signifie qu'il faut 10 ms par image, 1 000 / 100 = 10). De cette manière, nous parlons directement de la durée d'exécution d'un système. Nous voulons mesurer le nombre de millisecondes que prend chaque système dans le jeu afin de déterminer ceux qui prennent trop de temps et font chuter le framerate.

Nous utilisons un outil appelé RenderDoc pour nos tests de performance automatisés (parmi d'autres outils). RenderDoc nous permet d'obtenir les temps réels de chaque commande envoyée au GPU. Notre outil peut alors extraire les événements GPU les plus lents pour que nous puissions les étudier.

La machine que j'utilise ici pour l'analyse des performances est un ordinateur portable équipé d'un processeur i7-8650U, d'un GPU mobile Nvidia GTX 1060 de 6 Go et de 16 Go de RAM. Il a un GPU plus lent que nos spécifications minimales actuelles, donc nous ne nous attendons pas à ce qu'il produise un framerate jouable pour le moment.

Ecran principal du KSC : 11 FPS

Dans cette scène, huit des dix plus mauvais élèves sont liés à PQS+. PQS est l'abréviation de Procedural Quad System, l'algorithme utilisé pour générer les terrains des planètes. KSP2 utilise une version modifiée du PQS de KSP1, généralement appelée PQS+ après toutes les modifications apportées pour KSP2.

Cette table commence par un appel à PQSRENDERTEMP, qui émet 229 248 vertices. Tous les autres appels de dessin qui utilisent ce nombre spécifique font du travail sur le maillage PQS. Les deux appels de dessin qui ne sont pas liés à PQS dans ce tableau sont ceux dont le nom contient un 6 et qui sont liés au système de nuage. A partir de ce rapport, nous pouvons voir que le terrain prend clairement le plus de temps au GPU dans cette scène ; 29.94ms au total.

Essayons un autre point de vue.

LKO - Low Graphics - 8 FPS SpoilAfficherMasquerLKO signifie Low Kerbin orbit

Lorsque vous vous éloignez d'un corps céleste, nous remplaçons le shader local complexe par une version à l'échelle beaucoup plus efficace. Cette scène se trouve en orbite basse de Kerbin, mais elle est suffisamment proche de la planète pour utiliser la version locale du shader. PQS+ est à nouveau 8 des 10 pires appels (la ligne Dispatch (12, 240, 1) qui est le Draw Call #1 se trouve au début de l'image quand nous lançons un shader de calcul pour générer le maillage du terrain). Le premier appel PQS+ qui a pris plus de 10 ms est particulièrement sale.

Rester ancré dans la réalité

Il est clair que le système PQS et les shaders associés posent un gros problème de performance. Parlons-en, mais commençons par un peu d'histoire. Une philosophie de base pour la première partie du cycle d'EA de KSP2 est de s'assurer que "cela ressemble toujours à un jeu KSP". Cela signifie que pour chaque fonctionnalité que nous construisons, nous voulons commencer par ce que faisait KSP1 et ensuite construire un système similaire qui l'améliore.

Conformément à cet objectif, l'équipe a commencé par la conception du PQS de KSP1 et a ajouté des fonctions graphiques modernes pour le PQS+ de KSP2. Au fur et à mesure du développement de KSP2, de plus en plus de fonctionnalités ont été ajoutées à PQS+ pour continuer à repousser les limites artistiques.

Je suis peut-être partial, mais depuis l'orbite, les planètes de Kerbol sont incroyables. Notre équipe artistique a fait un travail fantastique. Depuis la surface, le jeu est encore très joli, mais le terrain lui-même n'a pas encore la qualité visuelle cohérente que nous recherchons. Tout en essayant de construire un terrain à la hauteur de nos ambitions visuelles, nous avons ajouté plus de fonctionnalités que l'architecture précédente de PQS ne peut en supporter. Ce n'est qu'au moment de la montée en puissance de l'EA que nous avons compris à quel point nous avions dépassé les limites de la technologie.

Trajectoire future

Il est clair qu'il y a un problème, mais qu'allons-nous faire ? Plusieurs choses sont faites simultanément. Tout d'abord, nous donnons la priorité à l'optimisation des performances de ce système dans les deux prochains patchs. En particulier lorsque les paramètres graphiques sont "LOW", nous voulons que ce système consomme beaucoup moins de temps GPU. Cela prend deux formes : l'une est une optimisation purement technique qui n'affecte pas les graphismes finaux, l'autre est la désactivation de certaines fonctionnalités visuelles lorsque les graphismes sont réglés sur "LOW" ou "MEDIUM". La première catégorie, les corrections techniques uniquement, a été poussée aussi loin que possible avec PQS+. Nos plans à court terme se concentrent actuellement sur la deuxième catégorie, en désactivant les fonctionnalités qui ne sont pas assez rentables.

Voici un exemple d'optimisation qui affecte les visuels. Bientôt, dans un patch, nous pourrons désactiver le système Anti-Tile dans le terrain. A plusieurs endroits, l'effet est négligeable, mais vous pouvez voir que la surface d'Eve a un artefact de texture répétitif sans ce système. Cet effet visuel est obtenu au prix d'un accès plus fréquent à chaque texture, ce qui pèse sur la bande passante de la mémoire du GPU. La désactivation de cet effet peut avoir un impact faible à moyen sur le framerate, en fonction du GPU en question.

Des optimisations comme celle-ci sont en cours et arriveront dans les prochaines mises à jour. Le reste de cet article traite de systèmes en cours de développement, nous ne pouvons donc pas faire de promesses spécifiques sur les délais ou les fonctionnalités avant que le développement ne soit plus avancé. Mais voici où nous allons :

À moyen terme, mon premier grand projet au sein de cette équipe est de concevoir et de construire un système de terrain de nouvelle génération - ce que nous appelons le système CBT (il utilise une structure de données Concurrent Binary Tree, mais il pourrait aussi signifier Celestial Body Terrain). PQS+ nous a bien servi, mais de nos jours, les cartes vidéo sont beaucoup plus flexibles et il existe des approches plus modernes qui nous donneront de meilleurs résultats en termes de performances et de qualité visuelle. De nouvelles architectures révolutionnaires sont possibles. Le système CBT de nouvelle génération sera le sujet d'un futur blog de développement qui contiendra un aperçu plus détaillé de ce que nous sommes en train de construire. Bien qu'il soit trop tôt pour partager des détails, je dirai que je suis très enthousiaste quant à l'expressivité artistique, la variété potentielle des terrains et les performances du système CBT.

Un autre domaine qui verra un changement majeur dans la qualité visuelle et la performance est l'adaptation du jeu au moteur de rendu moderne d'Unity, HDRP (lisez plus sur HDRP ici si vous êtes curieux, c'est génial SpoilAfficherMasquerhttps://unity-com.translate.goog/srp/High-Definition-Render-Pipeline?_x_tr_sl=en&_x_tr_tl=fr&_x_tr_hl=fr#features ). Les principaux avantages du HDRP sont un moteur de rendu plus optimisé, ce qui signifie des taux de rafraîchissem*nt plus rapides, et un modèle de shader plus flexible, ce qui signifie des efforts plus efficaces de la part de l'équipe de développement. Il facilitera également la création de mods visuels. En passant, malgré l'amour que nous portons aux moddeurs, ce changement va certainement casser la plupart des mods visuels (désolé les moddeurs, parfois nous devons faire du mal à ceux que nous aimons).

Ces changements en cours nous permettront de construire des mondes plus scientifiques mais aussi plus fantastiques que les Kerbals pourront explorer dans les années à venir.