Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - buzzkaido

Pages: [1]
1
Code / Displacement & normal maps
« on: 23 May 2013 à 20:56:28  »
Salut !

J'utilise plusieurs passes de rendu comme ça :

- une passe pour dessiner des "particules" contenant une map de displacement, dans un buffer A (RGB_32F)
- une passe pour dessiner des "particules" contenant une map de normales, dans un buffer B (RGB_32F)

Ensuite je fais le rendu de la scene en "plaquant" dessus les displacement et les normales issues des buffer A et B.

Du coup :

- le buffer A est en blending additif
- le buffer B est en blending additif

=> pour les displacements, ça marche très bien
=> pour les normales, ça déconne...

J'ai identifiés quelques soucis sur les normales, notamment concernant le repère dans lequel elles sont exprimées, mais avant d'aller trop loin dans le debug de mon code, est-ce que c'est correct d'additionner des normales ?

Je procède comme ça lors du dessin des particules :
- toutes les normales sont exprimées dans le même repère (à cette étape là, j'en suis certain)
- toutes les normales sont normalisées

Et lors de la passe de rendu des normales, si 4 particules écrivent sur le même pixel, j'ai :

pixel = Normale_1 + Normale_2 + Normale_3 + Normale_4

Et lors du rendu final de la scène, je récupère cette normale, je la normalise, et je l'utilise comme pour faire du bump mapping.

Avec 2-3 schémas vite fait au crayon, j'ai l'impression que ça devrais fonctionner, mais est-ce que c'est "géométriquement correct" ?


Merci !

2
Code / Re : Culling de patch / de primitives sur le GPU
« on: 20 May 2013 à 23:22:07  »
Ben non pas trop, la charge de travail est déjà lourde dans le tesselation evalutation.

Et le problème reste le même : un algo de culling de primitive efficace sur GPU.

3
Code / Re : Culling de patch / de primitives sur le GPU
« on: 19 May 2013 à 21:09:29  »
Merci pour la réponse !

Même si bon, c'est un peu ce que je craignais...

En fait, je cherche une astuce du genre :

1/ dans le vertex shader, placer 6 bits (ou 12 ?) pour chaque plan du frustum, avec 0 ou 1 pour indiquer de quel coté est le sommet
2/ dans le tesselation control shader, un bon vieux mélange de AND, OR, XOR (le shérif de l'espace) pour déterminer le culling très rapidement

Mais bon, je cherche encore.

Sinon, oui, le patch ont du displacement, mais il est appliqué à l'ensemble du patch dans le vertex shader, donc le culling reste valable. Ensuite il y a encore un displacement qui est appliqué à chaque primitive dans le tesselation evaluatation shader, mais l'algo garanti que les sommets ajoutés dans le patch restent "à l'intérieur" du patch initial, donc le culling reste pertinent.

Et pour finir, les calculs appliqués dans le tesselation evaluation shader et dans le fragment shader sont tellement lourds, que oui, ça reste utile de faire du culling.

4
Code / Culling de patch / de primitives sur le GPU
« on: 18 May 2013 à 19:27:58  »
Salut !

J'utilise OpenGL pour exécuter des rendus qui ne sont pas forcement du rendu "traditionnel" mais qui se rapprochent un peu du GP-GPU.

J'ai un algo qui fonctionne bien, mais pour lequel je pourrais augmenter significativement les performances en appliquant un test de culling au niveau de tesselation control shader ou du geometry shader.

Voila comment ça fonctionne, en gros :

1/ Vertex shader :
=> beaucoup de vertex sont traités, un certain nombre inutilement (il ne participeront pas tous au résultat final du calcul), mais l’exécution est très très rapide (cette étape ne fait pratiquement rien, les données sont pré-traitées) donc je ne touche à rien ici.

2/ Tesselation Control shader :
=> ici je calcule des facteur de "raffinement local" du calcul final. Le calcul est relativement lourd mais avec moins d’exécutions (les patchs contiennent 4 vertex), donc ça va, et on ne peut pas vraiment y couper.

3/ Tesselation Evaluation shader :
=> une des étapes les plus lourdes, ici y'a pas mal de trucs à faire

4/ Geometry shader :
=> quelques calculs, mais pas énormes

5/ Fragment shader :
=> une des étapes les plus lourdes, ici y'a pas mal de trucs à faire


Pour l'optimisation, je pourrais éliminer des patchs entiers (ceux qui sortent du frustum de la camera en gros) à la sortie du Tesselation Control en écrivant des facteurs à 0. Du coup, je fais ça :
- dans le vertex shader, je place un booléen à true ou false pour indiquer si le vertex est dans le frustum ou pas
- dans le tesselation control shader, si tous les vertex en entrée sont "pas visible" j'élimine le patch

Ca marche bien... sauf si le patch "croise" le frustum : si 2 vertex sont en dehors d'un coté et 2 autres vertex en dehors de l'autre coté, il faudrait quand même exécuter ce patch mais il se retrouve éliminé.

Du coup je vois pas très bien comment faire le test de culling "complet" pour être sûr de ne jamais éliminer un patch qui ne devrait pas l'être : les algos CPU qui font ce genre de choses me paraissent très complexe à mettre en place dans un shader...

Existe-t-il des "astuces" pour effectuer ce genre de test de culling ?

Et j'aimerais aussi faire la même chose au niveau du geometry shader pour éliminer des primitives produites par le tesselateur mais qui sont finalement inutiles...


Merci d'avance pour les pistes / conseils !

Pages: [1]