Pourquoi les performances de « Cities: Skylines 2 » sont-elles si faibles ?

• Bien que Cities: Skylines 2 relève d’un genre centré sur la simulation, il présente dans la plupart des situations un goulot d’étranglement GPU marqué, et certains benchmarks indiquent qu’il faut une carte graphique d’environ 1 000 à 2 000 euros pour viser le 1080p à 60 FPS au-delà des réglages minimum
• Une frame d’exemple capturée avec Renderdoc affiche 87,8 ms, 6 705 draw calls, plus de 50 000 appels API et environ 6,7 Go de buffers et textures GPU, très loin des 16,7 ms requis pour 60 FPS
• Le cœur du goulot d’étranglement tient au manque de LOD sur de nombreux meshes et à un culling simpliste, ce qui conduit à rendre de façon répétée de la géométrie très polygonée qui contribue à peine à l’image ; à lui seul, le shadow pass prend 40 ms et représente 72 % de tous les draw calls
• Les dents des citoyens, qui ont suscité la polémique, sont bien rendues, mais elles ne sont pas la cause unique ; le problème plus important vient plutôt de l’accumulation d’un nombre excessif de sommets et d’un rendu inefficace sur l’ensemble des modèles de citoyens, accessoires et décorations
• L’intégration de Unity DOTS et HDRP étant immature, plusieurs éléments laissent penser que Colossal Order a implémenté lui-même la liaison entre ECS et renderer, le culling, la virtual texturing, etc. ; le goulot d’étranglement CPU a été réduit, mais le pipeline graphique semble ne pas avoir été suffisamment peaufiné

---

Les problèmes de performances révélés avant et après la sortie

• Cities: Skylines 2 avait déjà, avant sa sortie, connu une hausse des configurations recommandées, un report des versions consoles à 2024 et des restrictions sur les mentions liées aux performances
• Une semaine avant la sortie, Colossal Order a publié une note qui ressemblait à une explication préventive des problèmes de performances, et après la sortie, les performances sont devenues un sujet de critique presque généralisé
• Les jeux de construction de ville peuvent avoir du mal à atteindre des framerates élevés, mais ce titre se distingue par un goulot d’étranglement GPU plus marqué que le goulot CPU habituel dans le genre
• D’après les benchmarks de PC Games Hardware et Gamers Nexus, il faut un GPU d’environ 1 000 à 2 000 euros pour obtenir du 1080p à 60 FPS avec des réglages supérieurs à « very low »
• Sur une configuration RTX 3080, Ryzen 7 5800X et écran 5120×1440, le menu principal était sous les 10 FPS au premier lancement ; après avoir désactivé, comme recommandé par le studio, depth of field, motion blur et volumetric effects, il est monté à environ 90 FPS
• Sur une carte vide, le jeu tournait à environ 30 à 40 FPS, et après environ une heure de jeu, un niveau similaire et des saccades intermittentes persistaient

Moteur et structure de rendu

• Cities: Skylines 2 repose sur Unity 2022.3.7 et utilise DOTS, ECS et le Burst compiler de Unity
• Grâce à DOTS, le jeu semble exploiter plusieurs cœurs CPU bien plus efficacement que le premier opus
• La logique de jeu se compose, d’après le code, d’environ 1 200 systèmes, et la quasi-totalité de cette logique semble effectivement reposer sur une architecture ECS
• L’UI n’utilise pas Unity UI Toolkit, mais Coherent Gameface, fondé sur HTML, CSS et JavaScript
  • Le bundle JS contient des traces d’utilisation de React et Webpack
  • L’UI peut présenter des avantages en matière de maintenance et de modifications, mais d’après les données analysées, elle ne constitue pas le principal goulot d’étranglement
• Les graphismes utilisent Direct3D 11 et HDRP de Unity
• Relier un jeu construit avec DOTS/ECS au système de rendu Unity existant nécessite une couche séparée, mais Cities: Skylines 2 ne semble pas utiliser Unity Entities Graphics
  • Le skinning et l’occlusion culling d’Entities Graphics sont marqués comme expérimentaux
  • La virtual texturing n’est pas prise en charge
  • À la place, le jeu semble avoir implémenté sa propre couche de liaison à l’aide de BatchRendererGroup et de code bas niveau

Environnement et limites de l’analyse Renderdoc

