A propos de la série de tutoriels Interactive Raytracing

**Matthieu Brucher** · 04/05/2009, 22h53

Je continue à publier des articles sur le sujet du raytracing interactif. Il est vrai que j'ai pris du retard sur ce que je voulais faire, mais je veux saisir ici l'opportunité de discuter sur mon projet, à savoir les tutoriels, les choix que j'ai fait, ce que je compte faire, mais aussi les possibilités à explorer pour une telle bibliothèque.

Voici la liste des tutoriels :

Dans les futurs tutoriels, il y aura :
- passage à des objets triangulés
- optimisation de la structure statique
- intégration des shaders et donc des textures
- pas la suite, on passera à l'intégration des objets dynamiques (à voir)

**IrmatDen** · 07/05/2009, 16h12

Salut,

Content de voir que tu continues d'avancer sur cette série, j'attendais la suite assez impatiemment (surtout pour l'approche utilisant Python que je trouve assez surprenante)

2 questions:

Envoyé par Matthieu Brucher

- kdtree pour les objets statiques

Par la formulation de ce point, je suppose que tu comptes utiliser une autre structure pour les objets dynamiques ; la visite de 2 structures pour un même rayon ne risque-t-elle pas d'être trop couteuse ? Ce serait pas mieux d'avoir une structure peut-être un peu moins optimisée pour les objets statiques, mais qui permette une visite en 1 passe ?

Envoyé par Matthieu Brucher

- intégration des shaders et donc des textures

Quand tu parles de shader, tu fais référence à une VM pour des shaders programmables ou à des BRDF pré-définies combinables ?

**Matthieu Brucher** · 07/05/2009, 16h49

L'approche pour Python, c'est surtout pour me permettre de tester rapidement une scène. Par la suite, je ne pense pas la conserver, ou plutôt je vais créer une application C++ complète (avec Qt

) pour charger des scènes existantes.

En réponse à tes questions :

- je ne sais pas trop encore. Je vais commencer par le kdtree pour les objets statiques, et eux-même auront sans doute leur propre kdtree, optimisé selon ce qu'il sont (à l'aide de builders, il devrait être facile de sélectionner la bonne manière de créer l'arbre). Pour les objets dynamiques, c'est sûr qu'on a un autre problème. En revanche, si je considère que ces objets dynamiques correspondent à des sous-objets statiques, les éléments de cette nouvelle structure (BVH ?) pourront être décrits par des kdtrees. Mais il faudra que je regarde à nouveau la littérature à ce moment. Rien ne m'empêche de changer mon modèle de fonctionnement, ça fera un article en plus

- En fait, ce sera le calcul de la couleur qui sera complètement laissée à un shader sous la forme d'une fonction spécifique à l'objet traversé. Cette fonction permettra de gérer les rayons secondaires à générer (et donc on pourra avoir plusieurs rayons, et non plus un seul rayon réfléchi, ou même des rayons réfractés, échantillonnés selon une loi spatiale, ...) ainsi que le rôle de la lumière. C'est sûr qu'à ce moment, on s'éloignera fortement de l'interactif si on veut des objets avec des shaders complexes.

J'espère avoir répondu à peu près à tes questions

**IrmatDen** · 07/05/2009, 19h44

Yes, je vois mieux où dans quelle direction tu vas, merci des explications

**Matthieu Brucher** · 07/05/2009, 23h27

Envoyé par IrmatDen

Merci des explications

Merci d'avoir lancé les commentaires sur le thread

Et n'hésite pas à commenter sur mes choix par la suite !

**IrmatDen** · 08/05/2009, 01h25

Envoyé par Matthieu Brucher

Et n'hésite pas à commenter sur mes choix par la suite !

Je vais attendre qu'elle arrive, et en profiter pour lire les parties sur les reflets et gui que je n'avais pas vu passer

**Matthieu Brucher** · 08/05/2009, 09h58

Envoyé par IrmatDen

Je vais attendre qu'elle arrive, et en profiter pour lire les parties sur les reflets et gui que je n'avais pas vu passer

Normal, ils n'ont pas été annoncés, effectivement

**IrmatDen** · 14/05/2009, 22h22

Dans le GPU Gems 7, Jacco Bikker (auteur principal d'Arauna) présente une utilisation des kD-Tree dans le contexte de ray queries (pas pour du RTRT, mais à priori ça devrait s'y appliquer). Il part aussi sur un arbre pour les objets statiques et un autre pour les dynamiques.
Ce dernier est simplifié:

In the proposed scheme, the tree containing the dynamic triangles is rebuilt each frame. Using the SAH, determining the split plane position is by far the most expensive part. By fixing plane positions, a tree for the dynamic triangles can be built in very little time. One way to do this is to choose the spatial median for alternating axes. This essentially creates an octree. Using a separate tree for dynamic triangles assumes the scenery contains more static geometry than dynamic geometry, which is generally the case.

Ceci lié à la façon de stocker l'arbre devrait t'intéresser, si tu ne l'as pas déjà lu

**Matthieu Brucher** · 14/05/2009, 22h37

GPU Gems 7 ? Tu as une référence plus précise ?

Ca peut effectivement être une des solutions que j'étudierai pour faire la différence. En revanche, la construction du kd-tree n'est pas, pour moi et pour l'instant, un problème. Si je considère un objet, il est statique, et donc je peux prendre du temps pour faire un bon kd-tree (en choisissant le meilleur plan sur les 3 axes, et non sur un seul comme l'a fait Bikker dans sa série de tutoriels).
Mais c'est vrai que certains objets peuvent être dynamiques, comme les surfaces de l'océan, auquel cas il va falloir songer à une solution

