cloner le depot : git clone https://gitlab.liris.cnrs.fr/jiehl/formation/

la base de code compile sans dépendances.

ouvrez la solution visual studio dans build/

plusieurs scènes de tests au format .glTF sont également disponibles : cf les fichiers *.glb

TP

il y a 2 codes de tests dans projects :

• ao.cpp pour prendre le code en main, c'est un calcul assez direct d'ambiant occlusion,
• path.cpp, un path tracer tout simple qu'il va falloir améliorer.

il est possible de changer de sampler pour faire quelques comparaisons, il suffit de modifier le typedef au début des sources. les samplers eux mêmes sont dans :

• projects/sampler.h : il y a un générateur standard c++ et 2 générateurs basés compteurs,
• projects/sampler_sobol.h : la séquence sobol classique, avec max 128 dimensions, la version avec une évaluation "rapide" dans l'ordre des codes de gray, et les 2 acceptent un scrambling simple, random digit shift,
• projects/owen_fast.h : les permutations d'owen (à utiliser sur un échantillon sobol).

voila quelques suggestions, à faire (ou pas) dans l'ordre que vous préferrez.

réduction de dimensions

vous pouvez appliquer les différentes stratégies de réduction de dimensions au path tracer :

• passer de 3d à 2d dans la sélection des sources, et dans la génération des directions en fonction des matières,
• réutiliser les mêmes nombres aléatoires pour estimer les 2 intégrales, cf la fonction direct_mis().

le nombre de dimensions comsommées est affiché à la fin du calcul.

j'ai "laissé" la dernière amélioration en place, qui permet d'économiser un rayon par rebond et par pixel.

les matières sont dans src/gltf/brdf.h et les sources de lumières (uniquement des triangles émissifs) se trouvent dans src/gltf/sources.h.

sélection des sources

vous pouvez également modifier la stratégie de sélection des sources dans src/gltf/sources.h. la solution actuelle construit une variable aléatoire discrète et inverse sa cdf pour sélectionner une source proportionnellement à son aire.

et par rapport à son angle solide ? c'est mieux ou pas ? dans quels cas ?

cf wikipedia pour calculer l'angle solide d'un triangle

multiple importance sampling

vous pouvez facilement modifier l'heuristique utilisée pour combiner les 2 stratégies dans la fonction direct_mis(). ie utiliser balance au lieu de power comme c'est le cas dans le code.

il y a 2 estimateurs MIS, la version "multi-sample" et la version "one-sample". que faut-il modifier pour écrire la version "one-sample". quelles sont les différences en temps de rendu, en erreur ?

owen

il y a un bug numérique dans les permutations d'owen, cf projects/owen_fast.h. vous pouvez vous en rendre compte en comparant les images calculées avec Owen et OwenFast pour peu d'échantillons (< 16).

de manière assez surprenante le code de construction des permutations est correct, le générateur de nombre aléatoire (utilisé pour les décisions aléatoires de permuter chaque bit), aussi, à un détail près...

roulette russe ?

comment terminer les chemins sans introduire de biais systématique en limitant brutalement le nombre de rebonds ?

une solution interressante est présentée dans "Adjoint-Driven Russian Roulette and Splitting in Light Transport Simulation", 2016

il faut le lire calmement, mais tout ce que dit l'article est qu'il faut calculer chaque rebond avec un nombre d'échantillon proportionnel à la contribution du rebond à l'image complète (ie la somme des rebonds).

comment peut-on estimer une somme de plusieurs intégrales avec Monte Carlo ? ça vous rappelle quelque chose ? la vraie difficulté est due à la construction progressive des chemins. si le 2ieme rebond doit être évalué avec plus d'échantillons que le premier, il faut utiliser du splitting, pour obtenir le bon nombre de chemins de cette longueur. mais si le rebond suivant doit être évalué avec moins d'échantillons, il faut utiliser une roulette russe pour terminer brutalement certains chemins et conserver le bon nombre de chemins.

autre chose ?