Advanced Ray Tracing - 98/01/26 ------------------------------- Pete hasn't graded dookey. Don't expect any feedback. Yet... Next HW is easy if you set up mental model right. Unbelievable pain if you have no clue. Today is the only day we'll cover it. Adaptive chatter -- anywhere you have high variance, blur it. Pete: go thru and and find high variance spots in image, then spread out the energy to neighboring pixels. Variance mapping. Four-corners. Camera lens sampling - - - - - - - - - - In current code, probably have a viewpoint ("lookFrom"), a virtual screen out there. When it's time to sample, you send a ray from lookFrom thru a screen point (lookFrom + t*(onScreen-lookFrom)). Screen is d away, screen pix (0,0) to (nx,ny) and scene coords (xmin,ymin) and (xmax,ymax). Point onScreen=(?,?,d)=(xmin+(a/nx)(xmax-xmin),ymin+(b/ny)(ymax-ymin),d). Then do a change of coords from xyz origin to lookFrom/lookDir coords: lookFrom+t*M*v [v is onScreen] you ought to have the ray you need. Computing the rays is usually the bottleneck. How to optimize? Given input (a,b), first go to onScreen, then go to M*onScreen. This is unnecessarily slow. Why? Should be able to go from (a,b,0) straight to the answer by composing onScreen generation and M. Actually easier to think about if you just make a unit vector class, then normalize Mv, make v be v-hat, etc. [doesn't necc. go faster, but is easier to think about]. Handout on system in ~cs431/[schedule for winter] and some other junk in there... Note Pete's screen is not centered in front of the viewer's nose... Also, vup needn't be perp to lookAt, it just defines a plane. Anyway, so why do it off center? To make stereo pairs! Interactive ray tracers on head displays, etc. Reasons: stereo pairs, tiling (dist'n), head tracking. Want xmin/ymin, xmax/ymax (film size/focal length vs. field of view) so you can shift things around to line stuff up... Also, allow for non-square pixels for printers w/ns pixels. This is the normal way to do things (pinhole camera). Pinhole camera. (picture of a pinhole camera) image ends up upside down and backwards. Call the hole "cp" for "center of projection". Problem with these is that the hole is small. Making the hole bigger means light doesn't just come from one direction; it comes from many directions. The farther away things got, the more they get blurred onto the screen, 'cause one pt gets projected onto a cone... Darkening toward the fringe on a a pinhole camera, 'cause off-axis the hole becomes a thinning ellipse. Solve all these problems by using a lens. Could model the lens; shoot a ray out, thry the lens, diffract it, and see where it goes! Ideally, rays thru lens converge on a point in space. Ends up really being integrating over the lens. Real camera have lots of lenses, interreflection, anti- refl coatings. Idealized lens is a "thin lens" -- zero thickness. These are impossible in real life, but real lens systems end up being approx to thin lenses, so we win by using a thin lens instead! If you view the behavior of thin lens as a basis, and compare to real camera lens, they're really close. Thin lens: has a radius and a position -- actually they're planes; like giant Fresnel lenses. Any light that goes thru center at any angle is unperturbed. Also, convergence (focus) is perfect. All light originating from the same point, thru any point on the lens, converges at exactly the same point. So if you know the convergence point, you know where any ray goes. So you know d0 from p0 to lens center, and d1 from lens center out to p1... If you know d0, d1, p0, then you know p1. Properties of thin lenses: 1. Light thru center doesn't bend 2. All light from p0 converges at some p1 3. Thin lens law is: 1/F = 1/d0 + 1/d1 F is focal length of lens ("how good it is at bending light") Thin lens law tells you d1 = [ 1/F - 1/d0 ]^-1 = F d0 / (d0 - F) So if d0=F, you focus on infinity. In a thin lens camera, you focus on a plane. Real camera on the boundaries diverge from this behavior... If you set R=0, it's a pinhole camera. Means you only need one camera class. Camera picks random point on film, random point on lens, you figure out where it goes (magic point is intersection of ray with plane of perfect focus). Problem with putting film in scene is that it lives in the plane of perfect focus, which might be at infinity. This becomes an implementation problem. Can get around it by forcing the user to enter d1. Want to become regular users of which defines things like MAXFLOAT. You'd rather the user ender d1 (that's what you enter on a real lens). That's the beef. We know: stratified sampling is good. Noise is bad. UF random is noisy. Suppose there's a coordinate system (u,v) on the lens. Pixel is (x,y). The sample (u,v,x,y) somehow gets turned into a ray: u=r cos phi r = Rsqrt(drand48) x=drand48 v=r cos phi phi = 2*Pi*drand48 y=drand48 Statify on lens: take 4 sample (say), then will map samples in the four cartesian cells onto a disc (not area preserving). Stratify on pixel: same idea. Stratification in 4D for 16 samples means a 2x2x2x2 grid. Doesn't map well into the stratified pixel. Suppose the world is the checkerboard. No such thing as a lens. What does strateifying on the pixel do for you? It forces only the guys on the boundary to be the only things with choice. Decreasing the avg. error 'cause big regions give deterministic errors. Minimizes maximum error (fewer pops in image), makes average error smaller (smoother image). Think of the lens now: we're only looking at the center of each pixel. Objects at plane of perfect focus have all the rays go the sample place. Objects not at that plane: half hit the object, half hit the background; the lens sees half black/white (lens averages it). Ideally you'd like a cartesian stratefication on the lens (Pete's paper). If you're on the sort of pixel where the noise is coming from the lens seeing half obj/half BG, you want to stratefy on the lens. When the object is in focus, you want the pixel stratefied. Rectangle-world: could strat in X and strat in Y: xi=(i+drand48)/N, yi=(i+drand48)/N Ends up doing real bad in XY. So, if you have 16 samples (ui,vi) nicely stratefied on lens, and same on pixel, you get an analogous situation -- UL of pixel likely to sample UL of lens; will get subtle artefacts you'll see in animation. Back on xi/yi: To win, you take a random permutation. If you shuffle the y values, you get, eg. (x0,y1),(x1,y4),(x2,y2),(x3,3),(x4,y0). It's fair (you won't get weird correlation artefacts). Sampling is stratefied. H/V edges will be AA'd great. Diagonals will be AA's like uniform; no worse than you'd have otherwise. Fairness is the concern. Shuffling 17 requires generating 0..16 fairly. Just a mod is slightly unfair. Upshot: randomly pair up the x and y's, each of which are stratefied. Is sometimes called N-rooks sampling 'cause N-rooks can't take each other. [ Solutions to N-queens do better on diagonal artefacts... ? ] Open shutter: close shutter, for animation. Take 16 samples in time as well (stratefied)! Motion will blur, animation will look lots better. Square camera lens makes it easier, and we don't notice. Look up: mpegencode... Might want to write a random class that, say you want 7 dimensions of random numbers, and you want them stratefied 2,2,2,1 or somesuch. Use real units in code.