Skip to content

Commit c4bdaa9

Browse files
committed
Add \mathit for Book1
1 parent cdccbe4 commit c4bdaa9

File tree

1 file changed

+10
-10
lines changed

1 file changed

+10
-10
lines changed

books/RayTracingInOneWeekend.html

Lines changed: 10 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -844,13 +844,13 @@
844844

845845
<div class='together'>
846846
This `hittable` abstract class will have a hit function that takes in a ray. Most ray tracers have
847-
found it convenient to add a valid interval for hits $t_{min}$ to $t_{max}$, so the hit only
848-
“counts” if $t_{min} < t < t_{max}$. For the initial rays this is positive $t$, but as we will see,
849-
it can help some details in the code to have an interval $t_{min}$ to $t_{max}$. One design question
850-
is whether to do things like compute the normal if we hit something. We might end up hitting
851-
something closer as we do our search, and we will only need the normal of the closest thing. I will
852-
go with the simple solution and compute a bundle of stuff I will store in some structure. Here’s
853-
the abstract class:
847+
found it convenient to add a valid interval for hits $t_{\mathit{min}}$ to $t_{\mathit{max}}$, so
848+
the hit only “counts” if $t_{\mathit{min}} < t < t_{\mathit{max}}$. For the initial rays this is
849+
positive $t$, but as we will see, it can help some details in the code to have an interval
850+
$t_{\mathit{min}}$ to $t_{\mathit{max}}$. One design question is whether to do things like compute
851+
the normal if we hit something. We might end up hitting something closer as we do our search, and we
852+
will only need the normal of the closest thing. I will go with the simple solution and compute a
853+
bundle of stuff I will store in some structure. Here’s the abstract class:
854854

855855
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ C++
856856
#ifndef HITTABLE_H
@@ -1807,8 +1807,8 @@
18071807
this is that almost all image viewers assume that the image is “gamma corrected”, meaning the 0 to 1
18081808
values have some transform before being stored as a byte. There are many good reasons for that, but
18091809
for our purposes we just need to be aware of it. To a first approximation, we can use “gamma 2”
1810-
which means raising the color to the power $1/gamma$, or in our simple case ½, which is just
1811-
square-root:
1810+
which means raising the color to the power $1/\mathit{gamma}$, or in our simple case ½, which is
1811+
just square-root:
18121812

18131813
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ C++
18141814
void write_color(std::ostream &out, color pixel_color, int samples_per_pixel) {
@@ -2184,7 +2184,7 @@
21842184
</div>
21852185

21862186
Note we could just as well only scatter with some probability $p$ and have attenuation be
2187-
$albedo/p$. Your choice.
2187+
$\mathit{albedo}/p$. Your choice.
21882188

21892189
If you read the code above carefully, you'll notice a small chance of mischief. If the random unit
21902190
vector we generate is exactly opposite the normal vector, the two will sum to zero, which will

0 commit comments

Comments
 (0)