Discussion :

[supercopter]

Combien y'a-t-il de batches sur votre screenshot ?

Normalement c'est un batch par combinaison shader / chunk.

Là je vois un chunk unique donc il ne devrait y'avoir qu'un seul batch par shader. Donc même pas une demie-douzaine de drawcalls. Donc c'est pas normal que ça rame.

[Gregouar]

Déjà j'ai jamais dit que ça ramait ; je cherche juste la manière qui me convient le mieux pour afficher des sprites pour après commencer à réimplémenter tous les autres effets plus couteux. Et justement je disais qu'avec l'instanciation je peux afficher tous mes sprites d'un coup (un seul draw call) à condition de réécrire un VBO à chaque frame (qui contient en gros les infos d'affichage de chaque sprite qu'on veut afficher à cette frame).
Alors qu'avant j'avais testé d'utiliser un dynamic uniform buffer object mais qui alors demandait un draw call par sprite (car tu dois bouger ton offset dynamic pour chacun d'entre eux). Ce qui au final était plus lent même si mon cpu était plus tranquille (je ne devais quasi pas l'utiliser vu que mes command buffers restaient les même, je devais juste éventuellement mettre à jour des morceaux de mon dynamic ubo).

[Gregouar]

Alors pour donner quelques nouvelles, je suis passé par un bug plutôt sympa:


En gros pour ceux que ça intéresserait, c'est parce que dans mon frag shader je faisais un discard des pixels dont l'alpha n'était pas à 1 (100% opaque). Sauf que je passais la couleur (dont l'alpha) du sprite en varying depuis le vertex shader, et le rasterizer apparement prenait ses libertés dans l'interpolation. Du coup quand des vertex sortaient de l'écran, parfois il approximait l'alpha comme plus petite que 1.

Mais maintenant tout ça est réglé et fonctionne plutôt bien; je vais pouvoir commencer à réimplémenter des effets sympas:

[Dabou Master]

Ah ben voilà ! Là mon cerveau sait ce qu'il voit ^^.
T'es un sacré acharné qui bosse très vite ? Ou tu es en plein milieu du genre d'étape très gratifiante avec des résultats très visibles ?

