Merge pull request #915 from ymherklotz/textit-in-mathblocks

Add \mathit for multiletter math variables

Author: hollasch

CHANGELOG.md

@@ -28,6 +28,7 @@ Change Log -- Ray Tracing in One Weekend
   - Fix: rect hit returning NaNs and infinities. Superseded with new `quad` primitive (#681)
   - Added: New 2D `quad` primitive of arbitrary orientation (#756)
   - Added: New `box()` utility function returns `hittable_list` of new `quad` primitives (#780)
+  - Fix: Add `\mathit` to italic math variables to fix slight kerning issues (#839)
 
 ### In One Weekend
   - Added: More commentary about the choice between `double` and `float` (#752)

books/RayTracingInOneWeekend.html

@@ -844,13 +844,13 @@
 
 <div class='together'>
 This `hittable` abstract class will have a hit function that takes in a ray. Most ray tracers have
-found it convenient to add a valid interval for hits $t_{min}$ to $t_{max}$, so the hit only
-“counts” if $t_{min} < t < t_{max}$. For the initial rays this is positive $t$, but as we will see,
-it can help some details in the code to have an interval $t_{min}$ to $t_{max}$. One design question
-is whether to do things like compute the normal if we hit something. We might end up hitting
-something closer as we do our search, and we will only need the normal of the closest thing. I will
-go with the simple solution and compute a bundle of stuff I will store in some structure. Here’s
-the abstract class:
+found it convenient to add a valid interval for hits $t_{\mathit{min}}$ to $t_{\mathit{max}}$, so
+the hit only “counts” if $t_{\mathit{min}} < t < t_{\mathit{max}}$. For the initial rays this is
+positive $t$, but as we will see, it can help some details in the code to have an interval
+$t_{\mathit{min}}$ to $t_{\mathit{max}}$. One design question is whether to do things like compute
+the normal if we hit something. We might end up hitting something closer as we do our search, and we
+will only need the normal of the closest thing. I will go with the simple solution and compute a
+bundle of stuff I will store in some structure. Here’s the abstract class:
 
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ C++
     #ifndef HITTABLE_H
@@ -1807,8 +1807,8 @@
 this is that almost all image viewers assume that the image is “gamma corrected”, meaning the 0 to 1
 values have some transform before being stored as a byte. There are many good reasons for that, but
 for our purposes we just need to be aware of it. To a first approximation, we can use “gamma 2”
-which means raising the color to the power $1/gamma$, or in our simple case ½, which is just
-square-root:
+which means raising the color to the power $1/\mathit{gamma}$, or in our simple case ½, which is
+just square-root:
 
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ C++
     void write_color(std::ostream &out, color pixel_color, int samples_per_pixel) {
@@ -2184,7 +2184,7 @@
 </div>
 
 Note we could just as well only scatter with some probability $p$ and have attenuation be
-$albedo/p$. Your choice.
+$\mathit{albedo}/p$. Your choice.
 
 If you read the code above carefully, you'll notice a small chance of mischief. If the random unit
 vector we generate is exactly opposite the normal vector, the two will sum to zero, which will

books/RayTracingTheRestOfYourLife.html

@@ -388,7 +388,7 @@
 Our Buffon Needle example is a way of calculating $\pi$ by solving for the ratio of the area of the
 circle and the area of the inscribing square:
 
-    $$ \frac{\text{area}(circle)}{\text{area}(square)} = \frac{\pi}{4} $$
+    $$ \frac{\text{area}(\mathit{circle})}{\text{area}(\mathit{square})} = \frac{\pi}{4} $$
 
 We picked a bunch of random points in the inscribing square and counted the fraction of them that
 were also in the unit circle. This fraction was an estimate that tended toward $\frac{\pi}{4}$ as
@@ -397,14 +397,14 @@
 $\frac{\pi}{4}$, and we know that the area of a inscribing square is $4r^2$, so we could then use
 those two quanties to get the area of a circle:
 
-    $$ \frac{\text{area}(circle)}{\text{area}(square)} = \frac{\pi}{4} $$
-    $$ \frac{\text{area}(circle)}{(2r)^2} = \frac{\pi}{4} $$
-    $$ \text{area}(circle) = \frac{\pi}{4} 4r^2 $$
-    $$ \text{area}(circle) = \pi r^2 $$
+    $$ \frac{\text{area}(\mathit{circle})}{\text{area}(\mathit{square})} = \frac{\pi}{4} $$
+    $$ \frac{\text{area}(\mathit{circle})}{(2r)^2} = \frac{\pi}{4} $$
+    $$ \text{area}(\mathit{circle}) = \frac{\pi}{4} 4r^2 $$
+    $$ \text{area}(\mathit{circle}) = \pi r^2 $$
 
 We choose a circle with radius $r = 1$ and get:
 
-    $$ \text{area}(circle) = \pi $$
+    $$ \text{area}(\mathit{circle}) = \pi $$
 
 Our work above is equally valid as a means to solve for $pi$ as it is a means to solve for the area
 of a circle:
@@ -1340,31 +1340,31 @@
 in the _LMS color space_ (long, medium, short).
 
 If the light does scatter, it will have a directional distribution that we can describe as a PDF
-over solid angle. I will refer to this as its _scattering PDF_: $pScatter()$. The scattering PDF
-will vary with the outgoing direction: $pScatter(\omega_o)$. The scattering PDF can also vary with
-_incident direction_: $pScatter(\omega_i, \omega_o)$. You can see this varying with incident
-direction when you look at reflections off a road -- they become mirror-like as your viewing angle
-(incident angle) approaches grazing. Lastly, the scattering PDF can also depend on the scattering
-position: $pScatter(\textbf{x}, \omega_i, \omega_o)$. The $\textbf{x}$ is just a vector representing
-the scattering position: $\textbf{x} = (x, y, z)$. The Albedo of an object can also depend on these
-quantities: $A(\textbf{x}, \omega_i, \omega_o)$.
+over solid angle. I will refer to this as its _scattering PDF_: $\mathit{pScatter}()$. The
+scattering PDF will vary with the outgoing direction: $\mathit{pScatter}(\omega_o)$. The scattering
+PDF can also vary with _incident direction_: $\mathit{pScatter}(\omega_i, \omega_o)$. You can see
+this varying with incident direction when you look at reflections off a road -- they become
+mirror-like as your viewing angle (incident angle) approaches grazing. Lastly, the scattering PDF
+can also depend on the scattering position: $\mathit{pScatter}(\textbf{x}, \omega_i, \omega_o)$. The
+$\textbf{x}$ is just a vector representing the scattering position: $\textbf{x} = (x, y, z)$. The
+Albedo of an object can also depend on these quantities: $A(\textbf{x}, \omega_i, \omega_o)$.
 
 <div class='together'>
 The color of a surface is found by integrating these terms over the unit hemisphere by the incident
 direction:
 
     $$ \text{Color}_o(\textbf{x}, \omega_o) = \int_{\omega_i}
         A(\textbf{x}, \omega_i, \omega_o) \cdot
-        pScatter(\textbf{x}, \omega_i, \omega_o) \cdot
+        \mathit{pScatter}(\textbf{x}, \omega_i, \omega_o) \cdot
         \text{Color}_i(\textbf{x}, \omega_i) $$
 
 We've added a $\text{Color}_i$ term. The scattering PDF and the albedo at the surface of an object
 are acting as filters to the light that is shining on that point. So we need to solve for the light
 that is shining on that point. This is a recursive algorithm, and is the reason our `ray_color`
 function returns the color of the current object multiplied by the color of the next ray.
 
-Note that $A()$, $pScatter()$, and $\text{Color}_i()$ may all depend on the wavelength of the light,
-$\lambda$, but I've left it out of the equation because it's complicated enough as it is.
+Note that $A()$, $\mathit{pScatter}()$, and $\text{Color}_i()$ may all depend on the wavelength of
+the light, $\lambda$, but I've left it out of the equation because it's complicated enough as it is.
 </div>
 
 
@@ -1374,7 +1374,7 @@
 If we apply the Monte Carlo basic formula we get the following statistical estimate:
 
     $$ \text{Color}_o = \frac{A(\textbf{x}, \omega_i, \omega_o) \cdot
-        pScatter(\textbf{x}, \omega_i, \omega_o) \cdot
+        \mathit{pScatter}(\textbf{x}, \omega_i, \omega_o) \cdot
         \text{Color}_i(\textbf{x}, \omega_i)}
         {p(\textbf{x}, \omega_o)} $$
 
@@ -1383,11 +1383,11 @@
 </div>
 
 For a Lambertian surface we already implicitly implemented this formula for the special case where
-$p()$ is a cosine density. The $pScatter()$ of a Lambertian surface is proportional to
+$p()$ is a cosine density. The $\mathit{pScatter}()$ of a Lambertian surface is proportional to
 $\cos(\theta_o)$, where $\theta_o$ is the angle relative to the surface normal. All two dimensional
-PDFs need to integrate to one over the whole surface (remember that $pScatter()$ is a PDF). We set
-$pScatter(\theta_o < 0) = 0$ so that we don't scatter below the horizon. The integral of
-$\cos(\theta_o)$ over the hemisphere is $\pi$.
+PDFs need to integrate to one over the whole surface (remember that $\mathit{pScatter}()$ is a
+PDF). We set $\mathit{pScatter}(\theta_o < 0) = 0$ so that we don't scatter below the horizon. The
+integral of $\cos(\theta_o)$ over the hemisphere is $\pi$.
 
 <div class='together'>
 To integrate over the hemisphere, remember that in spherical coordinates:
@@ -1404,13 +1404,13 @@
 If we have a scattering PDF that is $\cos(\theta_o)$ over the hemisphere, then we need to normalize
 by $\pi$. So for a Lambertian surface the scattering PDF is:
 
-    $$ pScatter(\omega_o) = \frac{\cos(\theta_o)}{\pi} $$
+    $$ \mathit{pScatter}(\omega_o) = \frac{\cos(\theta_o)}{\pi} $$
 </div>
 
 <div class='together'>
 We'll assume that the PDF is equal to the scattering PDF:
 
-    $$ p(\omega_o) = pScatter() = \frac{\cos(\theta_o)}{\pi} $$
+    $$ p(\omega_o) = \mathit{pScatter}() = \frac{\cos(\theta_o)}{\pi} $$
 
 The numerator and denominator cancel out, and we get:
 
@@ -1428,7 +1428,7 @@
 _Bidirectional Reflectance Distribution Function_ (BRDF). It relates pretty simply to our terms:
 
     $$ BRDF(\omega_i, \omega_o) = \frac{A(\textbf{x}, \omega_i, \omega_o) \cdot
-        pScatter(\textbf{x}, \omega_i, \omega_o)}{\cos(\theta_o)} $$
+        \mathit{pScatter}(\textbf{x}, \omega_i, \omega_o)}{\cos(\theta_o)} $$
 
 So for a Lambertian surface for example, $BRDF = A / \pi$. Translation between our terms and BRDF is
 easy. For participating media (volumes), our albedo is usually called the _scattering albedo_, and
@@ -1446,27 +1446,29 @@
 <div class='together'>
 Our goal over the next two chapters is to instrument our program to send a bunch of extra rays
 toward light sources so that our picture is less noisy. Let’s assume we can send a bunch of rays
-toward the light source using a PDF $pLight(\omega_o)$. Let’s also assume we have a PDF related to
-$pScatter$, and let’s call that $pSurface(\omega_o)$. A great thing about PDFs is that you can just
-use linear mixtures of them to form mixture densities that are also PDFs. For example, the simplest
-would be:
+toward the light source using a PDF $\mathit{pLight}(\omega_o)$. Let’s also assume we have a PDF
+related to $\mathit{pScatter}$, and let’s call that $\mathit{pSurface}(\omega_o)$. A great thing
+about PDFs is that you can just use linear mixtures of them to form mixture densities that are also
+PDFs. For example, the simplest would be:
 
-  $$ p(\omega_o) = \frac{1}{2} pSurface(\omega_o) +  \frac{1}{2} pLight(\omega_o)$$
+  $$ p(\omega_o) = \frac{1}{2} \mathit{pSurface}(\omega_o) +  \frac{1}{2}
+      \mathit{pLight}(\omega_o)$$
 </div>
 
 As long as the weights are positive and add up to one, any such mixture of PDFs is a PDF. Remember,
 we can use any PDF: _all PDFs eventually converge to the correct answer_. So, the game is to figure
 out how to make the PDF larger where the product
 
-    $$ pScatter(\textbf{x}, \omega_i, \omega_o) \cdot \text{Color}_i(\textbf{x}, \omega_i) $$
+    $$ \mathit{pScatter}(\textbf{x}, \omega_i, \omega_o) \cdot
+        \text{Color}_i(\textbf{x}, \omega_i) $$
 
 is largest. For diffuse surfaces, this is mainly a matter of guessing where
 $\text{Color}_i(\textbf{x}, \omega_i)$ is largest. Which is equivalent to guessing where the most
 light is coming from.
 
-For a mirror, $pScatter()$ is huge only near one direction, so $pScatter()$ matters a lot more. In
-fact, most renderers just make mirrors a special case, and make the $pScatter()/p()$ implicit -- our
-code currently does that.
+For a mirror, $\mathit{pScatter}()$ is huge only near one direction, so $\mathit{pScatter}()$
+matters a lot more. In fact, most renderers just make mirrors a special case, and make the
+$\mathit{pScatter}()/p()$ implicit -- our code currently does that.
 
 
 Returning to the Cornell Box
@@ -1674,7 +1676,7 @@
 material, but Lambertian requires a $\cos(\theta_o)$ sampling pattern. So any differences that we
 see is because we are using a slightly different material. We're going to uniformly scatter random
 directions from the hemisphere and perfectly match the PDF, given by
-$pScatter(\omega_o) = p(\omega_o) = \frac{1}{2\pi}$.
+$\mathit{pScatter}(\omega_o) = p(\omega_o) = \frac{1}{2\pi}$.
 
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ C++
     class lambertian : public material {
@@ -2416,9 +2418,10 @@
 </div>
 
 <div class='together'>
-The details of how this is done under the hood varies for $pSurface$ and $pLight$, but that is
-exactly what class hierarchies were invented for! It’s never obvious what goes in an abstract class,
-so my approach is to be greedy and hope a minimal interface works, and for `pdf` this implies:
+The details of how this is done under the hood varies for $\mathit{pSurface}$ and $\mathit{pLight}$,
+but that is exactly what class hierarchies were invented for! It’s never obvious what goes in an
+abstract class, so my approach is to be greedy and hope a minimal interface works, and for `pdf`
+this implies:
 
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ C++
     #ifndef PDF_H
@@ -2735,13 +2738,14 @@
 mixtures of any PDFs to form mixture densities that are also PDFs. Any weighted average of PDFs is
 also a PDF. As long as the weights are positive and add up to any one, we have a new PDF.
 
-  $$ pMixture() = w_0 p_0() + w_1 p_1() + w_2 p_2() + \ldots + w_{n-1} p_{n-1}() $$
+  $$ \mathit{pMixture}() = w_0 p_0() + w_1 p_1() + w_2 p_2() + \ldots + w_{n-1} p_{n-1}() $$
 
   $$ 1 = w_0 + w_1 + w_2 + \ldots + w_{n-1} $$
 
 For example, we could just average the two densities:
 
-  $$ pMixture(\omega_o) = \frac{1}{2} pSurface(\omega_o) +  \frac{1}{2} pLight(\omega_o)$$
+  $$ \mathit{pMixture}(\omega_o) = \frac{1}{2} \mathit{pSurface}(\omega_o) +  \frac{1}{2}
+      \mathit{pLight}(\omega_o)$$
 
 <div class='together'>
 How would we instrument our code to do that? There is a very important detail that makes this not
@@ -2754,7 +2758,7 @@
         pick direction according to pLight
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-But solving for the PDF value of $pMixture$ is slightly more subtle. We can't just
+But solving for the PDF value of $\mathit{pMixture}$ is slightly more subtle. We can't just
 
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     if (direction is from pSurface)
@@ -2769,10 +2773,10 @@
 correct, we would have to solve backwards to figure which PDF the direction could come from. Which
 honestly sounds like a nightmare, but fortunately we don't need to do that. There are some
 directions that both PDFs could have generated. For example, a direction toward the light could have
-been generated by either $pLight$ _or_ $pSurface$. It is sufficient for us to solve for the pdf
-value of $pSurface$ and of $pLight$ for a random direction and then take the PDF mixture weights to
-solve for the total PDF value for that direction. The mixture density class is actually pretty
-straightforward:
+been generated by either $\mathit{pLight}$ _or_ $\mathit{pSurface}$. It is sufficient for us to
+solve for the pdf value of $\mathit{pSurface}$ and of $\mathit{pLight}$ for a random direction and
+then take the PDF mixture weights to solve for the total PDF value for that direction. The mixture
+density class is actually pretty straightforward:
 
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ C++
     class mixture_pdf : public pdf {

books/acknowledgments.md.html

@@ -60,6 +60,7 @@
   - Tatsuya Ogawa
   - Thiago Ize
   - Vahan Sosoyan
+  - [Yann Herklotz](https://github.com/ymherklotz)
   - [ZeHao Chen](https://github.com/oxine)
 </div>