• L’analyse du rendu a été réalisée avec Renderdoc
• Sur la version Game Pass, Renderdoc et NVidia Nsight Graphics ne pouvaient pas accéder à l’exécutable, probablement en raison du sandboxing ou de permissions de fichiers
• La version Steam était elle aussi difficile à connecter à Renderdoc par les méthodes habituelles, à cause de Paradox Launcher et du flux d’authentification Steam ; la capture a finalement réussi avec le Global Process Hook de Renderdoc
• NVidia Nsight Graphics a fonctionné en lançant Steam depuis Nsight puis le jeu à l’intérieur, mais sur D3D11, de nombreuses fonctions de profiling ne sont pas prises en charge, si bien qu’il n’a pas fourni beaucoup plus d’informations que Renderdoc
• La frame analysée a été capturée dans une ville d’environ 1 000 habitants
  • La version du jeu était 1.0.11f1
  • Le patch plus récent 1.0.12f1 inclut certaines améliorations, mais ne résout pas tous les problèmes
  • Le temps de frame mesuré par Renderdoc était de 87,8 ms, soit environ 11,4 FPS
  • La moyenne pendant le jeu réel étant de 30 à 40 FPS, il peut s’agir d’un overhead de Renderdoc ou d’une frame anormale

Indicateurs de rendu de la frame d’exemple

• Les statistiques de la frame d’exemple rapportées par Renderdoc sont les suivantes
  • Draw calls : 6705
  • Dispatch calls : 191
  • Appels API : 53361
  • Appels de bind index/vertex : 8724
  • Appels de bind constant : 25006
  • Appels de mise à jour de ressources : 1679
  • Textures : 342, environ 3926 Mo
  • Render targets : 180, environ 2328 Mo
  • Buffers : 4144, environ 447 Mo
  • Total des buffers GPU et textures : environ 6,7 Go
• Une utilisation de 6,7 Go de VRAM est élevée pour une scène relativement simple, alors qu’il existe encore des GPU milieu de gamme de génération actuelle dotés de 8 Go de VRAM
• D’après l’analyse complémentaire de la FAQ, le rendu de cette frame comprend 121 millions d’input vertices et environ 36 millions de triangles rasterized
  • Il ne s’agit pas du nombre total de polygones réellement visibles à l’écran, mais de la quantité de géométrie traitée sur l’ensemble des passes de rendu
  • Sur Reddit, certains rapports évoquent aussi plusieurs centaines de millions de sommets dans des villes plus grandes, et jusqu’à 1 milliard de sommets par frame dans certains cas

Instancing DOTS et mise à jour des données GPU

• Presque tous les draw calls utilisent l’instancing
• Le jeu place dans un grand buffer unique les données d’instance nécessaires au rendu de tous les objets
• Les objets de jeu ordinaires utilisent environ 50 floats par instance, tandis que les routes semblent utiliser davantage de données
• Les données d’instance de tous les objets visibles sont mises à jour dans le buffer et téléversées vers le GPU à chaque frame
• Le buffer commence autour de 60 Mo et est réalloué avec une taille supérieure si nécessaire
• Ce buffer est utilisé par presque tous les draw calls et, d’après Renderdoc, il est accessible depuis le vertex shader et le pixel shader
• Le coût de consultation du buffer peut s’appliquer à chaque sommet, ce qui peut se combiner avec le problème des meshes très polygonés

Simulation et virtual texturing

• Les compute shaders GPU sont utilisés pour des simulations liées aux graphismes, comme l’eau, la neige, les particules et l’animation squelettique
• Ces tâches prennent au total environ 1,5 ms, soit moins de 2 % du temps de frame total
• L’hypothèse initiale selon laquelle la simulation réelle du jeu serait massivement déportée sur le GPU ne correspond pas au code décompilé ni aux appels GPU
• Cities: Skylines 2 semble implémenter son propre système de virtual texturing / texture streaming
  • Le Streaming Virtual Texturing intégré de Unity reste expérimental et non pris en charge
  • Le jeu semble utiliser la virtual texturing pour la plupart des objets 3D statiques, à l’exception du terrain
• La virtual texturing permet d’économiser de la mémoire en ne chargeant que les tuiles de texture nécessaires, mais l’implémentation actuelle présente un problème où les textures haute résolution ne se chargent pas même sur des surfaces proches
• L’absence de prise en charge de l’anisotropic texture filtering pourrait également être liée à l’utilisation de la virtual texturing
• Cette passe prend environ 0,5 ms

