Host site from root of master (was from docs/)

- move assets directory from docs/assets/ to assets/
- move docs/ to book/
- move home index.html file to root of workspace
- update asset links from book source

docs/ch01.md.html → book/ch01.md.html

@@ -253,7 +253,7 @@
     );
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-![Image 1-1](assets/img1-01.jpg)
+![Image 1-1](../assets/img1-01.jpg)
 
 
 

docs/ch02.md.html → book/ch02.md.html

@@ -39,7 +39,7 @@
 divided a set of objects into two groups, red and blue, and used rectangular bounding volumes, we’d
 have:
 
-![Figure 2-1](assets/fig2-01.jpg)
+![Figure 2-1](../assets/fig2-01.jpg)
 
 Note that the blue and red bounding volumes are contained in the purple one, but they might
 overlap, and they are not ordered -- they are just both inside. So the tree shown on the right has
@@ -70,13 +70,13 @@
 the points between two endpoints, _e.g._, $x$ such that $3 < x < 5$, or more succinctly $x$ in
 $(3,5)$. In 2D, two intervals overlapping makes a 2D AABB (a rectangle):
 
-![Figure 2-2](assets/fig2-02.jpg)
+![Figure 2-2](../assets/fig2-02.jpg)
 
 For a ray to hit one interval we first need to figure out whether the ray hits the boundaries. For
 example, again in 2D, this is the ray parameters $t_0$ and $t_1$. (If the ray is parallel to the
 plane those will be undefined.)
 
-![Figure 2-3](assets/fig2-03.jpg)
+![Figure 2-3](../assets/fig2-03.jpg)
 
 In 3D, those boundaries are planes. The equations for the planes are $x = x_0$, and $x = x_1$. Where
 does the ray hit that plane? Recall that the ray can be thought of as just a function that given a
@@ -100,7 +100,7 @@
 The key observation to turn that 1D math into a hit test is that for a hit, the $t$-intervals need
 to overlap. For example, in 2D the green and blue overlapping only happens if there is a hit:
 
-![Figure 2-4](assets/fig2-04.jpg)
+![Figure 2-4](../assets/fig2-04.jpg)
 
 What “do the t intervals in the slabs overlap?” would like in code is something like:
 

docs/ch03.md.html → book/ch03.md.html

@@ -89,7 +89,7 @@
 
 We get:
 
-![Image 3-1](assets/img3-01.jpg)
+![Image 3-1](../assets/img3-01.jpg)
 
 If we add a new scene:
 
@@ -121,7 +121,7 @@
 
 We get:
 
-![Image 3-2](assets/img3-02.jpg)
+![Image 3-2](../assets/img3-02.jpg)
 
 
 

docs/ch04.md.html → book/ch04.md.html

@@ -11,11 +11,11 @@
 To get cool looking solid textures most people use some form of  Perlin noise. These are named after
 their inventor Ken Perlin. Perlin texture doesn’t return white noise like this:
 
-![Image 4-1](assets/img4-01.jpg)
+![Image 4-1](../assets/img4-01.jpg)
 
 Instead it returns something similar to blurred white noise:
 
-![Image 4-2](assets/img4-02.jpg)
+![Image 4-2](../assets/img4-02.jpg)
 
 A key part of Perlin noise is that it is repeatable: it takes a 3D point as input and always returns
 the same randomish number. Nearby points return similar numbers. Another important part of Perlin
@@ -25,7 +25,7 @@
 We could just tile all of space with a 3D array of random numbers and use them in blocks. You get
 something blocky where the repeating is clear:
 
-![Image 4-3](assets/img4-03.jpg)
+![Image 4-3](../assets/img4-03.jpg)
 
 Let’s just use some sort of hashing to scramble this, instead of tiling. This has a bit of support
 code to make it all happen:
@@ -118,7 +118,7 @@
 
 Add the hashing does scramble as hoped:
 
-![Image 4-4](assets/img4-04.jpg)
+![Image 4-4](../assets/img4-04.jpg)
 
 To make it smooth, we can linearly interpolate:
 
