Book 3.6.2: Missing actual change to the probability function

[TheThief]

It's not very clearly explained IMO, but the pdf value you're multiplying by is the value from the ideal pdf you want to use for the surface, and the one you divide by is the value from the pdf you've actually used to generate the rays (which can e.g. be biased towards lights for importance sampling).

But in 6.2 as it stands at the time of writing (4.0.0-alpha.1 I believe) you're only changing the value you're dividing by to a uniform value, but still generating with the cosine distribution inside the material! So they don't match, and instead of correcting for the distribution being used it's actually altering it to a double cosine reflectance by accident.

The change you make in 6.3 to change to generate rays using a uniform hemisphere should be in 6.2 as well, to get the effect you're claiming of giving the same result but taking longer to converge (aka more noise).

Also, a lot of the code past this point is using the material function that returns a scatter ray in an out parameter but then throws that away and generates another one it actually uses immediately afterwards, which is inefficient

[hollasch]

From (now closed #1272):

In 6.2 Using a Uniform PDF Instead of a Perfect Match, the scatter ray is sampled in Lambert Distribution in rec.mat->scatter(), but the pdf value is set to 1/(2*pi). I think it is against the Monte Carlo Theory. Can It still converge to the correct answer? As the book said This will still converge on the correct answer. I'm confused about this.

[dimitry-ishenko]

FWIW, I got different results between 6.1 and 6.2.

6.1

6.2

This seems to make sense, actually. In 6.1 we multiply and divide by the same value of the PDF, which nullify each other. In 6.2 brighter rays are penalized less, relative to the darker ones since all are divided by the same amount.

I think this sentence in 6.2:

We will sample using a uniform PDF about the hemisphere, so we'll set the denominator to 1/2𝜋. This will still converge on the correct answer ...

goes against what was said earlier in the book. For example, when talking about directing rays towards the light in 3.3:

We could lessen this problem if we steered both of these rays toward the light, but this would cause the scene to be inaccurately bright. ... We can remove this inaccuracy by downweighting those samples to adjust for the over-sampling.

[dimitry-ishenko]

To make sure the problem was not with my implementation, I took the code from TheNextWeekend folder and applied the changes introduced in 6.1 and 6.2:

diff --git a/src/TheNextWeek/camera.h b/src/TheNextWeek/camera.h
index c8580d20..cfb8de7a 100644
--- a/src/TheNextWeek/camera.h
+++ b/src/TheNextWeek/camera.h
@@ -151,7 +151,12 @@ class camera {
         if (!rec.mat->scatter(r, rec, attenuation, scattered))
             return color_from_emission;
 
-        color color_from_scatter = attenuation * ray_color(scattered, depth-1, world);
+        double scattering_pdf = rec.mat->scattering_pdf(r, rec, scattered);
+        //double pdf = scattering_pdf;
+        double pdf = 1 / (2*pi);
+
+        color color_from_scatter =
+            (attenuation * scattering_pdf * ray_color(scattered, depth-1, world)) / pdf;
 
         return color_from_emission + color_from_scatter;
     }
diff --git a/src/TheNextWeek/main.cc b/src/TheNextWeek/main.cc
index b0191da8..a0b1a108 100644
--- a/src/TheNextWeek/main.cc
+++ b/src/TheNextWeek/main.cc
@@ -401,7 +401,7 @@ void final_scene(int image_width, int samples_per_pixel, int max_depth) {
 
 
 int main() {
-    switch (0) {
+    switch (7) {
         case 1:  bouncing_spheres();          break;
         case 2:  checkered_spheres();         break;
         case 3:  earth();                     break;
diff --git a/src/TheNextWeek/material.h b/src/TheNextWeek/material.h
index 1b168879..8b6cac84 100644
--- a/src/TheNextWeek/material.h
+++ b/src/TheNextWeek/material.h
@@ -31,6 +31,11 @@ class material {
     ) const {
         return false;
     }
+
+    virtual double scattering_pdf(const ray& r_in, const hit_record& rec, const ray& scattered)
+    const {
+        return 0;
+    }
 };
 
 
@@ -52,6 +57,12 @@ class lambertian : public material {
         return true;
     }
 
+    double scattering_pdf(const ray& r_in, const hit_record& rec, const ray& scattered)
+    const override {
+        auto cos_theta = dot(rec.normal, unit_vector(scattered.direction()));
+        return cos_theta < 0 ? 0 : cos_theta/pi;
+    }
+
   private:
     shared_ptr<texture> tex;
 };

And, I got results similar to mine:

Unmodified code from TheNextWeekend:

Applied changes from 6.1, which should result in an identical image:

Applied change from 6.2:

According to 6.2:

You should get a very similar result to before, only with slightly more noise, it may be hard to see.

But we don't... We get brighter image. 😕 😖