**IrmatDen** · 14/05/2009, 22h43

Envoyé par Matthieu Brucher

GPU Gems 7 ? Tu as une référence plus précise ?

Ouplà, désolé mes mains ont fourchées, je voulais écrire Game Programming Gems

Envoyé par Matthieu Brucher

Ca peut effectivement être une des solutions que j'étudierai pour faire la différence. En revanche, la construction du kd-tree n'est pas, pour moi et pour l'instant, un problème. Si je considère un objet, il est statique, et donc je peux prendre du temps pour faire un bon kd-tree (en choisissant le meilleur plan sur les 3 axes, et non sur un seul comme l'a fait Bikker dans sa série de tutoriels).
Mais c'est vrai que certains objets peuvent être dynamiques, comme les surfaces de l'océan, auquel cas il va falloir songer à une solution

Je ne parlais pas de sa construction (bien que ce soit aussi à prendre en compte et qu'il en parle dans cet article), mais bien du stockage cache-friendly où chaque noeud du KdTree tient en 8 octets

**Matthieu Brucher** · 14/05/2009, 22h46

Ah oui ! OK, je suis d'accord avec toi.
GGP 7, je ne l'ai pas encore, un peu cher, et je ne sais pas si j'aurai suffisamment d'intérêt dedans.

En revanche, cette optimisation est déjà décrite dans la thèse d'Havran que j'utilise. Pour l'instant, je stocke tout en clair, le temps d'avoir quelque chose qui fonctionne, et par la suite, je stockerai les données sur 8 ou 12 octets (je dois stocker un flottant + un pointeur, donc 8 en 32bits et un flottant, 12 en 32bits avec un double ou en 64bits avec un flottant et 16 en 64bits avec un double, même si je ne travaillerai sans doute jamais en double pour avoir de meilleures performances en SSE à terme).

**LeGreg** · 15/05/2009, 23h16

Hors sujet : Ça me rappelle qu'il faut que je mette à jour ma série de tutoriels.. (6 ans déjà..). Mais bon vu le temps que je passe en dehors du boulot, ça risque pas d'arriver de sitôt

. Peut-etre dans six ans ou quand la crise aura piquée tous nos boulots..

Sujet :
J'ai juste une question sur le titre : "lancer de rayon interactif", qu'est-ce qui fait que le programme est caractérisé comme "intéractif" dans le titre ? Est-ce que tu fais ça avec un plan bien défini, tu as un programme qui tourne et tu expliques comment y arriver (ou en te basant sur un autre tutoriel ?) ? Ou est-ce que le but c'est d'apprendre par ses erreurs et ensuite déterminer que ce qu'on faisait au début doit être réécrit pour être interactif ?

Est-ce que l'utilisation du GPU est prévue ?
Exemple d'approche de ray tracing interactif sur le GPU :
http://realtimerendering.com/downloa...T-Overview.pdf

**Matthieu Brucher** · 15/05/2009, 23h37

Envoyé par LeGreg

Hors sujet : Ça me rappelle qu'il faut que je mette à jour ma série de tutoriels.. (6 ans déjà..). Mais bon vu le temps que je passe en dehors du boulot, ça risque pas d'arriver de sitôt

. Peut-etre dans six ans ou quand la crise aura piquée tous nos boulots..

Je connais

J'ai regardé ta série de tutoriels, même si je ne prends pas toujours la même direction

Envoyé par LeGreg

Sujet :
J'ai juste une question sur le titre : "lancer de rayon interactif", qu'est-ce qui fait que le programme est caractérisé comme "intéractif" dans le titre ? Est-ce que tu fais ça avec un plan bien défini, tu as un programme qui tourne et tu expliques comment y arriver (ou en te basant sur un autre tutoriel ?) ? Ou est-ce que le but c'est d'apprendre par ses erreurs et ensuite déterminer que ce qu'on faisait au début doit être réécrit pour être interactif ?

En fait, c'est de l'essai erreur. L'objectif est qu'à la fin, le framerate puisse être intéressant. Mais il est certain que ça ne sera pas de si tôt... Surtout que pour des scènes très simples, sans textures, je suis déjà loin de l'interactif (c'est pour ça que je n'aime pas Real-Time, si je fais ma scène en moins de 10sec, c'est du temps réel, interactif, c'est suffisamment rapide pour qu'un rafraîchissement ne soit pas remarqué).

Envoyé par LeGreg

Est-ce que l'utilisation du GPU est prévue ?
Exemple d'approche de ray tracing interactif sur le GPU :
http://realtimerendering.com/downloa...T-Overview.pdf

Oui, je connais le moteur d'nVidia.
Pour le moment, ce n'est pas au programme, je préfère avoir un truc sur CPU qui tienne le choc (sans compter qu'après il faut le paralléliser). Mais je garde un oeil sur les solutions GPU (surtout si pour mon boulot je commence à m'y mettre).