GPGPU avec OpenGL : Exploitation du z buffer ou d'une texture 3D

Bonjour

e travaille actuellement sur un code de lancer de rayon, et je dois absolument optimiser une certaine partie de monde code.

Il s'agit de la fonction find_first, qui à partir de mon maillage détermine quelle est le premier tetrahèdre par lequel passe le rayon.

Je ne suis pas la pour discuter de la méthode du lancer de rayon, et si vous ne connaissez pas c'est pas grave, mais en substance mon code actuel sur cpu ne faisait que parcourir l'ensemble de tétraèdre de bordure pour chaque rayon pour tester sur le rayon passe dedans.

L'idée serait d'utiliser les spécificités des cartes graphiques en particulier l'optimisation en terme de projection qu'on les cartes graphiques.

Je sait que OpenGL me permettra de projeter très facilement mes tétraèdres de bordures.

En cherchant un peu j'ai vu qu'il existait deux choses qui me permettrait de détourner l'utilisation d'openGL.

Soit le Z_buffer qui me permettrait de connaitre la "profondeur" de la couleur à afficher sur le pixel

Soit la texture 3D....dont j'ai compris la finalité graphique mais que je ne voit pas comment exploiter, mais qui me parait plus puissant.

A la fin j'aimerais idealement récuperer un tableau a trois dimension de taille largeur pixel *longueur pixel*profondeur . Largeur pixel et longeur pixel correspondent à mon ecran et IDEALEMENT on trouverait dans profondeur l'identifiant du tetrahedre de bordure traversé ( vu que le maillage n'est pas obligatoirement convexe, on peut en avoir plusieurs ), ces identifiants etant ordonné en fonction de leur profondeur.

Pensez vous que cela soit faisable?

Que me conseillez-vous comme methode ? Z-buffer? texture3D? Autre chose?

Auriez vous un lien quelconque pouvant m'aider dans cette idée?

Merci beaucoup.

Citation:

---

Envoyé par GloW_on_dub

A la fin j'aimerais idealement récuperer un tableau a trois dimension de taille largeur pixel *longueur pixel*profondeur .

---

Juste par curiosité ta profondeur ferait quelle taille ?

Sinon pourquoi ne pas utiliser les division de l'espace (octree, quadtree) afin d'améliorer justement la fonction de détection d'intersection ?

Citation:

---

Envoyé par GloW_on_dub

Je sait que OpenGL me permettra de projeter très facilement mes tétraèdres de bordures.

En cherchant un peu j'ai vu qu'il existait deux choses qui me permettrait de détourner l'utilisation d'openGL.

Soit le Z_buffer qui me permettrait de connaitre la "profondeur" de la couleur à afficher sur le pixel

Soit la texture 3D....dont j'ai compris la finalité graphique mais que je ne voit pas comment exploiter, mais qui me parait plus puissant.

---

Les GPUs sont très rapides à tracer des triangles parce qu'ils utilisent la rasterisation et non le lancer de rayon. Le ZBuffer sert à calculer l'occlusion rapidement et de manière incrémentale ce qui est fait de manière très différente en ray tracing (on ne revisite pas un pixel déjà tracé).. Donc ton approche qui tenterait de combiner les deux serait en un sens contradictoire. Ceci dit, l'un des intérêts de la rasterisation c'est la rapidité du calcul des premières intersections, donc une approche "hybride" pourrait être tentée (rasterisation pour les premières intersections et suivi des rayons secondaires). Mais c'est loin d'être gagné (duplication des données de la scène ? comment lancer les rayons depuis le GPU ? utiliser un buffer intermédiaire avec rayons secondaires et et le rapatrier pour le traiter sur le CPU ?)..

Pour ce qui est du raytracing pur, utilliser le GPGPU (avec Cuda par exemple) est une approche intéressante :
http://www.nvidia.com/object/optix.html

Pour ce qui est des textures en volume.. Elles n'ont rien de particulièrement magique c'est juste une structure de donnée (indexées en trois dimensions s,t,r). Si tu as des données qui sont mieux représentée en trois dimensions (sans faire exploser la consommation mémoire) alors elles sont utiles.

LeGreg

J'ai en projet un peu près ce que tu expose mais moi j'ai décidé de partir du principe de l'octree, puis charger l'octree en mémoire puis faire un lancé de rayon avec cuda => un kernel par rayon donc tu peux en lancer un certain nombre en même temps ce qui accélère vraiment le lancé.
Pour l'instant, je suis qu'à la théorie donc je n'ai pas de code a proposer.

Désolé pour le retard de réponse.
Depuis ce premier message je suis beaucoup mieux informé , j'ai donc dit quelque connerieset j'ai commencé deja a coder certaines choses, je reviendrai dessus après.

Deja je dois recentrer certaines choses, je ne pose pas de questions sur le RayTracing, d'ailleurs en l'occurence je fait du volume Renderring en RayCasting, il n'y a donc pas de rayon secondaire.

L'algo de lancer de rayon tourne pour le moment sur CPU et sera porté en cuda sur GPU plus tard, le problème n'est pas la.

Il s'agit effectivement d'une approche hybride, je tente d'exploiter la rapidité de la rasterization pour otpimiser une certaines parties du code de l'algorithme de lancer de rayons.

Pour lancer une rayon sur un maillage, je dois d'abord determiner quel tetrahedre le rayon vas traverser en premier( il s'agit du find-first).
Il sepropage ensuite dans le maillage de proche en proche ( ca c'est notre algo)

J'ai un code fonctionnel (bientot) pour recuperer le premier tetrahedre heurté par le rayon par rasterisation, je dois finir de le tester et ensuite tester sa rapidité.

J'ai cependant un autre probleme.

Rien ne me dit que le maillage soit convexe. le rayon peut tres bien ressortir puis rerentrer dans le maillage.

Donc lorsque je projette le pixel d'un certain tetrahedre sur l'écran, je doit conserver la couleur du pixel, meme si elle est caché par un autre pixel qui serait devant.

et je doit de plus compter le nombre total de tentative d'affichage de pixel 3D pour chaque pixel de l'ecran.

Je n'ai pour le moment pas trouvé de solution theorique a ce probleme.

Peut etre est-ce avec les Texture3D.

voila, si vous n'avez pas compris une partie de mes explication, n'hesitez pas a demander.


@Wax :
-Profondeur theoriquement ilimité (imaginons un maillage un forme de sinusoide infini ) en pratique 3 ou 4.
-Octtree, quadTree, KDtree ont été envisagés, mais une approche originale parrassait plus interessantes et permettrait de faire la difference en terme de performances ( dans l'implementation actuelle, le recherche du premier tetrahedre prend 90% du temp, on arbre permettrait de reduire considerablement ce temp...mais pas trop non plus :D)

@AuraHxC:
Je ne fait pas d'octree désolé. Par contre je serai ravi d'achanger lorsque je bosserais sur le portage parrralele du code en CUDA.

En rasterisation il n'y a pas de miracle pour le moment... Si tu veux avoir toutes les "couches" de ton maillage sur ton "ecran", il faut appliquer la meme technique pour que la gestion d'objets transparents, par exemple la technique dite du depth-peeling. Donc je te conseille de t'orienter vers tous les algos qui tentent de gerer les objets translucides.

Si tu peux limiter le nombre maximum de couches: 2, N? Le depth peeling pourrait etre une solution. Sinon tu peux aussi envisager de ne conserver que le premier et dernier hit, dans ce cas tu peux facilement l'avoir rapidement en bien configurant le culling directionnel des faces et le z-buffer, ce qui pourrait deja etre une bonne approximation pour ton algo.

Un probleme si je tente d'utiliser la transparence. Les index de me tetraherde sont codés dans la couleur en RGBA.

Ainsi le transparence des objets n'as aucun sens reele, et je ne peut d'ailleurs y toucher, sauf en considerant que l'on reduit le nombre de tetra possible dans mon maillage.

Le culling me parait interessant et me peremetrrait en deux passe de recuperer le premier tetra d'entrée et le premier de sortie, ce qui n'est pas mal déja. mais quel rapport ici avec le z-buffer.

J'ai envisagé d'autre possiblités, comme je le disais avant , les textures 3D, mais je n'arrive pas a trouver grand chose d'explicite sur leur fonctionnement et si même je peut faire ce que je veux avec.

ensuite, si j'ai bien suuivi le fonctionnement des shader, un fragment shader est appellé pour chaque pixel 3D de la scene ( et non pas un pour chaque pixel de l'ecran ) en consequence, il y a un moment ou je peut tenir cette couleur du pixel mais il faudrait que je trouve quelque part ou la mettree et pour le moment...j'ai pas vu comment faire.

Je viens de passer de RGB8 en RGB16 histoire de me liberer quelque bits d'information, en particulier la transparence pour tenter de faire du depth peeling, pour le moment je n'ai pas trouvé grand chose de probant comme tutorial au sujet de cette technique.

Par contre je me demande si il y a une perte significative de vitesse de RGB8 a RGB16.

Je viens de comprendre le fonctionnement du depth peeling.

Et ca n'as rien a voir avec la composante alpha de mes triangles.

Citation:

---

Envoyé par GloW_on_dub

Par contre je me demande si il y a une perte significative de vitesse de RGB8 a RGB16.

---

cela dépend 1- de l'architecture 2- de ton bottleneck.

En 16bits par canal, tu doubles les besoins en bande passante mais aussi certaines architectures ne peuvent pas traiter le filtrage 16 bits par canal à la même vitesse que le filtrage 8 bits par canal (le chemin utilisé dans la puce n'est pas le même. ou s'il y a réutilisation elle se fait avec une perte d'efficacité).
Ceci dit si tu n'es limité 1 - ni par la bande passante en lecture (ou si le cache est efficace), 2 - ni par la latence/temps de lecture (qui peut-être cachée par un plus grand ratio math/tex ainsi que par le nombre de threads parallélisables), ou si un autre élément de ton pipeline domine (vertex stage, setup, cpu, rop ou autres), alors tu ne verras pas forcément une trop grande différence au niveau perf.

Ceci dit, passer de 8 bits à 16 bits c'est souvent imposé par la précision requise, si tu passes outre tu risques des artefacts et en contrepartie si tu ne vois pas d'artefacts quel que soit ton choix, ça veut dire que tu devrais prendre la version la plus rapide. J'enfonce des portes ouvertes..

LeGreg