Coût des principales passes de rendu

• Skybox generation

  • Le système de ciel physiquement basé de Unity HDRP est utilisé pour générer une cubemap à chaque frame
  • Cela prend environ 0,65 ms, soit près de 4 % du budget de frame à 60 FPS

• Pre-pass

  • Première étape du deferred rendering, elle écrit la profondeur, les normales et des informations estimées de smoothness dans des textures séparées
  • Elle prend environ 8,2 ms, ce qui est très lourd

• Motion vectors

  • Les per-pixel motion vectors utilisés pour l’anti-aliasing et le motion blur sont rendus dans une passe séparée
  • Elle prend environ 0,6 ms
  • Les motion vectors semblent partiellement cassés, ce qui explique l’absence de prise en charge de DLSS ou FSR2 au moment de la rédaction

• Roads and decals

  • Cette passe rend les routes, l’herbe et les éléments qui suivent la surface du terrain
  • Elle prend environ 1 ms

• Main pass

  • Passe centrale du deferred rendering, elle utilise les buffers précédents et le cache de virtual texturing pour produire albedo, normales, propriétés PBR, profondeur, etc.
  • Les informations de visibilité de la virtual texturing y sont également générées
  • Elle semble être rendue à la moitié de la résolution horizontale, tandis que le terrain, qui n’utilise pas la virtual texturing, est rendu en pleine résolution
  • Elle prend environ 16,7 ms, soit à elle seule tout le temps disponible par frame à 60 FPS

• Ambient occlusion

  • D’après le shader debug name, il semble s’agir de GTAO
  • Elle prend environ 1,6 ms

• SSR + SSGI

  • Le jeu utilise les screen space reflections et la screen space global illumination de Unity HDRP
  • Les deux effets prennent ensemble environ 3 ms

• Deferred lighting

  • Cette passe combine les buffers intermédiaires générés précédemment pour produire un résultat proche de l’image finale
  • Elle prend environ 2,1 ms

• Water rendering

  • Le rendu de l’eau s’appuie sur un prétraitement par compute shader et sur des images réduites/floutées en entrée
  • Il prend environ 1 ms

• Post-processing

  • Le jeu utilise temporal AA, bloom, tonemapping, ainsi que DOF et motion blur lorsqu’ils sont activés
  • L’ensemble prend environ 1 à 2 ms

• UI

  • Cette passe rend l’UI basée sur Gameface et le texte dans le monde
  • Les noms de routes sont rendus avec des signed distance fields 2D et utilisent le depth buffer pour se fondre dans la scène lorsqu’ils se trouvent derrière des bâtiments
  • Le temps de la passe UI finale est négligeable

La polémique des dents et les modèles de personnages

• Les citoyens disposent bien de modèles complets de dents, invisibles depuis le point de vue normal en jeu
• L’analyse de l’utilisateur Reddit Hexcoder0 avec NVidia Nsight Graphics a révélé que les dents étaient toujours rendues à la qualité maximale
• Le problème le plus important est que l’ensemble des meshes liés aux personnages ne disposent d’aucune variante LOD
• Colossal Order a reconnu publiquement ce problème et a aussi évoqué un problème plus large de gestion des LOD
• Les modèles de citoyens sont générés à partir de Didimo Popul8, et le modèle dents/bouche en jeu compte 6 108 vertices, contre 1 060 pour le mesh Didimo de base
• Un seul personnage, sans les cheveux, vêtements et accessoires, atteint environ 56 000 vertices
  • Un bâtiment résidentiel basse densité moyen compte moins de 10 000 vertices si l’on exclut les accessoires de jardin et les éléments de détail
• Dans la frame d’exemple, 13 ensembles de dents sont rendus, mais pas un seul pixel de l’image finale n’est affecté
• Les dents sont moins la cause unique de la baisse de performances qu’un indice de la présence généralisée de géométrie inutilement très polygonée

Accessoires très polygonés et problèmes de culling

• Le jeu rend trop d’objets qui contribuent peu, voire pas du tout, à l’image finale, avec un nombre de polygones trop élevé
• Les causes principales sont au nombre de deux
  • Certains modèles n’ont aucune variante LOD
  • Le système de culling maison est simple : seul le frustum culling semble implémenté, sans trace d’occlusion culling
