|
844 | 844 |
|
845 | 845 | <div class='together'>
|
846 | 846 | 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: |
854 | 854 |
|
855 | 855 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ C++
|
856 | 856 | #ifndef HITTABLE_H
|
|
1807 | 1807 | this is that almost all image viewers assume that the image is “gamma corrected”, meaning the 0 to 1
|
1808 | 1808 | values have some transform before being stored as a byte. There are many good reasons for that, but
|
1809 | 1809 | 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: |
1812 | 1812 |
|
1813 | 1813 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ C++
|
1814 | 1814 | void write_color(std::ostream &out, color pixel_color, int samples_per_pixel) {
|
|
2184 | 2184 | </div>
|
2185 | 2185 |
|
2186 | 2186 | 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. |
2188 | 2188 |
|
2189 | 2189 | If you read the code above carefully, you'll notice a small chance of mischief. If the random unit
|
2190 | 2190 | vector we generate is exactly opposite the normal vector, the two will sum to zero, which will
|
|
0 commit comments