@@ -163,7 +163,7 @@
 
 And we get:
 
-![Image 4-5](assets/img4-05.jpg)
+![Image 4-5](../assets/img4-05.jpg)
 
 Better, but there are obvious grid features in there. Some of it is  Mach bands, a known perceptual
 artifact of linear interpolation of color. A standard trick is to use a  hermite cubic to round off
@@ -189,7 +189,7 @@
 
 This gives a smoother looking image:
 
-![Image 4-6](assets/img4-06.jpg)
+![Image 4-6](../assets/img4-06.jpg)
 
 It is also a bit low frequency. We can scale the input point to make it vary more quickly:
 
@@ -208,7 +208,7 @@
 
 which gives:
 
-![Image 4-7](assets/img4-07.jpg)
+![Image 4-7](../assets/img4-07.jpg)
 
 This is still a bit grid blocky looking, probably because the min and max of the pattern always
 lands exactly on the integer x/y/z. Ken Perlin’s very clever trick was to instead put random unit
@@ -286,7 +286,7 @@
 
 This finally gives something more reasonable looking:
 
-![Image 4-8](assets/img4-08.jpg)
+![Image 4-8](../assets/img4-08.jpg)
 
 Very often, a composite noise that has multiple summed frequencies is used. This is usually called
 turbulence and is a sum of repeated calls to noise:
@@ -309,7 +309,7 @@
 
 Used directly, turbulence gives a sort of camouflage netting appearance:
 
-![Image 4-9](assets/img4-09.jpg)
+![Image 4-9](../assets/img4-09.jpg)
 
 However, usually turbulence is used indirectly. For example, the “hello world” of procedural solid
 textures is a simple marble-like texture. The basic idea is to make color proportional to something
@@ -334,7 +334,7 @@
 
 Which yields:
 
-![Image 4-10](assets/img4-10.jpg)
+![Image 4-10](../assets/img4-10.jpg)
 
 
 

docs/ch05.md.html → book/ch05.md.html

@@ -121,7 +121,7 @@
 To test this, assign it to a sphere, and then temporarily cripple the color() function in main to
 just return attenuation. You should get something like:
 
-![Image 5-1](assets/img5-01.jpg)
+![Image 5-1](../assets/img5-01.jpg)
 
 
 

docs/ch06.md.html → book/ch06.md.html

@@ -65,7 +65,7 @@
 First, here is a rectangle in an xy plane. Such a plane is defined by its z value. For example, $z =
 k$. An axis-aligned rectangle is defined by lines $x=x_0$ , $x=x_1$ , $y=y_0$ , $y=y_1$.
 
-![Figure 6-1](assets/fig6-01.jpg)
+![Figure 6-1](../assets/fig6-01.jpg)
 
 To determine whether a ray hits such a rectangle, we first determine where the ray hits the plane.
 Recall that a ray $p(t) = a + t \cdot b$ has its z component defined by $z(t) = a_z + t \cdot b_z$.
@@ -137,13 +137,13 @@
 
 We get:
 
-![Image 6-1](assets/img6-01.jpg)
+![Image 6-1](../assets/img6-01.jpg)
 
 Note that the light is brighter than $(1,1,1)$. This allows it to be bright enough to light things.
 
 Fool around with making some spheres lights too.
 
-![Image 6-2](assets/img6-02.jpg)
+![Image 6-2](../assets/img6-02.jpg)
 
 Now let’s add the other two axes and the famous Cornell Box.
 
@@ -253,7 +253,7 @@
 
 We get:
 
-![Image 6-3](assets/img6-03.jpg)
+![Image 6-3](../assets/img6-03.jpg)
 
 This is very noisy because the light is small. But why are the other walls missing? They are facing
 the wrong way. We need outward facing normals. Let’s make a hitable that does nothing but hold
@@ -307,7 +307,7 @@
 
 And voila:
 
-![Image 6-4](assets/img6-04.jpg)
+![Image 6-4](../assets/img6-04.jpg)
 
 
 