• Le culling fondé sur la distance existe, mais il n’est pas agressif ; cela réduit le pop-in, au détriment des performances
• Exemples d’accessoires très polygonés relevés
  • Palette de bouteilles de gaz : plus de 17 000 vertices
  • Accessoire de corde à linge : 25 000 vertices chacun, et plus de 30 000 vertices pour une variante plus dense
  • Guérite de parking : plus de 40 000 vertices, aucun LOD, jusqu’aux câbles reliant le moniteur et le clavier modélisés séparément
  • Tas de rondins : plus de 100 000 vertices
• Fusionner les bâtiments et leurs accessoires intérieurs en un seul mesh réduit les draw calls, mais empêche de culler individuellement les accessoires intérieurs
• Dans un city builder, un même modèle inefficace peut être rendu des centaines de fois dans une seule frame, ce qui accumule les petites pertes
• Les modèles haute résolution ne sont pas problématiques en soi ; le problème actuel est que le jeu ne parvient pas à absorber ce niveau de détail et que l’usage des polygones est inefficace et incohérent

La passe d’ombres, principal goulot d’étranglement

• Cities: Skylines 2 utilise le cascaded shadow mapping
• Les ombres présentent beaucoup d’artifacts et de flickering, particulièrement lorsque le soleil ou les feuilles bougent
• Le jeu utilise 4 cascades, chacune en résolution 2048×2048
• Les paramètres graphiques avancés comportent une option directional shadow map resolution, mais au moment de la rédaction, elle n’est pas reliée dans le code
  • Ni les réglages individuels ni le paramètre global shadow quality ne modifient la résolution de la shadow map
  • Les presets d’ombres medium et high sont en pratique identiques
  • Le preset low désactive les ombres projetées par le terrain
• Malgré une qualité faible, le shadow mapping est la passe de rendu la plus lente, à environ 40 ms
• Sur les 6 705 draw calls de la frame d’exemple, 4 828, soit 72 %, sont consacrés au shadow mapping
• Le jeu semble considérer tous les objets 3D comme des shadow casters potentiels, quels que soient leur taille ou leur éloignement, et ce pour tous les réglages de qualité
• Dans les compteurs de performance de Renderdoc, de nombreux draw calls n’affectent que 0 à moins de 100 pixels de la shadow map, et les dents réapparaissent elles aussi dans la passe d’ombres
• L’amélioration des LOD et du culling pourrait donc avoir un effet important sur les performances du shadow mapping
• Point positif de détail : le jeu utilise la date, l’heure et les coordonnées actuelles de la ville pour calculer la position du soleil et de la lune

Problème de performances du menu principal

• Le menu principal semble ne contenir qu’une image de fond statique et des boutons, mais en réalité une scène 3D est toujours présente
• Derrière le menu, une scène avec terrain, eau et skybox est rendue, puis l’UI la recouvre entièrement
• Comme l’ensemble du pipeline de rendu est utilisé même pour une scène invisible, les réglages graphiques affectent immédiatement les performances du menu principal
• À la sortie, la plupart des réglages étaient par défaut proches du maximum, y compris des effets lourds que le studio recommandait de désactiver
• La cause de la chute à environ 7 FPS lors du premier lancement n’a toutefois pas été entièrement établie
  • Une baisse de performances du même ordre n’a pas été reproduite par la suite
  • Un traitement du cache de virtual texturing est effectué au premier lancement, mais l’utilisation du GPU n’a pas été confirmée
• La scène complète du menu principal contient environ 400 draw calls, 563 000 input vertices et 745 000 triangles rasterized

Interprétations complétées dans la FAQ

• Il est difficile d’affirmer que le jeu aurait dû être fait avec Unreal Engine 5
  • UE5 dispose de Nanite, Lumen et Virtual Shadow Maps, capables de répondre à certains problèmes rencontrés par C:S2
  • En revanche, il manque de fonctionnalités de niveau production pour la logique de jeu et la simulation à grande échelle équivalentes à Unity ECS, et son architecture centrée sur C++ peut être défavorable à la flexibilité et à l’accessibilité du modding
• Le jeu n’est pas totalement dépourvu de LOD
  • De nombreux bâtiments semblent avoir des LOD appropriés
  • Mais beaucoup d’éléments comme les tuyaux, accessoires de jardin et décorations n’ont pas de LOD, ou ceux-ci ne sont pas sélectionnés
