Mise à jour 26.08.05
Des changements ont été apportés au menu principal, à la liste d'amis et à plusieurs fonctionnalités pour améliorer l'expérience de jeu.
Changements du Menu Principal
La page d'accueil du menu principal ne remplit pas son rôle, elle devrait vous permettre d'accéder facilement à un jeu qui vous intéresse. J'ai apporté quelques modifications cette semaine, et nous continuerons à l'améliorer jusqu'à ce qu'il soit utile.
Liste d'Amis
La liste d'amis a reçu quelques améliorations cette semaine car elle avait l'air dépassée. Les membres du groupe sont regroupés dans la liste et vous pouvez inviter des utilisateurs à votre jeu / groupe directement depuis la ligne.
Mode Streamer
Nous avons ajouté un paramètre Mode Streamer à la plateforme. Lorsqu'il est activé, tout le monde (vous y compris) se verra attribuer un nom anonyme générique ainsi qu'une image de profil générée procéduralement.
Veuillez noter que cela ne fonctionnera pas pour tous les jeux par défaut, donc les développeurs peuvent vérifier Preferences.StreamerMode pour s'assurer qu'ils ne partageront jamais les chaînes de joueurs/images de profil lorsque le Mode Streamer est activé.
Miniatures des Cartes Montées
Vous pouvez jouer à des cartes de jeux montés pris en charge, celles-ci ont maintenant des miniatures pour faciliter la sélection. Profitez-en 😎
Si vous développez votre propre montage, SceneLoader implémente maintenant IThumbnailProvider pour charger des miniatures depuis /thumbs/{Host.Ident}/{RelativePath.WithExtension( ".png" )}. Vous pouvez les générer en masse avec la commande mount_generatethumbs qui prend une capture d'écran miniature d'un objet de jeu étiqueté map_preview ou revient à un point de spawn de joueur.
Téléchargements de Paquets Plus Rapides
Télécharger des jeux et des actifs laissait beaucoup de bande passante inutilisée, surtout sur des connexions plus rapides.
Nous avons augmenté la limite de téléchargement parallèle de 16 à 64, et sommes passés à HTTP/2 afin que ces téléchargements partagent quelques connexions au lieu d'ouvrir 64 sockets séparés. Les petits fichiers sont maintenant téléchargés environ deux fois plus vite.
Nous streamons également les fichiers directement sur le disque au lieu de les mettre en mémoire d'abord. Un paquet de 610 Mo faisait auparavant grimper notre mémoire à 739 Mo, maintenant il reste à 3 Mo.
Glyphes d'Entrée & Améliorations
Nous avons ajouté le support pour le récent Steam Controller, maintenant nous avons une bibliothèque de glyphes unique pour le Steam Deck & Controller. Dans le même temps, j'ai également ajouté le support pour les joycons de Switch aussi.
De plus, le Steam Controller / d'autres contrôleurs génériques ne rapportaient pas leur nom, maintenant ils le font, ce qui devrait faciliter la distinction entre vos contrôleurs.
Vulkan 1.3
Nous augmentons notre version minimale de Vulkan de 1.2 à 1.3. Bien que cela semble être un saut significatif, nous ne nous attendons pas à ce que cela affecte la grande majorité des joueurs ou change de manière significative nos exigences matérielles.
En réalité, cela correspond aux nouvelles spécifications minimales de Minecraft, que nous considérons comme un standard raisonnable.
Passer à Vulkan 1.3 nous donne une base plus propre et plus cohérente pour le rendu et nous permet de nous appuyer sur des fonctionnalités qui sont déjà standard sur le matériel moderne. Pour presque tout le monde, rien ne change. Il n'y a pas de nouveaux paramètres visuels à configurer, pas de changement de performance attendu, et pas besoin de mettre à niveau votre PC.
Modernisation de Vulkan
Nous avons commencé à moderniser notre utilisation de l'API Vulkan.
Rien que vous verrez directement, mais cela élimine beaucoup de code hérité et donne au pilote de meilleures informations à traiter.
VK_KHR_synchronization2 est maintenant utilisé partout. Les portées de synchronisation sont spécifiées par barrière au lieu d'un masque OR'd par appel, donc le pilote voit les vraies dépendances et peut chevaucher des travaux non liés au lieu de sur-synchroniser.
VK_KHR_dynamic_rendering est maintenant obligatoire, ce qui nous a permis de supprimer complètement l'ancien chemin de rendu et de framebuffer.
Tout cela a été bien supporté par les trois principaux fournisseurs pendant des années, donc il s'agit principalement de nettoyer les anciens chemins de code et de préparer le terrain pour d'autres mises à jour.
Compilateur de Shaders Slang
Nous avons changé notre compilateur de shaders de DXC à Slang, c'est le même compilateur utilisé dans Source 2 en amont.
Il ne devrait pas y avoir de changements perturbateurs pour vos shaders, Slang est entièrement compatible avec HLSL mais ajoute :
- Réduction des temps de compilation des shaders jusqu'à 25% avec le même HLSL. Cela peut être encore amélioré avec des modules, des génériques et des interfaces.
- Support Intellisense via les extensions Visual Studio & VSCode (que nous utilisions déjà)
- Génériques & interfaces réduisant les combinaisons de shaders et permettant de gérer de grands codes avec un code plus modulaire.
Comme toujours, nous allons viser à rester à jour avec les dernières technologies, que ce soit en matière de rendu, .NET ou autre.
DLSS
J'ai ajouté un nouvel upscaleur DLSS aux côtés de FSR3. Ce sont des upscaleurs optionnels qui utilisent des techniques temporelles, donc ils peuvent présenter de légers effets de ghosting et des artefacts. Il n'y a pas de génération de frames et aucune intention de l'ajouter.
Corrections des Upscalers
Les GPU sélectionnent implicitement une version plus lisse et plus petite d'une texture lorsque les pixels voisins des textures sont plus proches lors du rendu à des résolutions plus basses, les upscaleurs rendent le jeu à une résolution inférieure, la combinaison des deux faisait que les textures semblaient trop lisses lorsque vous utilisiez DLSS ou FSR.
En appliquant un biais sur la manière dont ces textures sont sélectionnées, nous pouvons faire en sorte que les textures du jeu aient le même aspect net que la résolution native.
Le Spéculaire est maintenant activé par défaut dans les shaders complexes
Nous avons activé le spéculaire par défaut dans tous les matériaux utilisant un shader "complexe". Si vous avez déjà créé des matériaux avec des shaders complexes, vous savez que le "spéculaire" était auparavant une fonctionnalité optionnelle que vous deviez activer manuellement dans chaque matériau que vous créiez avec complexe.
Le spéculaire est ce qui rend les modèles brillants et élégants. Tout est brillant. Il n'était pas logique qu'une partie aussi importante de l'ombrage soit optionnelle, et je sais par expérience personnelle que cela peut être assez déroutant pour de nombreux artistes débutants. De plus, presque tous les autres shaders, y compris les personnalisés, ont le spéculaire activé par défaut.
Cela affectera-t-il mes actifs ? Il est très probable que cela NE affecte pas vos matériaux, et les jeux continueront à avoir le même aspect. Cependant, il peut y avoir un cas particulier où cela *peut* changer l'apparence de vos matériaux, mais seulement s'ils répondent à des critères spécifiques :
- Le matériau avait précédemment la fonctionnalité "Spéculaire" désactivée
- Aucune texture de rugosité définie, utilisant la texture par défaut qui équivaut à 0.5 de rugosité
Dans ce cas, les modèles pourraient acquérir un éclat plastique plat. Cela peut être corrigé en définissant la valeur de rugosité dans les paramètres du matériau à 1.0, ou en ajoutant une texture de rugosité appropriée, cela devrait être un correctif assez rapide espérons-le.
Ajouter le support de teinte au shader de fourrure
Le shader de fourrure prend maintenant en charge la teinte depuis le composant de rendu de modèle. Cela n'était pas possible auparavant, mais maintenant que nous avons enfin un code lisible par l'homme dans le shader de fourrure, nous pouvons commencer à implémenter de nouvelles fonctionnalités. J'imagine que cela sera utile pour les créateurs de cosmétiques.
Mise en Cache des Ombres Statique
Maintenant que nous pouvons marquer des objets comme statiques, nous pouvons faire de belles optimisations autour de cela.
Pour les cartes d'ombres, nous n'avons besoin de rendre la géométrie statique qu'une seule fois puis de la mettre en cache, les ombres ne redessineront ensuite que les objets dynamiques dans les cartes d'ombres et vous n'avez pas besoin de faire beaucoup de configuration ou de cuisson.
Corrections de Transparence des Cheveux
Nous comptons sur l'alpha pour la couverture pour une transparence indépendante de l'ordre, mais cette technique ne fonctionne que lorsque MSAA est activé. Avec MSAA désactivé, nous revenions essentiellement à la transparence par porte d'écran, ce qui donne des motifs de stippling peu esthétiques.
Maintenant, lorsque MSAA est désactivé, nous coupons l'alpha à la place. Cela signifie que les cheveux ne sont plus semi-opaques, mais cela élimine également le stippling.
À l'avenir, nous pourrions envisager d'autres techniques de transparence indépendante de l'ordre qui ne dépendent pas de MSAA, mais d'ici là, nous avertirons dans les paramètres si MSAA est désactivé.
Bloom 3
Notre deuxième implémentation de bloom, la précédente convenait mieux à ce qui était fourni avec le moteur et était également un bon exemple de notre pipeline de post-traitement, mais était difficile à configurer, après les changements récents, elle a également perdu beaucoup de puissance visuelle.
Bloom 3 a l'air encore mieux et est plus facile à configurer, cette implémentation est plus proche de ce que font les jeux modernes.
De petits détails très brillants ne fleurissaient pas, ils le font bien maintenant :
Cela s'est également avéré être environ 25 % plus rapide dans nos benchmarks.
Ombres
Il y a quelques mises à jour, nous avons ajouté des ombres en espace écran, nous voulons exposer le concept de masques d'ombre plus généralement progressivement, une façon de différer une partie des calculs d'ombre aux shaders de calcul avec une texture en espace écran, afin qu'ils puissent être décimés efficacement et composés correctement.
J'ai refait la manière dont nous gérons les masques d'ombre en interne et cela a également corrigé le délai d'une image qui causait des choses comme les ombres en espace écran en VR à être rendues dans l'ordre inverse, maintenant tout est en ordre et l'API devrait être presque prête à être rendue publique.
J'ai également corrigé des artefacts à travers les divergences de quad dans les ombres, nous utilisons une technique appelée biais de profondeur du plan récepteur qui utilise la différence de profondeur entre les texels de cartes d'ombre voisins dans un quad pour ajuster le biais de profondeur en conséquence, le problème est que l'ordre des cartes d'ombre dans ce quad peut diverger, donnant des données incorrectes, même lorsque nous essayons de l'atténuer.
J'ai simplifié cela et utilisé une technique similaire à ce que fait Unity et Godot en décalant la position de l'ombre par la taille de PCF et la normale de surface, ce qui résout à la fois l'acné d'ombre et le problème de divergence de quad.
Mesh Agrégés de Hammer
Les cartes Hammer construiront maintenant des objets de scène agrégés à partir de maillages et de props, les agrégats combinent plusieurs maillages et props partageant un matériau en un seul objet de scène agrégé spécialisé, de sorte que le runtime soumet un lot au lieu d'un par maillage.
Cela entraîne moins d'appels de dessin et un chemin plus rapide pour dessiner la géométrie statique.
Ceci est en partie rétro-porté de Source 2 en amont, mais sans meshlets ou culling GPU pour la première version.
Visibilité Open World de Hammer
Nous avons mis à jour la manière dont les clusters de visibilité sont fusionnés lors de la compilation de la carte, en utilisant des paramètres éprouvés de Deadlock.
Les cartes ouvertes pouvaient auparavant générer de nombreux petits clusters de visibilité voisins, même lorsque ces zones pouvaient déjà se voir. Les nouveaux passages de pré-fusion combinent des espaces ouverts appropriés et de petites régions avant le début de l'échantillonnage de visibilité.
Cela devrait :
- Réduire les clusters de visibilité inutiles
- Améliorer les calculs de visibilité dans de grandes zones ouvertes
- Produire des données de visibilité plus propres lors de la compilation de la carte
Les cartes doivent être reconstruites pour bénéficier de ces changements. Comme cela affecte la visibilité dans chaque carte, nous allons également valider les résultats à travers les constructions de cartes et des vérifications visuelles de bon sens.
Pourquoi mettre à jour Hammer ?
Nos scènes auront bientôt une étape de compilation qui utilise des maillages et des props agrégés.
Les rétro-porter de Source 2 en amont dans Hammer nous a donné l'occasion de les tester dans nos cas de géométrie statique les moins performants.
Mauvaises faces
Hammer mettrait en évidence les mauvaises faces afin que vous puissiez les trier, donc maintenant nous faisons de même.
Masques de maillage cachés
En plus de cacher des objets de jeu, vous pouvez maintenant également cacher temporairement des faces de maillage.
UX de l'Outil Primitif
L'outil primitif dans notre outil de cartographie avait besoin d'être amélioré, donc j'ai collaboré avec la communauté pour proposer quelque chose de plus agréable.
Ajouter une échelle d'importation avec des présélections d'unités
Une petite fonctionnalité demandée par les utilisateurs, l'échelle d'importation est maintenant incluse dans l'assistant de création de modèle.
ModelDoc : remplissage automatique des textures de matériaux par nom
J'ai mis à jour le fonctionnement du nœud DefaultMaterialGroup et maintenant il peut automatiquement assigner des matériaux si les noms correspondent. Donc, si les noms de matériaux de votre modèle correspondent aux matériaux de votre projet, ils seront remplis automatiquement.
Auparavant, cette fonctionnalité de remplissage automatique ne fonctionnait que si les emplacements de matériaux dans le modèle avaient un chemin de contenu complet, ce qui n'est évidemment pas très pratique pour les artistes. Maintenant, cela fonctionne également avec des noms de matériaux simples.
Cet outil fonctionnera tant que les conditions suivantes sont remplies : 1) l'emplacement de matériau n'a pas été automatiquement rempli par une autre fonction, comme le remplissage automatique par chemin de contenu, 2) le nom du matériau n'est pas ambigu, ce qui signifie qu'il ne doit y avoir qu'un seul matériau avec ce nom dans votre projet s&box
Création de décalcomanies depuis le menu contextuel
J'ai ajouté une nouvelle option au menu contextuel qui permet de créer rapidement de nouvelles définitions de décalcomanies à partir de la sélection actuelle de textures. Il suffit de sélectionner 1 ou plusieurs images dans le navigateur d'actifs, de faire un clic droit sur elles et de cliquer sur "Créer Décalcomanie".
Le moteur essaiera d'assigner automatiquement toutes les textures aux emplacements de décalcomanie appropriés à partir de la sélection. La seule exigence est que vos textures de décalcomanie doivent avoir des suffixes appropriés ajoutés à la fin de leur nom de fichier, tels que : _color, _normal, _rma, _emissive, _height. Par exemple, "my_custom_decal_color.png" sera assigné à un emplacement de couleur.
Vous serez informé dans une fenêtre contextuelle si quelque chose s'est mal passé lors de la création de la décalcomanie, cela se produira généralement si l'une des textures de décalcomanie a des suffixes incorrects ou manquants. Cet outil devrait rendre la création de décalcomanies un processus beaucoup moins fastidieux, le transformant essentiellement en une procédure rapide en deux clics.
Optimisation des rappels d'événements de physique
Les événements de collision sont maintenant beaucoup plus rapides, et beaucoup plus rapides lorsque les corps sont inactifs.
Chaque événement coûtait son propre rappel géré plus quatre appels dans le natif. Maintenant, tous les événements sont regroupés en un seul appel par étape physique.
Cela entraîne un petit changement de comportement : les événements de mise à jour de collision ne sont plus envoyés pour les contacts inactifs.
Unity a les mêmes sémantiques pour OnCollisionStay.
Si vous avez besoin de l'ancien comportement, PhysicsBody.AutoSleep = false le ramène.
Encombrement sur les cartes publiées
Auparavant, l'encombrement peint ne se chargeait pas correctement dans les cartes publiées car ses données étaient stockées au niveau de la scène plutôt que directement dans la carte.
Les instances de carte peuvent maintenant appliquer des remplacements temporaires du Système d'Objets de Jeu. Ces remplacements sont annulés lorsque la carte est déchargée, empêchant les données spécifiques à la carte de polluer la scène principale.
Merci à @Pol pour cette contribution !