docs/ch07.md.html → book/ch07.md.html

@@ -55,7 +55,7 @@
 
 This gives:
 
-![Image 7-1](assets/img7-01.jpg)
+![Image 7-1](../assets/img7-01.jpg)
 
 Now that we have boxes, we need to rotate them a bit to have them match the _real_ Cornell box. In
 ray tracing, this is usually done with an _instance_. An instance is a geometric primitive that has
@@ -65,7 +65,7 @@
 or (as we almost always do in ray tracing) leave the box where it is, but in its hit routine
 subtract 2 off the x-component of the ray origin.
 
-![Figure 7-1](assets/fig7-01.jpg)
+![Figure 7-1](../assets/fig7-01.jpg)
 
 Whether you think of this as a move or a change of coordinates is up to you. The code for this, to
 move any underlying hitable is a _translate_ instance.
@@ -107,7 +107,7 @@
 First, let’s rotate by theta about the z-axis. That will be changing only x and y, and in ways that
 don’t depend on z.
 
-![Figure 7-2](assets/fig7-02.jpg)
+![Figure 7-2](../assets/fig7-02.jpg)
 
 This involves some basic trigonometry that uses formulas that I will not cover here. That gives you
 the correct impression it’s a little involved, but it is straightforward, and you can find it in any
@@ -228,7 +228,7 @@
 
 Which yields:
 
-![Image 7-2](assets/img7-02.jpg)
+![Image 7-2](../assets/img7-02.jpg)
 
 
 

docs/ch08.md.html → book/ch08.md.html

@@ -21,7 +21,7 @@
 far the ray has to travel through the volume also determines how likely it is for the ray to make it
 through.
 
-![Figure 8-1](assets/fig8-01.jpg)
+![Figure 8-1](../assets/fig8-01.jpg)
 
 As the ray passes through the volume, it may scatter at any point. The denser the volume, the more
 likely that is. The probability that the ray scatters in any small distance $\delta L$ is:
@@ -92,7 +92,7 @@
                     return false;
                 if (rec1.t < 0)
                     rec1.t = 0;
-                float distance_inside_boundary = 
+                float distance_inside_boundary =
                     (rec2.t - rec1.t)*r.direction().length();
                 float hit_distance = -(1/density)*log(drand48());
                 if (hit_distance < distance_inside_boundary) {
@@ -152,7 +152,7 @@
 
 We get:
 
-![Image 8-1](assets/img8-01.jpg)
+![Image 8-1](../assets/img8-01.jpg)
 
 
 

docs/ch09.md.html → book/ch09.md.html

@@ -71,7 +71,7 @@
 
 Running it with 10,000 rays per pixel yields:
 
-![Image 9-1](assets/img9-01.jpg)
+![Image 9-1](../assets/img9-01.jpg)
 
 Now go off and make a really cool image of your own! See http://in1weekend.com/ for pointers to
 further reading and features, and feel free to email questions, comments, and cool images to me at

docs/index.html → index.html

@@ -7,16 +7,16 @@
 
                                          **Rough Content**
 
-- [Chapter 0](ch00.md.html)
-- [Chapter 1](ch01.md.html)
-- [Chapter 2](ch02.md.html)
-- [Chapter 3](ch03.md.html)
-- [Chapter 4](ch04.md.html)
-- [Chapter 5](ch05.md.html)
-- [Chapter 6](ch06.md.html)
-- [Chapter 7](ch07.md.html)
-- [Chapter 8](ch08.md.html)
-- [Chapter 9](ch09.md.html)
+- [Chapter 0](book/ch00.md.html)
+- [Chapter 1](book/ch01.md.html)
+- [Chapter 2](book/ch02.md.html)
+- [Chapter 3](book/ch03.md.html)
+- [Chapter 4](book/ch04.md.html)
+- [Chapter 5](book/ch05.md.html)
+- [Chapter 6](book/ch06.md.html)
+- [Chapter 7](book/ch07.md.html)
+- [Chapter 8](book/ch08.md.html)
+- [Chapter 9](book/ch09.md.html)