• InstaLOD semble être utilisé dans l’asset pipeline du jeu, en particulier pour importer de nouveaux assets dans l’outil de modding, mais pas pour le rendu à l’exécution
• L’UI basée sur JavaScript n’est pas, d’après les données analysées, le principal goulot d’étranglement
  • Gameface n’est pas fondé sur un moteur de navigateur complet comme Electron, mais sur un framework custom conçu pour les UI de jeu
  • Il est censé être plus avantageux en mémoire et en performances que les solutions basées sur Chromium/Blink ou WebKit
• Renderdoc a ses limites en tant qu’outil de benchmark précis, mais il fournit suffisamment d’éléments pour comprendre « ce que fait le jeu qui le rend lent »

Conclusion : le goulot CPU a été réduit, mais le pipeline GPU semble presque inachevé

• La raison directe pour laquelle Cities: Skylines 2 est si lourd pour le GPU est qu’il envoie à la carte graphique beaucoup trop de géométrie inutile
• Ce gaspillage de géométrie provient du manque de LOD sur de nombreux meshes et d’une implémentation du culling simple et insuffisamment réglée
• La raison pour laquelle le studio a implémenté son propre culling et sa couche de liaison au rendu semble être que l’intégration de Unity DOTS et HDRP est encore en chantier et trop limitée pour un vrai jeu
• La virtual texturing de Unity étant elle aussi expérimentale, Colossal Order a implémenté sa propre solution, qui comporte encore des parties peu abouties
• Le scénario plausible est que Colossal Order a parié sur DOTS, une nouvelle technologie Unity, et a obtenu des résultats côté réduction du goulot CPU et échelle de simulation, mais a dû implémenter lui-même des systèmes comme le culling, l’animation et le texture streaming côté graphismes
• L’affirmation du studio selon laquelle le jeu visait dès le départ 30 FPS est jugée difficile à croire, et compte tenu du fait qu’il s’agit d’un jeu PC pur et de sa qualité graphique, elle paraît difficile à justifier comme objectif de performance
• Les pistes les plus susceptibles d’améliorer la situation sont l’ajout de LOD, l’amélioration du culling, l’optimisation du choix des shadow casters et le nettoyage des assets au niveau des accessoires ; cela pourrait prendre du temps, car de nombreux assets devront peut-être être retravaillés individuellement

[GN⁺]

Avis de Hacker News

• C’est un article intéressant, donc j’aimerais qu’on discute surtout de ce qui est intéressant précisément
  Ce genre de fil peut facilement dériver vers des généralités sur $THING lui-même, ici le jeu dans son ensemble, ou sur $RELATED, ici les frameworks, ou encore sur des sujets similaires en général
  Ce n’est pas mauvais en soi, mais plus on avance pas à pas vers des généralités, plus la discussion devient superficielle et moins intéressante. C’est pour cela que les règles du site incluent aussi « évitez les digressions générales » - https://news.ycombinator.com/newsguidelines.html

