Discussion :

[Gregouar]

J'ai mis en place une première version basique de la génération de Points d'intérêts. Du coup, voilà une petite vidéo où je me promène dans le monde et en découvre un:

[Gregouar]

Et pour continuer, génération de chemin entre les points d'intérêts, en utilisant une version modifiée de l'algorithme de Kruskal, du bruit de Perlin et A*.



Et en jeu, ça donne ça:

[Gregouar]

Un petit apercu de ce sur quoi je travail, utilisant la même base que le reste:



Avec un zoom sur la torche parce c'est moi qui l'a fait tout seul comme un grand



Vous pouvez aussi voir du coup que j'ai ajouté du bloom.

[Gregouar]

Pour ceux que ça manquait de Alag, j'ai repris l'idée de faire des contact shadows/ambient occlusion en calculant les bent normals. Il y a encore pas mal de boulot à tweaker les paramètres pour améliorer le résultat mais ça ressemble déjà à quelque chose:


Voilà une comparaison, sans et avec (vous pouvez voir des artefacts au niveau du mur d'ailleurs):


Techniquement parlant, au moment de calculer l'occlusion en screen space pour le SSAO, je fais aussi la moyenne des rayons des rayons qui ne sont pas occludé. Cela me donne une idée de la direction "la moins occludée". Du coup, je le fais en half résolution:


Avec upscale & blur intelligent (basé sur le gbuffer de position):

(Au passage, noté les artefacts de banding, ça montre bien que je dois encore améliorer mon sampling).

Finalement, quand je calcule le lighting, je mixe entre le NdotL (produit scalaire de vecteur normal et vecteur de direction d'éclairage) et le produit scalaire de la bent normal et du vecteur d'éclairage, en fonction de la quantité d'occlusion (qui est aussi utilisée pour l'occlusion de l'éclairage ambiant, mais sans tenir compte des bent normals). J'utilise le minimum entre ce nouveau résultat et l'ancien NdotL comme nouveau NdotL pour calculer mon shading. Cela a pour effet que le côté exposé à la lumière reste inchangé par rapport à avant (donc éclairé), alors que l'autre côté n'est pas éclairé puisque la bent normal pointe dans la direction opposée.

Ce n'est clairement pas aussi précis que des ombres projetées sur une shadowmap, mais le gros avantage c'est que ça a un coût fixe, qui rentre plus ou moins déjà dans le budget du SSAO (je dirais juste qu'il faut lancer un peu plus de rayons que d'habitude pour avoir un résultat "correct"). Vu le nombre de lumières qui peuvent influencer l'écran en même temps (j'atteins facilement plus de 50 avec toutes mes torches dans les environs), je pense que ça ne serait pas raisonnable de calculer une shadowmap pour chacune d'entre elles. En plus, ça m'épargne la peine de devoir commencer à allouer/libérer les shadowmaps quand les lumières arrivent ou sortent de la zone d'affichage.
Bien sûr, en contrepartie, ça vient avec tout un tas de désavantages. Notamment, le fait que c'est beaucoup moins précis et n'affiche des ombres que proches de l'obstacle (d'où le fait que je parle plutôt de "contact shadow").

Je ne sais pas si on s'en rend vraiment compte sur les screen & gifs, mais ça donne quand-même vraiment plus de profondeur à l'image, et surtout du dynamisme (ça fait toujours plaisir quand on voit des ombres bougés alors qu'on passe devant une lumière.


En bonus, je vous poste un gif de l'animation des torches qui s'allument quand on passe. L'idée serait que ça aiderait le joueur à savoir les salles/couloirs qu'il a déjà visité (désolé pour la qualité un peu moisie):