• Pour les scènes simples, cela ne dépasse généralement pas 5 rebonds environ

• Plus petit est plus rapide

SELECT * FROM rays WHERE img_x=100 AND img_y=250

Éléments d'implémentation intéressants

Telle qu'elle est, je me suis retrouvé à résoudre certains problèmes de façon intéressante.

JOIN LATERAL

JOIN LATERAL est une façon de faire une sous-requête corrélée dans un JOIN, au lieu de juste dans une clause WHERE. Je l'utilise comme moyen de remonter des calculs et d'en faire beaucoup une seule fois et, dans certains cas, d'éviter une duplication excessive.

Diffusion diffuse

Cela nécessite d'échantillonner une sphère uniforme. Je génère beaucoup d'échantillons aléatoires à l'avance [échantillonnage avec rejet -> mise à l'échelle des points sur la surface de la sphère], et je les numérote.

Trouver une façon de joindre chaque rayon à une seule ligne aléatoire parmi ces diffusions précalculées était étrange ; on ne peut pas simplement joindre à RANDOM() parce que chaque rayon serait joint à la même diffusion aléatoire. On ne peut pas non plus sélectionner avec un calcul typique sur une normale car cela mène à des bandes dans l'image. Donc, à la place, je sors quelques décimales tardives d'une dimension d'une normale, puis je rejoins dessus. C'est « aléatoire » mais aussi suffisamment unique par rayon.

CTE récursifs

Le lancer de rayons suit très naturellement le fonctionnement des CTE récursifs. Une des choses que j'ai rencontrées était une façon propre d'identifier quel rayon est celui à prendre en compte. L'utilisation d'une fonction fenêtrée ordonnant par l'interception (t) a bien marché. À chaque itération, cette requête intersecte un rayon avec tout ce qui est devant lui et effectue tous les calculs associés, mais ensuite dans la clause WHERE rejette tout sauf la chose que le rayon a réellement touchée.

Aussi, il y a quelque chose de vraiment beau dans la simplicité du cœur du rollup final [édité pour la clarté] :

 SELECT img_x, img_y,
         SUM(POW(color_mult * ray_col_r/samples_per_px, gamma)) col_r,
         SUM(POW(color_mult * ray_col_g/samples_per_px, gamma)) col_g,
         SUM(POW(color_mult * ray_col_b/samples_per_px, gamma)) col_b
    FROM rays
    GROUP BY img_y, img_x

Scènes, matériaux, etc.

Parce que c'est en SQL, je peux stocker plusieurs scènes dans la base de données. Celle qui est réellement rendue est sélectionnée dans la table "camera".

Se tenir sur les épaules des géants

Deux ans avant que j'écrive ceci, "Le traceur de rayons MySQL le plus avancé du marché actuellement" a circulé sur les réseaux sociaux : https://www.pouet.net/prod.php?which=83222

J'avais quelques idées en tête que je voulais faire différemment [pire ?] :

[...]

Cela ressemble soit à un brillant projet de thèse d'un étudiant en informatique, à l'expérience d'un ingénieur senior pendant un week-end, ou à quelqu'un piégé dans un environnement strictement limité aux bases de données qui a refusé d'abandonner ses rêves de lancer de rayons.

C'est l'équivalent en programmation de construire une voiture de course en Lego - techniquement impressionnant, mais vous ne devriez probablement pas vraiment la conduire.

Je ne sais pas si je suis flatté ou offensé.

Références

La plupart de ceci est construit en suivant la série "Ray Tracing in One Weekend" : https://raytracing.github.io/ , puis en tenant compte de la manière délibérément obtuse dont je le code.

Gary