• Le passage disant que « si Colossal Order n’utilise pas le culling intégré de Unity et a sa propre implémentation, c’est parce que l’intégration de DOTS et HDRP dans Unity est encore en plein chantier et qu’on peut la considérer comme inadaptée à la plupart des vrais jeux, ce qui les a obligés à implémenter eux-mêmes une bonne partie de la partie graphique » correspond tristement à mon expérience avec les outils Unity
  DOTS est sorti, mais comme d’autres outils rachetés par Unity, on a l’impression que son implémentation est laissée à l’abandon. La gestion de l’entreprise est gravement défaillante, et vu l’affaire de politique tarifaire qui a éclaté publiquement il y a quelques semaines, elle semble plus concentrée sur les moyens de soutirer davantage d’argent aux utilisateurs que sur l’amélioration du moteur
  L’implémentation ECS de Bevy est vraiment bonne, et avec Godex, j’aimerais les voir réussir dans ce domaine

  • Je ne comprends pas comment Unity peut apparemment brûler jusqu’à 1 milliard de dollars de chiffre d’affaires par an alors que le moteur donne toujours l’impression d’un produit à moitié cuit et inachevé. Où va tout cet argent ?
  • Godex, c’est finalement du rouge à lèvres sur un cochon. Ça peut améliorer un peu les performances, mais ECS n’est pas une optimisation magique qu’on ajoute comme un plugin
    La cohérence de cache de la couche gameplay ne peut pas corriger des goulets d’étranglement au niveau du moteur
  • Honnêtement, il existe de nombreuses façons de sortir un jeu performant, et ECS n’est ni indispensable, ni forcément l’approche moderne. C’est l’un des nombreux patrons d’architecture possibles pour structurer un jeu, avec beaucoup d’avantages et d’inconvénients
    Par exemple, Godot n’est pas centré sur ECS : il s’articule autour du concept de « serveurs », des sous-systèmes de jeu autonomes qui traitent largement de manière indépendante les domaines spécialisés comme le rendu ou la physique, et qui sont faiblement couplés à la logique de jeu générale
    L’architecture ECS trouve ses origines à l’époque PS2/PS3, quand les CPU étaient médiocres. À cause des petits caches, du coût élevé des échecs de prédiction de branchement, de la mémoire lente, des espaces mémoire fragmentés et de l’absence de stockage à accès aléatoire, les développeurs devaient concevoir leurs jeux autour de schémas d’accès mémoire prévisibles ; il est donc devenu courant de traiter les données de jeu en les streamant par petits blocs
    Cette approche reste globalement une bonne pratique aujourd’hui, mais avec les CPU très rapides, l’excellente exécution spéculative, les bons prédicteurs de branchement et les dizaines de Mo de cache, ce n’est plus une exigence stricte. C’est d’autant plus vrai que les jeux modernes n’ont pas tant augmenté l’échelle de ce qui se passe à l’écran par rapport à il y a 10 ou 20 ans. Dans les jeux d’action, il reste rare qu’un joueur affronte plus d’une dizaine d’ennemis à la fois
    Les jeux qui affichent des milliers d’éléments simultanément à l’écran ont généralement besoin d’une logique et de traitements spécialisés séparés
  • DOTS n’a-t-il pas été créé en interne chez Unity ?

• Conseil pour ceux qui veulent essayer ce jeu : il faut passer le scaling de résolution de dynamique à fixe
  Sur une 3080, le menu principal est passé de « injouable à 10 fps » à « tourne très bien sans problème » en jeu avec des options moyen-haut

  • On peut même le désactiver complètement. Sur ma 3080, il semble créer beaucoup d’artefacts de rendu
  • Ce n’est pas la solution. Il faut désactiver le motion blur et la profondeur de champ. C’est surtout la profondeur de champ qui tue les performances des menus

• Pour référence, il me semble qu’une frame de Crysis, dans la scène de benchmark, comptait environ 300 000 sommets ou triangles. Donc, selon le sens dans lequel ma mémoire se trompe et selon le mauvais rapport sommets/triangles de chaque modèle, cela représente l’équivalent de 3 à 10 piles de rondins

  • Je suis l’auteur : je n’ai pas trouvé de moyen simple de compter le nombre total de sommets par frame dans RenderDoc, donc je ne les ai pas comptés moi-même. Mais quelqu’un sur Reddit a mesuré le nombre total de sommets avec ReShade, et d’après lui, dans les scènes rapprochées d’une grande ville, on peut atteindre des centaines de millions, voire jusqu’à 1 milliard de sommets
    Mise à jour : j’ai vérifié le nombre de sommets et de polygones avec RenderDoc. La scène d’exemple de l’article traite 121 millions de sommets et plus de 40 millions de triangles
  • Ça me semble juste. Je me souviens avoir vu « 1M Triangles » dans le HUD de performance et m’être dit qu’un million de triangles, c’était délirant. En tenant compte des arêtes séparées, des billboards, etc., il y a aussi de fortes chances qu’il n’y ait presque pas de sommets partagés

• J’ai vraiment apprécié le style d’écriture :
  Des phrases comme « cette passe prend environ 8,2 millisecondes, c’est-à-dire à peu près absurdement longtemps, ce qui la rend étonnamment lourde… »

  • J’aimerais que davantage de gens ajoutent ce genre de petite touche d’humour même dans des articles assez sérieux

