|
66 | 66 | write it to a file. The catch is, there are so many formats and many of those are complex. I always |
67 | 67 | start with a plain text ppm file. Here’s a nice description from Wikipedia: |
68 | 68 |
|
69 | | -  |
| 69 | +  |
70 | 70 |
|
71 | 71 | Let’s make some C++ code to output such a thing: |
72 | 72 |
|
|
108 | 108 | Opening the output file (in ToyViewer on my mac, but try it in your favorite viewer and google “ppm |
109 | 109 | viewer” if your viewer doesn’t support it) shows: |
110 | 110 |
|
111 | | -  |
| 111 | +  |
112 | 112 |
|
113 | 113 | Hooray! This is the graphics “hello world”. If your image doesn’t look like that, open the output |
114 | 114 | file in a text editor and see what it looks like. It should start something like this: |
|
332 | 332 | front of $A$, and this is what is often called a half-line or ray. The example $C = p(2)$ is shown |
333 | 333 | here: |
334 | 334 |
|
335 | | -  |
| 335 | +  |
336 | 336 |
|
337 | 337 | The function $p(t)$ in more verbose code form I call “point_at_parameter(t)”: |
338 | 338 |
|
|
372 | 372 | sides to move the ray endpoint across the screen. Note that I do not make the ray direction a unit |
373 | 373 | length vector because I think not doing that makes for simpler and slightly faster code. |
374 | 374 |
|
375 | | -  |
| 375 | +  |
376 | 376 |
|
377 | 377 | Below in code, the ray $r$ goes to approximately the pixel centers (I won’t worry about exactness |
378 | 378 | for now because we’ll add antialiasing later): |
|
421 | 421 |
|
422 | 422 | with $t$ going from zero to one. In our case this produces: |
423 | 423 |
|
424 | | -  |
| 424 | +  |
425 | 425 |
|
426 | 426 |
|
427 | 427 |
|
|
467 | 467 | (meaning no real solutions), or zero (meaning one real solution). In graphics, the algebra almost |
468 | 468 | always relates very directly to the geometry. What we have is: |
469 | 469 |
|
470 | | -  |
| 470 | +  |
471 | 471 |
|
472 | 472 | If we take that math and hard-code it into our program, we can test it by coloring red any pixel |
473 | 473 | that hits a small sphere we place at -1 on the z-axis: |
|
493 | 493 |
|
494 | 494 | What we get is this: |
495 | 495 |
|
496 | | -  |
| 496 | +  |
497 | 497 |
|
498 | 498 | Now this lacks all sorts of things -- like shading and reflection rays and more than one object -- |
499 | 499 | but we are closer to halfway done than we are to our start! One thing to be aware of is that we |
|
513 | 513 | as are most design decisions like that. For a sphere, the normal is in the direction of the hitpoint |
514 | 514 | minus the center: |
515 | 515 |
|
516 | | -  |
| 516 | +  |
517 | 517 |
|
518 | 518 | On the earth, this implies that the vector from the earth’s center to you points straight up. Let’s |
519 | 519 | throw that into the code now, and shade it. We don’t have any lights or anything yet, so let’s just |
|
552 | 552 |
|
553 | 553 | And that yields this picture: |
554 | 554 |
|
555 | | -  |
| 555 | +  |
556 | 556 |
|
557 | 557 | Now, how about several spheres? While it is tempting to have an array of spheres, a very clean |
558 | 558 | solution is the make an “abstract class” for anything a ray might hit and make both a sphere and a |
|
728 | 728 | This yields a picture that is really just a visualization of where the spheres are along with their |
729 | 729 | surface normal. This is often a great way to look at your model for flaws and characteristics. |
730 | 730 |
|
731 | | -  |
| 731 | +  |
732 | 732 |
|
733 | 733 |
|
734 | 734 |
|
|
786 | 786 | For a given pixel we have several samples within that pixel and send rays through each of the |
787 | 787 | samples. The colors of these rays are then averaged: |
788 | 788 |
|
789 | | -  |
| 789 | +  |
790 | 790 |
|
791 | 791 | Putting that all together yields a camera class encapsulating our simple axis-aligned camera from |
792 | 792 | before: |
|
853 | 853 | Zooming into the image that is produced, the big change is in edge pixels that are part background |
854 | 854 | and part foreground: |
855 | 855 |
|
856 | | -  |
| 856 | +  |
857 | 857 |
|
858 | 858 |
|
859 | 859 |
|
|
872 | 872 | direction randomized. So, if we send three rays into a crack between two diffuse surfaces they will |
873 | 873 | each have different random behavior: |
874 | 874 |
|
875 | | -  |
| 875 | +  |
876 | 876 |
|
877 | 877 | They also might be absorbed rather than reflected. The darker the surface, the more likely |
878 | 878 | absorption is. (That’s why it is dark!) Really any algorithm that randomizes direction will produce |
|
883 | 883 | Pick a random point s from the unit radius sphere that is tangent to the hitpoint, and send a ray |
884 | 884 | from the hitpoint $p$ to the random point $s$. That sphere has center $(p + N)$: |
885 | 885 |
|
886 | | -  |
| 886 | +  |
887 | 887 |
|
888 | 888 | We also need a way to pick a random point in a unit radius sphere centered at the origin. We’ll use |
889 | 889 | what is usually the easiest algorithm: a rejection method. First, we pick a random point in the unit |
|
917 | 917 |
|
918 | 918 | This gives us: |
919 | 919 |
|
920 | | -  |
| 920 | +  |
921 | 921 |
|
922 | 922 | Note the shadowing under the sphere. This picture is very dark, but our spheres only absorb half the |
923 | 923 | energy on each bounce, so they are 50% reflectors. If you can’t see the shadow, don’t worry, we will |
|
939 | 939 |
|
940 | 940 | That yields light grey, as we desire: |
941 | 941 |
|
942 | | -  |
| 942 | +  |
943 | 943 |
|
944 | 944 | There’s also a subtle bug in there. Some of the reflected rays hit the object they are reflecting |
945 | 945 | off of not at exactly $t=0$, but instead at $t=-0.0000001$ or $t=0.00000001$ or whatever floating |
|
1082 | 1082 | For smooth metals the ray won’t be randomly scattered. The key math is: how does a ray get |
1083 | 1083 | reflected from a metal mirror? Vector math is our friend here: |
1084 | 1084 |
|
1085 | | -  |
| 1085 | +  |
1086 | 1086 |
|
1087 | 1087 | The reflected ray direction in red is just $(v + 2B)$. In our design, $N$ is a unit vector, but $v$ |
1088 | 1088 | may not be. The length of $B$ should be $dot(v,N)$. Because $v$ points in, we will need a minus |
|
1174 | 1174 |
|
1175 | 1175 | Which gives: |
1176 | 1176 |
|
1177 | | -  |
| 1177 | +  |
1178 | 1178 |
|
1179 | 1179 | We can also randomize the reflected direction by using a small sphere and choosing a new endpoint |
1180 | 1180 | for the ray: |
1181 | 1181 |
|
1182 | | -  |
| 1182 | +  |
1183 | 1183 |
|
1184 | 1184 | The bigger the sphere, the fuzzier the reflections will be. This suggests adding a fuzziness |
1185 | 1185 | parameter that is just the radius of the sphere (so zero is no perturbation). The catch is that for |
|
1208 | 1208 |
|
1209 | 1209 | We can try that out by adding fuzziness 0.3 and 1.0 to the metals: |
1210 | 1210 |
|
1211 | | -  |
| 1211 | +  |
1212 | 1212 |
|
1213 | 1213 |
|
1214 | 1214 |
|
|
1223 | 1223 | there is a refraction ray at all. For this project, I tried to put two glass balls in our scene, and |
1224 | 1224 | I got this (I have not told you how to do this right or wrong yet, but soon!): |
1225 | 1225 |
|
1226 | | -  |
| 1226 | +  |
1227 | 1227 |
|
1228 | 1228 | Is that right? Glass balls look odd in real life. But no, it isn’t right. The world should be |
1229 | 1229 | flipped upside down and no weird black stuff. I just printed out the ray straight through the middle |
|
1236 | 1236 | Where $n$ and $n'$ are the refractive indices (typically air = 1, glass = 1.3–1.7, diamond = 2.4) |
1237 | 1237 | and the geometry is: |
1238 | 1238 |
|
1239 | | -  |
| 1239 | +  |
1240 | 1240 |
|
1241 | 1241 | One troublesome practical issue is that when the ray is in the material with the higher refractive |
1242 | 1242 | index, there is no real solution to Snell’s law and thus there is no refraction possible. Here all |
|
1309 | 1309 |
|
1310 | 1310 | We get: |
1311 | 1311 |
|
1312 | | -  |
| 1312 | +  |
1313 | 1313 |
|
1314 | 1314 | (The reader Becker has pointed out that when there is a reflection ray the function returns `false` |
1315 | 1315 | so there are no reflections. He is right, and that is why there are none in the image above. I |
|
1391 | 1391 |
|
1392 | 1392 | This gives: |
1393 | 1393 |
|
1394 | | -  |
| 1394 | +  |
1395 | 1395 |
|
1396 | 1396 |
|
1397 | 1397 |
|
|
1407 | 1407 | I first keep the rays coming from the origin and heading to the $z = -1$ plane. We could make it the |
1408 | 1408 | $z = -2$ plane, or whatever, as long as we made $h$ a ratio to that distance. Here is our setup: |
1409 | 1409 |
|
1410 | | -  |
| 1410 | +  |
1411 | 1411 |
|
1412 | 1412 | This implies $h = tan(\theta/2)$. Our camera now becomes: |
1413 | 1413 |
|
|
1452 | 1452 |
|
1453 | 1453 | gives: |
1454 | 1454 |
|
1455 | | -  |
| 1455 | +  |
1456 | 1456 |
|
1457 | 1457 | To get an arbitrary viewpoint, let’s first name the points we care about. We’ll call the position |
1458 | 1458 | where we place the camera _lookfrom_, and the point we look at _lookat_. (Later, if you want, you |
|
1464 | 1464 | vector for the camera. Notice we already we already have a plane that the up vector should be in, |
1465 | 1465 | the plane orthogonal to the view direction. |
1466 | 1466 |
|
1467 | | -  |
| 1467 | +  |
1468 | 1468 |
|
1469 | 1469 | We can actually use any up vector we want, and simply project it onto this plane to get an up vector |
1470 | 1470 | for the camera. I use the common convention of naming a “view up” (_vup_) vector. A couple of cross |
1471 | 1471 | products, and we now have a complete orthonormal basis (u,v,w) to describe our camera’s orientation. |
1472 | 1472 |
|
1473 | | -  |
| 1473 | +  |
1474 | 1474 |
|
1475 | 1475 | Remember that `vup`, `v`, and `w` are all in the same plane. Note that, like before when our fixed |
1476 | 1476 | camera faced -Z, our arbitrary view camera faces -w. And keep in mind that we can -- but we don’t |
|
1520 | 1520 |
|
1521 | 1521 | to get: |
1522 | 1522 |
|
1523 | | -  |
| 1523 | +  |
1524 | 1524 |
|
1525 | 1525 | And we can change field of view to get: |
1526 | 1526 |
|
1527 | | -  |
| 1527 | +  |
1528 | 1528 |
|
1529 | 1529 |
|
1530 | 1530 |
|
|
1549 | 1549 | computed (the image is projected upside down on the film). Graphics people usually use a thin lens |
1550 | 1550 | approximation. |
1551 | 1551 |
|
1552 | | -  |
| 1552 | +  |
1553 | 1553 |
|
1554 | 1554 | We also don’t need to simulate any of the inside of the camera. For the purposes of rendering an |
1555 | 1555 | image outside the camera, that would be unnecessary complexity. Instead I usually start rays from |
1556 | 1556 | the surface of the lens, and send them toward a virtual film plane, by finding the projection of the |
1557 | 1557 | film on the plane that is in focus (at the distance `focus_dist`). |
1558 | 1558 |
|
1559 | | -  |
| 1559 | +  |
1560 | 1560 |
|
1561 | 1561 | For that we just need to have the ray origins be on a disk around `lookfrom` rather than from a |
1562 | 1562 | point: |
|
1628 | 1628 |
|
1629 | 1629 | We get: |
1630 | 1630 |
|
1631 | | -  |
| 1631 | +  |
1632 | 1632 |
|
1633 | 1633 |
|
1634 | 1634 |
|
|
1680 | 1680 |
|
1681 | 1681 | This gives: |
1682 | 1682 |
|
1683 | | -  |
| 1683 | +  |
1684 | 1684 |
|
1685 | 1685 | An interesting thing you might note is the glass balls don’t really have shadows which makes them |
1686 | 1686 | look like they are floating. This is not a bug (you don’t see glass balls much in real life, where |
|
0 commit comments