Question bête : ça me rappelle un peu la 3D tout ça, du coup c'est quoi dans ton image là on a juste la première passe pour l'albedo (ou je ne sais pas comment ça s'appelle dans ce cas-là, disons juste les couleurs de base simple sans la moindre fioriture) et ensuite il te faudra rajouter différentes passes pour tout ce qui est réflexion (spéculaire ou autre), AO, etc ?

[Gregouar]

T'es un sacré acharné qui bosse très vite ? Ou tu es en plein milieu du genre d'étape très gratifiante avec des résultats très visibles ?

Disons que j'ai trouvé pas mal de temps cette dernière semaine pour avancer.

Question bête : ça me rappelle un peu la 3D tout ça, du coup c'est quoi dans ton image là on a juste la première passe pour l'albedo (ou je ne sais pas comment ça s'appelle dans ce cas-là, disons juste les couleurs de base simple sans la moindre fioriture) et ensuite il te faudra rajouter différentes passes pour tout ce qui est réflexion (spéculaire ou autre), AO, etc ?

Sur l'image qu'il y avait avant en effet, c'est juste l'albedo qui est présente mais qui utilise quand-même le depthBuffer et la heightmap des sprites pour les intersecter en 3D (et en fait, il y aussi une passe de tone mapping car j'écris d'abord l'albedo dans une map HDR, qui normalement sera générée en fonction de l'éclairage). Ensuite comme tu dis, il faudra ajouter des passes pour mettre tous les effets (lumières, réflections, SSAO, etc) en utilisant les infos stockées dans mes 4 différents buffers: albedo, position, normal, rmt (roughness-metalness-translucency).

D'ailleurs, je viens au passage apporter d'autres nouvelles: j'ai mis au point des outils bien sympas qui me permettent d'ajouter des passes, les lier et les synchroniser en quelques lignes de codes seulement (avec transfert de renderTarget qui peuvent devenir des uniforms). L'idée sera à la fin d'avoir le rendu sous forme d'un graphe avec plusieurs passent qui se font en parallèle (par exemple, génération de la map de SSAO et SSR en parallèle de l'éclairage) et que je peux facilement modifier (notamment pour faire du benchmarking). Pour tester, j'ai ajouté la gestion de la transparence, qui est un peu plus subtile que ce qu'on pourrait croire a priori:



Peut-être que vous vous souvenez mais j'avais expliqué dans la version SFML/OpenGL que je gère la transparence en ajoutant juste une deuxième couche de rendu deferred (donc j'ai 2 fois les albedo, position, normal, rmt): la première couche contient les pixels complètement opaques et la seconde les transparents ; ensuite je peux blender le tout dans la passe de tone mapping par exemple. Cependant, une partie des pixels transparents viennent de l'anticrénelage présent sur les sprites et l'autre vient d'objets réellement transparents. Puisqu'on ne ne peut avoir qu'un pixel transparent par fragment, il faut que je donne priorité à ceux qui ne viennent pas de l'AA (par exemple l'eau si vous vous souvenez). C'est en fait un problème assez difficile à régler de façon efficace. J'ai donc décidé d'ajouter une passe de rendu entre celle qui fait les pixels opaques et les pixels transparent. Cette passe de rendu détecte la présence d'un pixel qui n'est pas d'AA et l'écrit dans un buffer. Après pendant ma passe pour les pixels transparent j'ai juste à regarder s'il existe dans le fragment courant un pixel qui n'est pas d'AA et si c'est le cas je ne dessine pas le pixel actuel s'il est AA. Sinon je donne juste priorité au plus haut (peut-être que j'utiliserai ce système pour même donner priorité aux pixels en fonction de leur transparence, afin que si on a un pixel très très transparent au dessus d'un pas très transparent, je donne priorité au plus opaque).

Du coup maintenant ajouter la plupart de mes effets ne sera qu'une question de GLSL, que je n'ai qu'à recopier de ma version OpenGL. Les prochains gros morceaux qu'il me reste à faire sont l'ajout de vrai 3D dans la scène (pas dur à faire) et la gestion des shadowMaps (je n'ai pas encore trop réfléchi à comment j'allais gérer ça avec Vulkan).

EDIT : Je me suis rendu qu'en fait j'avais mal compris quelque chose: je n'ai même pas besoin de semaphores entre mes renderpass car mes subpass dependencies mettent déjà des barrières automatiquement. Du coup, je n'ai pas besoin d'ajouter une couche de synchronisation manuelle. En retirant toutes ces sémaphores inutiles, ça augmente beaucoup mes performances: je passe de l'ordre de 0.64 ms à 0.45 ms.

[Gregouar]

Ce fut plus facile que prévu:



Pour le moment c'est juste un petit obj loader que j'ai codé mais je verrai plus tard pour utiliser quelque chose de plus sérieux. L'important étant que ça se mixe bien avec la 2.5D (même s'il me reste encore a gérer l'anticrénelage).

[Gregouar]

Désolé pour la qualité du gif, mais je n'ai pas accès au serveur habituel pour le moment:

(On dirait pas comme ça, mais il y a en fait 100 lumières qui tournent)

Au programme des nouveautés j'ai ajouté l'éclairage ambient (sans filtrage pour le moment) et la gestion des lumières omnis. Pour celles-ci, j'ai décidé de changer un peu la méthode que je faisais avant sur la version opengl. En effet, plutôt que de lister les lumières dans un ubo et boucler dans le shader d'éclairage qui se fait sur tout l'écran, maintenant je dessine un hexagone autour de ma lumières qui est sensé englober tous les pixels éclairés (après, la lumières est considérée comme trop loin et donc je la tronque de façon lisse). En exagéré, ça donne ça:


Ca me permet d'éviter de calculer l'éclairage pour des pixels qui ne sont pas affectés par la lumière sans utiliser de branching dans le shader. De plus, ça me permet de dessiner les lumières de la même façon que tout le reste dans le moteur (ie. j'enregistre la lumière dans le vbo qui liste les lumières et je dessine par instancing). J'en ai profité pour aussi ajouter un petit stencil test pour la couche alpha qui me permet de discard tous les fragments qui contiennent des pixels complètement transparents (càd la plupart de l'écran).

[guitz]

Disco Duck lol

Excellentissime, comme d'hab. Keep up the good work

[Gregouar]

Inspiré par cet article: https://80.lv/articles/ssrtgi-toughe...-real-time-3d/
J'ai décidé d'implémenter ma propre version de SSAO basé sur des Bent Normals. L'idée ? Quand on lance des rayons pour calculer l'occlusion ambiante, en plus de compter le nombre qui touchent de la géométrie, on prend aussi la moyenne de l'orientation de ceux qui ne font pas de collision. Dès lors, cette me moyenne me donne une idée de la direction globale qui reçoit le plus de lumière (les autres étant sensées être occludées). Ca ressemble à ceci:


Du coup, au moment de calculer l'éclairage, je peux appliquer un niveau d'AO qui dépend de l'orientation de la lumière (comme on peut voir dans le gif au dessus: l'ombrage ambiant des tonneaux change suivant la position de la lumière). On peut aussi le voir sur cette image, où le soleil ne produit pas d'AO à gauche mais à droite:


En plus, je garde en mémoire la position de plusieurs des points de collision de mes rayons: je les utiliserai ensuite lors du calcule de la lumière ambiante pour simuler une globale illumation avec 1 rebond.

[Gregouar]

J'ai continué à travailler sur l'ambient occlusion. J'ai décidé de partir sur la même idée que ce qu'ils ont fait pour Starcraft 2: je sépare l'AO en deux parties, chacune ayant sa moyenne calculée séparemment.

1. "SSAO" : la première est calculée en ne regardant les collisions que pour le premier morceau des rayons et est appliqué sans prendre compte de la position de la source lumineuse. Cela permet de vraiment mettre en valeur les petits détails et jointures d'objets.
2. "GIAO" : la seconde est calculée en regardant le rayon totale et est appliquée en fonction des bent normals (je rappelles que ce sont des normales qui représentent la direction qui reçoit le plus de lumière et qui permettent donc d'occluder uniquement des zones non-orientées vers la lumières). Cella permet de donner un effet "global illumunation" à la scène.

Ensuite je prends uniquement le minimum des deux. Par ailleurs, j'ai aussi upgradé mon flou gaussien pour le rendre plus intelligent: ainsi maintenant je ne sample plus à l'aveugle pour faire mes moyennes, mais je ne prends en compte que les fragments qui sont assez prochent (je compare juste la position Z). Ca me permet d'éviter d'avoir le flou qui donne un effet de "bleed" sur mon AO. Subtilité de passage: en fait, je n'utilise pas le gbuffer des normal opaques uniquement, mais aussi celles alphas que j'alpha-blend dessus. Ainsi, mon anti-crénelage ne donne pas de sales artefacts.
Petite remarque au passage, j'ai du revoir comment je garde en mémoire mes bents normals. En effet, maintenant mon attachment SSAO contient en RG les valeurs X et Y de mes bents normales, supposées normalisées. Dans le Z, je sauvegarde le signe de la composante Z et la valeur d'intensité du GIAO. Dans le A je save l'intensité du SSAO.

Voici le résultat pour le moment:

Meilleure qualité :
https://i.imgur.com/phNqWe1.mp4

[Gregouar]

Après pas mal d'efforts, je suis de retour avec enfin une pipeline qui me permet de gérer le shadow mapping (des lumières directionnelles uniquement pour le moment) !
J'ai changé un peu la technique par rapport à ce que je faisais sur la version OpenGL: avant je générais une shadow map par sprite 2.5D du côté du CPU, en lisant texel par texel et projetant sur le plan. Du coup en fait, c'est assez précis (même trop par rapport à ce qu'on veut pour une shadow map) et surtout TRES TRES lent. Maintenant, je les génère côté GPU, sauf que évidemment, j'ai du changé la technique (celle que je faisais n'étais pas parallelisable: je ne connais pas à l'avance l'endroit où je vais écrire ma texture). Du coup, je suis parti pour du raytracing en viewspace (du sprite 2.5D). Vu que je n'ai quand-même besoin que de le faire une fois (sauf si la lumière bouge) je peux me permettre de faire du raytracing assez précis (j'ai fait des tests avec 128 steps + 4 binary search). Ca reste quand-même beaucoup beaucoup plus rapide (je peux même le faire en temps réel sur mon laptop).

J'ai aussi ajouté la projection d'ombres des mesh (qui n'est pas précalculée elle, car pas nécessaire et gaspillage de mémoire sinon). Afin de palier au manque d'information du screen-space des sprites (trous dans la shadowmap créés par la superposition de géométrie), j'ajoute à la main des box invisibles qui ne font que projeter de l'ombre et me servent à venir remplir les trous, dans le style (rendu visible pour vos beaux yeux):


L'idée serait qu'en pratique, l'artiste fasse une version box de ses modèles qui ont de grosses ombres (genre les bâtiments).

Au passage, je vous remets un gif comparitif HD entre avec et sans SSGI:


Sinon, il me reste encore pas mal de travail, notamment pour filtrer les shadows maps des sprites (boucher les trous et retirer le bruit). En théorie c'est facile, mais il faut que je trouve comment l'insérer dans ma pipeline de façon pas trop stupide. Je voudrais aussi encore améliorer la qualité du smoothing des ombres qui sont trop bruitées pour le moment à mon goût. Je crois que je devrais pouvoir tweaker aussi encore un peu le SSGIAO pour améliorer le rendu, puis j'ajouterai le GI à un rebond.