C'est mon truc.
Le Game Jam a attiré plus de 200 participations. Des améliorations ont été apportées au menu et aux fonctionnalités de groupe.
Progression du Game Jam
Le Game Jam est en cours depuis 19 jours et nous avons eu plus de 200 participations. Nous sommes tous assez impressionnés par la qualité de certaines de ces participations.. et il est vraiment évident que nous aurions dû organiser un Jam il y a 6 mois. Nous allons certainement en faire un événement régulier à partir de maintenant.
C'est la première fois que nous mettons en place ce système de nomination et de vote, donc nous gérons les choses en arrière-plan et corrigeons les problèmes au fur et à mesure. Il y aura toujours de petits problèmes qui apparaîtront et nous faisons de notre mieux pour y répondre.
Les nominations se termineront ce dimanche et les jeux les plus nominés entreront dans la phase de vote. À ce moment-là, c'est un knockout chaque jour. La communauté votera sur chaque jeu, et celui avec le plus bas nombre de votes sera éliminé. Les votes seront réinitialisés, et nous voterons sur le reste. Jusqu'à ce qu'il ne reste qu'un seul gagnant.
Cela pourrait être un désastre total, mais j'ai hâte de voir comment cela se passe.
Améliorations du Menu Principal
Quelques petites améliorations sur le menu cette semaine. Les récompenses s'ouvrent maintenant dans une fenêtre contextuelle compacte au lieu d'une page entière, les aperçus des jeux sont plus réactifs, et nous avons corrigé un problème avec le menu qui était beaucoup trop petit à des résolutions plus élevées (1440p+), ainsi que de petites améliorations de style sur la majorité des pages.
Nous avons également corrigé un autre problème avec l'écran de chargement, où vous aviez deux écrans de chargement empilés en même temps.
Améliorations des Groupes
Nous supportons maintenant des groupes de jusqu'à 16 personnes, contre 8 auparavant. Nous avons également effectué un passage de visibilité, donc il est plus évident ce qui se passe lorsque le leader de votre groupe rejoint un jeu.
Vous pouvez annuler votre participation sans quitter le groupe, ou réessayer si quelque chose ne va pas. Nous avons également corrigé des problèmes de suivi du leader entre les jeux, des invitations en double et le nettoyage de la connexion Steam, avec des erreurs plus claires lorsque la connexion échoue.
GUIDs de Ressources
Nous donnons aux actifs une identité stable, donc vous pouvez déplacer ou renommer des fichiers sans casser les références.
Chaque actif aura maintenant un GUID stocké à côté de lui dans un fichier .meta, et toutes les références à cette ressource stockeront cet ID avec le chemin. Au chargement, nous essaierons de résoudre la ressource par cet ID en premier, et de revenir à l'ancien chemin si nécessaire.
Il est important que vous incluiez ces .metas dans votre contrôle de source. Si vous ne le faites pas, tout le monde sur votre dépôt finira avec des ID différents pour le même actif, et ce n'est pas ce que vous voulez.
C'est la première partie du travail, couvrant l'infrastructure de base et les références des types GameResource, y compris la plupart du système de scène et des Prefabs. Les références des formats Valve (comme les matériaux référencés à l'intérieur d'un modèle) sont encore à faire.
Nous continuerons à étendre le support jusqu'à ce que tout utilise ce nouveau système, mais soyez simplement prudent pour l'instant, et probablement ne réorganisez pas encore tout votre projet. Nous y arriverons.
TLDR: Les actifs ont maintenant des ID permanents, donc déplacer ou renommer des fichiers ne cassera pas les choses qui pointent vers eux. Assurez-vous simplement que les
.meta
fichiers voyagent avec vos actifs et vont dans le contrôle de source.
Scripting v0.1
J'ai ajouté un système de script. C'est comme une version c# de Lua. C'est expérimental et je vais itérer dessus. Ce n'est pas sa forme finale mais n'hésitez pas à l'essayer. Il est livré avec un ScriptControl avec coloration syntaxique pour éditer le script.. c'est un contrôle basé sur des panneaux donc il peut être utilisé dans le jeu.
L'idée est d'ajouter quelque chose qui peut exécuter des scripts en place. Cela fera partie de Doo, et facilitera la transition depuis ActionGraph pour beaucoup de gens. Je veux également l'intégrer dans l'éditeur de matériaux afin qu'il permette des expressions dynamiques sur les propriétés.
TLDR: Le scripting est là. Vous écrivez dans un éditeur de code intégré et les changements s'exécutent en direct au fur et à mesure que vous tapez, donc retour d'information instantané au lieu de construire/reconstruire tout le projet. C'est aussi une alternative textuelle aux graphes de nœuds visuels (ActionGraph) que les gens utilisaient.
Docking de Panneaux
Le système de panneaux a maintenant un système de docking intégré.. si vous le souhaitez. Vous pouvez l'utiliser dans vos jeux. Vous pouvez faire les choses habituelles, redimensionner les panneaux, faire glisser d'une section à l'autre. Fonctionne comme tous les autres systèmes de docking créés au cours des 10 dernières années.
Nous utiliserons cela lorsque l'éditeur passera de Qt à Panels.
Éditeur de Courbes de Panneaux
Un nouvel éditeur de courbes basé sur des panneaux CurveEditor vous permet d'éditer des courbes, tout comme celui de l'éditeur. Eh bien, c'est un mensonge. C'est mieux que celui de l'éditeur.
Gestion des Fenêtres en C#
Nous avons transféré la propriété des fenêtres de jeu et de panneau en C#. La création, le redimensionnement et la présentation des fenêtres sont maintenant gérés avec le code PanelWindow, avec le routage des événements SDL, les curseurs et les connexions de contrôleur gérés là aussi.
Les liaisons de touches, la configuration de la console et l'exécution de scripts de configuration ont déménagé avec elles. Cela rapproche plus de la couche d'application dans le même code source que le travail basé sur des panneaux de l'éditeur et élimine une quantité substantielle de code de fenêtre et d'entrée natifs dupliqués.
TLDR: La gestion des fenêtres et des entrées a été déplacée hors du vieux code natif, réduisant une charge de code dupliqué et mettant plus de l'engin au même endroit.
Pilotage de Caméra
Vous pouvez maintenant piloter une caméra directement depuis la vue de scène. Sélectionnez une caméra et cliquez sur Piloter dans sa fenêtre d'aperçu pour la déplacer avec les contrôles habituels de la vue. La vue utilise les paramètres de cette caméra, avec un cadre 16:9 et des guides de tiers pour aider à cadrer votre prise de vue.
C'est particulièrement utile pour enregistrer le mouvement de la caméra dans Movie Maker. Appuyez sur Alt+F8 pour commencer ou arrêter l'enregistrement pendant que vous pilotez, puis utilisez l'outil de lissage pour nettoyer tout mouvement soudain. Appuyez sur Échap lorsque vous avez terminé le pilotage.
Corrections d'Enregistrement de Démo
L'enregistrement de démo en jeu (en utilisant la commande movie) capture maintenant plus précisément votre scène. Nous avons ajouté le support pour le brouillard et les composants de skybox, et divers bugs avec les modèles de vue à la première personne ont été corrigés.
L'exportation vidéo a également été améliorée, pour lorsque vous avez terminé d'éditer vos démos dans Movie Maker. L'encodeur ne devrait maintenant jamais sauter de frames, vous offrant un mouvement parfaitement fluide.
Sprites dans Painter
Painter peut maintenant dessiner des sprites animés. Une nouvelle SpriteInstance suit la lecture indépendamment de l'actif de sprite lui-même. Cela vous permet de dessiner des sprites dans vos panneaux et sur votre HUD sans avoir besoin de faire quoi que ce soit de spécial.
Configuration Rapide de Modèle + Matériau
Lors de la création d'un modèle à partir du menu contextuel dans le navigateur d'actifs, vous pouvez utiliser Essayer de générer des matériaux pour configurer automatiquement les matériaux pour votre modèle.
L'éditeur scannera le dossier du modèle (et ses sous-dossiers) à la recherche d'ensembles de textures correspondants, créera un nouveau matériau basé sur le shader choisi, et mettra toutes les textures trouvées dans les emplacements appropriés.
Vos textures dans un ensemble doivent suivre un motif spécifique.
- Leur nom de fichier doit se terminer par un suffixe, comme
_color,_normal,_roughetc... Ces suffixes doivent correspondre à ce qui est attendu par le shader, vous pouvez vérifier cela dans l'Éditeur de Matériaux. - Les textures doivent commencer par un nom qui correspond au nom de l'emplacement du matériau dans le modèle. Donc si vous avez assigné un emplacement de matériau à votre modèle dans Blender avec un nom
my_cool_material, alors l'ensemble de textures pour cet emplacement doit également commencer par ce nom. Par exemple,my_cool_material_color. L'éditeur prend en charge n'importe quel nombre d'emplacements de matériaux, il générera un matériau pour chaque emplacement tant que le modèle a tous les ensembles de textures nécessaires fournis.
Cela devrait fonctionner avec tous les shaders, y compris les personnalisés, tant que votre shader déclare correctement le nom de suffixe attendu dans les emplacements d'entrée de texture. (voir la documentation pour les attributs de shader)
Cette fonctionnalité n'est pas un remplacement pour quoi que ce soit, c'est juste un flux de travail alternatif que vous pouvez utiliser pour une configuration rapide de modèle + matériau.
Plus de Canaux UV
Les shaders personnalisés peuvent maintenant accéder aux troisième et quatrième canaux UV d'un modèle via les sémantiques d'entrée de vertex LowPrecisionUv2 et LowPrecisionUv3.
Ils ne sont pas disponibles dans votre shader par défaut, vous devez les ajouter dans votre structure VertexInput dans le shader d'abord. Voici comment vous pouvez ajouter UV2/UV3 en plus de l'entrée de vertex standard :
VS
{
// Ajout de champs pour les canaux UV2/UV3 en plus de l'entrée de vertex standard
#include "common/vertexinput.hlsl"
float2 vTexCoord3 : TEXCOORD4 < Semantic( LowPrecisionUv2 ); >;
float2 vTexCoord4 : TEXCOORD5 < Semantic( LowPrecisionUv3 ); >;
}Il y a aussi une page de documentation couvrant toutes les sémantiques d'entrée de vertex (et plus d'informations sur ce qu'elles font)
Shaders Plus Petits
J'ai considérablement réduit la taille et les temps de compilation des shaders en implémentant les constantes de spécialisation Vulkan et en marquant diverses combinaisons statiques (variantes de shader) comme telles. Cela nous permet de supprimer le travail répété et le code de variante de shader de la compilation de shader, il y aura toujours le même nombre de pipelines à l'exécution.
Lorsqu'appliqué à complex, le nombre de tâches de compilation de PS passe de 5728 à 856, la peau passe de 512 à 128.
Cela signifie une réduction substantielle du travail de compilation de shaders, passant de 6 minutes à 1 minute.
C'est bien loin de l'époque où complex.shader prenait 20 heures à compiler.
En plus de la réduction des combinaisons, les shaders compilés stockent maintenant des modules partagés une fois par programme de shader, plutôt que de répéter le même bytecode à travers les combinaisons. Les modules et les données de réflexion sont compressés ensemble par groupes, et chaque combinaison conserve une référence au code qu'elle utilise.
Tout cela ensemble nous donne une réduction massive de 129,88 Mo à 10,80 Mo pour nos shaders expédiés.
TLDR: Les fonctionnalités de shader qui ne changent que le comportement (pas les entrées) peuvent maintenant partager du code compilé au lieu que chaque combinaison ait besoin de sa propre construction, réduisant le shader complexe de 5 728 tâches de compilation à 856, ce qui représente une énorme réduction du temps de compilation des shaders.
Artifacts de Rendu Bindless
Correction des artefacts en blocs et en taches que certaines personnes voyaient autour des sondes d'environnement, des ombres et d'autres éléments, en particulier sur les cartes AMD RX 6000. Le GPU était autorisé à traiter un index de texture comme uniforme lorsque différents pixels pouvaient en fait demander des textures différentes.
Le Bindless permet à un shader de choisir une texture par son index dans un grand tableau. Les GPU exécutent des invocations de shader ensemble en groupes appelés vagues. Si cet index varie à travers une vague, la recherche doit être marquée NonUniformResourceIndex. Si vous manquez cette annotation, le GPU peut échantillonner la mauvaise texture. Cela peut sembler correct sur votre machine et se transformer en désordre sur celle de quelqu'un d'autre.
Notre API Bindless applique maintenant ces annotations automatiquement à chaque étape de shader.
Texture2D texture = Bindless::GetTexture2D( textureIndex );
La sécurité est la priorité par défaut. Mais si vous êtes vraiment sûr que l'index est le même à travers la vague, vous pouvez opter pour le chemin rapide uniforme. Ce n'est pas un gain de vitesse garanti en aucun cas.
cbuffer DrawConstants
{
uint g_nTextureIndex;
};
// Cet index est partagé par le tirage, donc utilisez le chemin uniforme.
Texture2D texture = Bindless::GetTexture2D( UniformIndex( g_nTextureIndex ) );Échantillonnage de Matériaux de Terrain
Pendant longtemps, nous avions presque tout le code d'échantillonnage de terrain coincé dans le shader de terrain standard. Maintenant, il a été déplacé vers le reste de notre API de terrain, et vous pouvez l'utiliser dans presque n'importe quel shader, pas seulement le terrain.
Pour l'utiliser dans votre shader, incluez terrain/TerrainCommon.hlsl dans la section de shader pixel (PS) et utilisez simplement Terrain::Sample( float3 WorldPosition, bool bUseGeometricNormals ). Cela renverra une structure Material contenant le matériau de terrain mélangé avec toutes les textures - albédo, rugosité, normal, occlusion ambiante, etc...
Le deuxième argument décide s'il doit copier les normales géométriques cuites du terrain ou non - il est faux par défaut. Cette fonction renverra un splat de terrain qui est visuellement identique à ce que vous voyez sur le maillage de terrain lui-même, reflétant pleinement tous les paramètres de terrain et de matériau également. C'est ce que le shader de terrain principal utilise maintenant aussi !
J'ai également écrit une assez grande page de documentation couvrant la plupart de notre backend de terrain - il est probablement juste de prévenir que ce n'est pas une API finale, et que les choses peuvent changer, mais cela devrait suffire si vous souhaitez écrire des shaders de terrain personnalisés, ou faire quelque chose de plus complexe.
Corrections d'Exportation Autonome
L'autonome a reçu un peu d'amour cette semaine. Nous avons corrigé le problème de lancement des jeux exportés qui avaient des icônes personnalisées. Nous intégrons également le fichier de projet s&box et d'autres métadonnées dans le .exe, pour nettoyer le dossier des actifs.
Les exports incluent maintenant les assemblages de jeu compilés sans les archives source CLL accompagnantes ou la documentation XML.
Les données de jeu autonome utilisent également directement la racine des données, évitant un dossier supplémentaire par jeu. Merci à boxrocket6803 pour la correction du dossier de données.
Améliorations des Ombres
Nous avons reçu d'excellentes corrections d'ombres de la communauté cette semaine, couvrant à la fois l'apparence des ombres directionnelles et certains bugs de rendu distrayants.
Ombres douces qui restent réellement douces
Le paramètre de dureté des ombres pouvait cesser de faire une différence dans les cascades d'ombres directionnelles éloignées. Même avec la dureté réglée sur zéro, le résultat pouvait sembler presque identique au réglage le plus dur. PolEpie a corrigé le clamping afin que le contrôle de douceur fonctionne à distance aussi.
Faites glisser le séparateur pour comparer la même vue à Dureté des Ombres 0, avant et après la correction.
Bords d'ombres dures plus lisses
Un autre changement de PolEpie réduit les dents répétées le long des bords d'ombres directionnelles dures à la plus haute qualité de filtre d'ombre. Le filtre se transitionne à mesure que la dureté augmente, gardant l'apparence douce d'origine à dureté zéro et utilisant le même maximum de 16 échantillons de comparaison.
Ces captures avant/après incluent toutes deux la correction de dureté de cascade ci-dessus, donc elles montrent l'amélioration de filtrage supplémentaire. Les qualités de filtre d'ombre inférieures et les lumières locales conservent leur filtrage existant.
Fini les lignes sombres mouvantes
Les scènes avec plusieurs lumières locales projetant des ombres pouvaient montrer des lignes sombres sur les surfaces qui se déplaçaient lorsque la caméra bougeait. CorentArts a retracé cela au calcul de la normale du récepteur d'ombre à l'intérieur d'une boucle de lumière, où des pixels voisins pouvaient prendre des chemins différents.
Nous calculons maintenant cette normale avant la boucle et la transmettons au code d'ombre. Les shaders personnalisés peuvent faire de même avec les nouvelles surcharges de normale explicite sur Light::From, Light::Init et Light::Shadows. Merci à CorentArts pour la correction et à tous ceux qui ont fourni des exemples dans le rapport original.
Vues orthographiques
Sam a également corrigé les ombres en espace écran déformées dans les vues orthographiques. Cette technique suppose une caméra perspective, donc nous ignorons maintenant son masque d'ombre pour les caméras orthographiques.