• « Ce mesh de pile de rondins n’est lui aussi utilisé que dans la passe de rendu des ombres, mais il contient plus de 100 000 sommets »… Mais pourquoi ?

  • Parce que dans le développement de jeux, il y a environ un million de choses auxquelles faire attention. Quelqu’un, ou un logiciel, a probablement fait une erreur dans les réglages de LOD. Ou bien le code de LOD dynamique n’a pas correctement cullé le mesh LOD0, ou ils n’ont pas réussi à terminer ce code à temps, ou c’est peut-être pour une toute autre raison
    Il est parfaitement normal qu’un jeu AAA comporte quelques éléments incomplets et non optimisés. Les budgets sont toujours limités et les délais de développement courts. En plus, c’est une industrie dépendante de succès commerciaux qui ne sont pas garantis. Il existe quelques façons d’augmenter les chances de succès d’un jeu, mais elles relèvent généralement davantage de la gestion que du développement, et les revenus de précommande prévus ne sont pas fiables. Il faut donc faire des compromis pour réduire les risques, diminuer les coûts là où c’est possible et abaisser la priorité des développements les plus coûteux. Ces compromis sont bien plus importants qu’un seul mesh non optimisé. Un mesh, ce n’est rien
    Le fait que ce mesh soit en LOD0 et que le mesh des dents soit aussi en LOD0 est intéressant. Mais ce n’est pas cela, à lui seul, qui fait s’effondrer les performances du jeu, et il me paraît peu probable qu’ils corrigent ça au lieu de faire de vraies corrections de performance. Dans ce fil, l’obsession pour ce genre de meshes me semble un peu excessive
    Il y a beaucoup de commentaires chargés émotionnellement, donc je ne veux pas en rajouter ; j’essaie seulement d’apporter un peu plus de contexte
  • On aurait pu faire ça avec une centaine de sommets et une normal map intelligente, c’est juste complètement délirant
  • Le studio qui a créé ce jeu compte environ 30 développeurs

• Le bon résumé, c’est que le jeu utilise des modèles extrêmement détaillés, sans disposer de méthodes intelligentes pour abstraire ou culler ce qui ne sera pas réellement affiché en pixels ?
  Et si c’est le cas, est-ce quelque chose qui se corrige facilement, ou est-ce tellement au cœur de l’architecture qu’il faudrait repartir de la conception pour le résoudre ?

  • On ne peut que spéculer sur la difficulté de correction. Je ne suis pas spécialiste, mais je vois le culling et le LOD comme de grands piliers dans un moteur. Ne pas pouvoir utiliser l’implémentation existante, c’est vraiment une très mauvaise situation.
    Les « astuces » elles-mêmes sont sans doute bien connues, mais je ne pense pas que l’implémentation soit facile.

• DOTS est issu des idées de Mike Action. Il suffit de regarder sa présentation CppCon 2014, « Data-Oriented Design and C++ » [1]. Cela dit, d’après Twitter, Mike a quitté Unity.
  [1] https://www.youtube.com/watch?v=rX0ItVEVjHc

  • Le billet original mentionne certes les aspérités de DOTS, mais je n’y ai rien vu qui permette de dire que DOTS est la cause. Si DOTS était le problème, cela créerait un surcoût CPU, mais ici cela ressemble plutôt à l’utilisation massive d’une géométrie incroyablement trop détaillée, sans implémenter de système de LOD.
    Avec le Nanite d’UE5, ils auraient peut-être pu tenir d’une manière ou d’une autre, mais une géométrie aussi excessive aurait fait s’effondrer tout le reste.
  • On parle bien de ce Mike Action qui, avec un jeu de données très douteux excluant notamment les jeux de sport, disait que les jeux à 30 fps se vendaient mieux que ceux à 60 fps ?

• J’ai passé 40 minutes sous Proton Experimental à essayer d’obtenir ne serait-ce que quelques fps en 1080p sur une carte vide, puis j’ai abandonné et demandé un remboursement. Si les performances atroces sont corrigées, je réessaierai.
  J’ai vraiment énormément apprécié le premier, donc c’est très frustrant de ne pas pouvoir jouer à celui-ci.

  • La solution tient dans un tweet -> https://twitter.com/ColossalOrder/status/1716883884724322795
    « Si vous rencontrez des problèmes de performances, nous vous recommandons de réduire la résolution de l’écran à 1080p, de désactiver la profondeur de champ et les volumétriques, et de baisser l’illumination globale pendant que nous corrigeons les problèmes qui affectent les performances. »
    C’est tout ce que j’ai eu à faire pour obtenir des performances fluides sur une AMD Radeon RX 5700 XT.
  • Sur GeForce Now, c’est plutôt jouable. Ça saccade encore un peu, mais j’ai pu jouer plusieurs heures sans gros problème. Il y a parfois des freezes agaçants, mais ça reste acceptable.