Extension du pipeline de rendu Unity 5 : Tampons de commande

Dans Unity 5, nous avons ajouté de nombreuses fonctionnalités graphiques visibles par l'utilisateur (nouveau shader standard, éclairage global en temps réel, sondes de réflexion, nouveau flux de production de lightmapping, etc.), mais nous avons aussi travaillé sur le rendu interne. En plus d'éléments typiques tels que « l'optimiser » (par exemple gommage multithread) et « le rendre plus cohérent » (par exemple plus cohérent entre les espaces colorimétriques Linear et Gamma), nous avons également cherché à le rendre plus flexible.

En interne et au sein du groupe de test bêta, nous avons discuté de différentes approches. Beaucoup d'idées ont circulé : plus de rappels de scripts, l'assemblage de petits tampons « voici une liste de choses à faire », la possibilité de créer des pipelines de rendu complets à partir de rien, une sorte d'arbre visuel/des outils de construction de pipelines de rendu de graphes, etc. Pour Unity 5, nous avons décidé de créer des tampons de « liste de choses à faire », que nous avons surnommés « Command Buffers ».

Un buffer de commandes dans les graphismes est une liste de commandes de bas niveau à exécuter. Par exemple, les API de rendu 3D comme Direct3D ou OpenGL finissent généralement par construire un tampon de commande qui est ensuite exécuté par le GPU. Le moteur de rendu multi-thread de Unity construit également un tampon de commandes entre un thread appelant et le "worker thread" qui soumet les commandes à l'API de rendu.



Dans notre cas, l'idée est très similaire, mais les "commandes" sont un peu plus élevées. Au lieu de contenir des éléments comme « définir le registre interne du GPU X à la valeur Y », les commandes sont « Dessiner ce maillage avec ce matériau », etc.

À partir de vos scripts, vous pouvez créer des tampons de commande et y ajouter des commandes de rendu (« définir une cible de rendu, dessiner un maillage, ... »). Ensuite, ces tampons de commande peuvent être configurés pour s'exécuter à différents endroits pendant le rendu de la caméra.

Par exemple, vous pouvez transformer certains objets supplémentaires en tampon G d'ombrage différé une fois que tous les objets habituels sont terminés. Vous pouvez également afficher des nuages immédiatement après le dessin de skybox, mais avant toute autre chose. Vous pouvez également transformer des éclairages personnalisés (éclairages de volume, négatifs, etc.) en tampon d'éclairage d'ombrage différé une fois que tous les éclairages réguliers sont effectués. Nous pensons qu'il existe de nombreuses façons intéressantes de les utiliser.

Consultez les pages CommandBuffer et CameraEvent dans la documentation de l'API scripting.

D'accord.

Par exemple, nous pouvons faire des réfractions floues :

Après le rendu des objets opaques et de la skybox, l'image actuelle est copiée dans une cible de rendu temporaire, floutée et configurée en tant que propriété de shader global. Le shader sur l'objet en verre échantillonne ensuite l'image floue, avec décalage des coordonnées UV basé sur une carte normale pour simuler la réfraction. C'est similaire à ce que fait Shader GrabPass, sauf que vous pouvez faire des choses plus personnalisées (dans ce cas, le flou).

Autre exemple d'utilisation : les éclairages différés personnalisés. Voici des éclairages en forme de sphère et de tube :

Après un passage régulier différé de la lumière d'ombrage, une sphère est dessinée pour chaque lumière personnalisée, avec un shader qui calcule l'éclairage et l'ajoute à la mémoire tampon d'éclairage.

Autre exemple : les decals différés.

L'idée est : une fois le tampon G terminé, dessinez chaque « forme » du decal (une boîte) et modifiez le contenu du tampon G. C'est très similaire à la façon dont les lumières sont faites en ombrage différé, sauf qu'au lieu d'accumuler l'éclairage, nous modifions les textures de la mémoire tampon G.

Chaque décalque est implémenté ici sous forme de boîte et affecte toute géométrie à l'intérieur du volume de la boîte.

En fait, voici un petit dossier de projet Unity (5,0 bêta 22) qui démontre tout ce qui précède : RenderingCommandBuffers50b22.zip.

Vous pouvez voir que tous les cas ci-dessus ne sont même pas complexes à implémenter - les scripts font environ une centaine de lignes de code.

Je pense que c'est excitant. Hâte de voir ce que vous en ferez tous !