En bref : une énorme part des joueurs est sur du matériel modeste (laptops, consoles portables comme le Steam Deck, GPU plus anciens) et un environnement qui ne tourne que sur une config haut de gamme les exclut. La bonne nouvelle : la plupart de la performance d'environnement se perd à quelques endroits prévisibles (overdraw, draw calls, feuillage dense, textures surdimensionnées) et se récupère avec quelques habitudes disciplinées. Voici un playbook pratique pour atteindre un budget de frame bas sans éventrer ton art, plus la méthode de la caméra fixe pour attraper les régressions avant qu'elles ne partent.
C'est le type de scène le plus cher à faire tourner : des couches de feuilles transparentes, des milliers d'instances, un overdraw lourd. C'est aussi là que vivent les gains les plus gros et les plus faciles une fois que tu sais où passe le temps de frame.
Fixe d'abord un budget, en millisecondes
Choisis un temps de frame cible sur ton matériel supporté le plus faible (16,6 ms pour 60 fps, 33,3 ms pour 30) et traite-le comme une limite dure. « Optimiser plus tard » veut dire « reconstruire plus tard » ; budgétiser d'emblée est bien moins cher.
L'optimisation sans chiffre, c'est juste au feeling. Décide le frame que tu vises sur ton matériel plancher (le Steam Deck, un laptop moyen, quelle que soit ta spec minimale) et convertis-le en millisecondes, parce que les millisecondes s'additionnent et les pourcentages mentent. Puis tiens chaque scène à cela pendant que tu construis, pas à la fin. Les équipes qui livrent fluide sur bas de gamme n'optimisent pas plus fort ; elles ne laissent simplement jamais une scène crever le budget en premier lieu, ce qui coûte une fraction de récupérer la performance après que l'art est fini et que tout en dépend.
Sache où passe le temps
Le temps de frame d'environnement est généralement mangé par l'overdraw (feuillage transparent), trop de draw calls (objets non-batchés), textures surdimensionnées (bande passante mémoire), et éclairage/ombres coûteux. Profile pour trouver TON goulot avant d'optimiser à l'aveugle.
Deviner les optimisations gaspille des jours. Ouvre un profiler, trouve si tu es CPU-bound (généralement draw calls) ou GPU-bound (généralement overdraw, shading ou bande passante), et attaque le vrai goulot. Cela dit, les environnements échouent de façons prévisibles, et c'est presque toujours l'un de : overdraw de feuillage transparent en couches ; draw calls de milliers d'objets non-instanciés ; mémoire/bande passante de texture de textures surdimensionnées ou trop nombreuses ; et coût d'éclairage/ombre de trop de lumières dynamiques ou shadow maps haute résolution. Le reste de ce playbook les parcourt dans l'ordre de leur impact habituel.
Feuillage et overdraw : le vilain habituel
Les cartes de feuillage transparent se chevauchent et re-shadent les mêmes pixels plusieurs fois : c'est l'overdraw, et c'est le tueur numéro un du bas de gamme. Réduis le chevauchement des cartes de feuilles, utilise des LODs agressifs, et culle dur le feuillage lointain.
La végétation dense est là où meurent la plupart des budgets de frame bas de gamme, parce que chaque carte de feuille semi-transparente force le GPU à shader des pixels qu'il redessinera ensuite par-dessus, parfois dix fois ou plus par pixel dans une canopée épaisse. Les correctifs : utilise des cartes de feuilles plus serrées avec moins de zone transparente gaspillée, tombe vite sur des LODs moins chers à mesure que le feuillage recule, et fixe des distances de cull dures pour que l'herbe et les buissons lointains cessent simplement de dessiner. Sur une portable, la différence entre « herbe jusqu'à l'horizon » et « herbe cullée à une distance raisonnable » peut être toute la différence entre 25 et 40 fps. Bake le feuillage en instances natives pour que le GPU puisse le batcher, et laisse l'instancing du moteur faire le gros du travail.
Draw calls et instancing
Chaque objet unique soumis séparément est un draw call, et des milliers d'entre eux calent le CPU. Instancie les meshes répétés pour que des centaines de copies coûtent un call ; fusionne le clutter statique là où ça a du sens.
Si tu es CPU-bound, les draw calls en sont généralement la raison. Chaque chose distincte que tu demandes au moteur de rendre porte de l'overhead, et une scène placée à la main avec mille rochers et buissons individuels noie le CPU en coût de soumission. L'instancing est le remède : des meshes répétés dessinés comme instances effondrent des centaines de copies en un seul call, ce qui est exactement pourquoi les outils de scatter qui bakent en instances natives du moteur comptent pour la performance : le scatter qui ressemble à mille plantes coûte comme une poignée. Là où l'instancing ne s'applique pas, fusionner le petit clutter statique en meshes combinés coupe aussi le nombre de calls. C'est un endroit où un workflow comme celui de Numivo (peindre la densité, puis bake en meshes instanciés simples) paie directement sur du matériel faible, parce que la sortie est la chose bon marché que le GPU veut.
Toutes les scènes n'ont pas à être maximalement denses. Les espaces calmes et ouverts ne coûtent presque rien et donnent au matériel comme au joueur un repos ; rythmer ta densité est en soi une optimisation.
LODs, distances de cull et tailles de texture
Donne à chaque mesh significatif des LODs pour que les copies lointaines soient bon marché, fixe des distances de cull pour que les objets minuscules-à-l'écran cessent de dessiner, et plafonne la résolution de texture à ce que la caméra résout à distance. Ces trois récupèrent beaucoup pour peu d'effort.
Trois habitudes sans glamour portent l'essentiel du budget restant. LODs : les meshes lointains devraient basculer vers des versions moins polygonales, parce que le détail complet sur un arbre de 20 pixels est gaspillé. Distances de cull : tout ce qui est trop petit à l'écran pour être remarqué devrait cesser entièrement de rendu (petits props, cailloux, herbe fine), réglé par type d'objet. Tailles de texture : plafonne la résolution à ce qui est réellement résoluble à la distance du joueur (voir la logique de densité de texels : les choses lointaines ont besoin de bien moins de texels), parce que les textures surdimensionnées brûlent la bande passante mémoire que les GPU bas de gamme ne peuvent épargner. Aucun d'eux ne nuit au look quand bien réglé ; ils t'empêchent juste de payer pour du détail que personne ne voit.
Trouve les régressions avec des caméras fixes
Définis quelques « caméras de budget » (ta pire vista, l'espace de combat le plus dense, l'intérieur le plus chargé) et vérifie leur temps de frame à chaque build. Les survols aléatoires cachent les régressions ; les mêmes vues brutales à chaque fois les exposent.
La performance pourrit silencieusement à mesure que du contenu est ajouté, et tu ne l'attraperas pas en errant dans le niveau nonchalamment. À la place, épingle ta poignée de vues pires (le belvédère de forêt dense, le marché bondé, le combat chargé d'effets) et mesure exactement celles-là, à chaque build, contre le budget. Quand un chiffre passe au rouge, tu sais qu'un changement récent l'a causé, et à peu près où. C'est la différence entre une équipe qui découvre une crise de performance à la fin et une qui corrige une régression de 2 ms le jour où elle apparaît. Sur les cibles bas de gamme, fais tourner une de ces caméras sur le vrai Steam Deck ou la machine spec minimale, pas juste une estimation d'éditeur.
Chiffres de terrain à voler
- Budgets de frame : 16,6 ms (60 fps) / 33,3 ms (30 fps), fixe-le sur ton matériel plancher
- Le tueur habituel du bas de gamme : overdraw de feuillage, cartes plus serrées, LODs rapides, cull dur
- Meshes répétés → instances : des centaines de copies pour un draw call
- Plafonne la taille de texture au détail résoluble par la caméra ; le lointain a besoin de bien moins de texels
- Attrape les régressions avec des caméras de budget fixes, mesurées à chaque build
Mini-FAQ
Dois-je choisir entre beau et bas de gamme ? Moins que tu ne le penses. La plupart du coût bas de gamme est du gaspillage (overdraw, calls non-batchés, textures surdimensionnées), pas de la qualité visible. Coupe le gaspillage et l'art survit ; les joueurs sur matériel faible manquent rarement le détail pour lequel tu payais mais qu'ils ne pouvaient pas voir.
L'éclairage dynamique est-il interdit sur Steam Deck ? Pas interdit, mais budgétisé. Limite le nombre de lumières dynamiques et de projecteurs d'ombre, appuie-toi sur l'éclairage baked là où la scène est statique, et réserve le coût dynamique là où ça compte. C'est une ligne de budget, pas une interdiction.
Quel changement unique aide le plus sur une portable ? Généralement dompter le feuillage : cartes de feuilles plus serrées, LODs agressifs et distances de cull dures sur l'herbe et les buissons. L'overdraw est le goulot le plus courant sur portable, et la végétation est là où l'overdraw vit.
À quel point tôt devrais-je tester sur le matériel cible ? Dès la première vertical slice. Une estimation d'éditeur sur une machine de dev puissante cache exactement les problèmes que la portable aura. Obtiens un build sur le vrai appareil spec minimale tôt et garde-le dans la boucle.
Tourner sur une patate, ce n'est pas rendre ton jeu moche ; c'est ne pas payer pour du détail que les joueurs ne peuvent pas voir. Budgétise en millisecondes, tue l'overdraw, instancie les répétitions, culle l'invisible, et surveille tes pires caméras à chaque build, et ton environnement sera superbe et tournera pour l'énorme public qui n'est pas sur une config haut de gamme.
