Today

1. Today • Photorealistic rendering • Algorithms for producing high-quality images • Ways of deciding which algorithm for use CS 559, Fall 2001

2. Lighting Revisited • Some applications are intended to produce pictures that look photorealistic, or close to it • The image should look like a photograph • A better metric is perceptual: the image should generate a target set of perceptions • Applications include: Film special effects, Training simulations, Computer games, Architectural visualizations, Psychology experiments, … • To achieve the goal of photorealism, we must think carefully about light and how it interacts with surfaces • What you should take away: The various aspects of light interaction and how algorithms capture or ignore them CS 559, Fall 2001

3. The Light of Mies van der Rohe Image by Henrik Wann Jensen CS 559, Fall 2001

4. Global Illumination Equation • If we wish to compute perfect illumination, we need to solve the global illumination equation • The light leaving a point (what we see) is a combination of light it emits and light it reflects • The light it reflects depends on what light arrives and how it reflects it Emitted light Sum Reflection: BRDF Incoming light Light leaving Incoming light reflected at the point CS 559, Fall 2001

5. Photorealistic Lighting • Photorealistic lighting requires solving the equation! • Not possible in the general case with today’s technology • Light transport is concerned with the “incoming light” part of the equation • Notice the chicken and egg problem • To know how much light leaves a point, you need to know how much light reaches it • To know how much light reaches a point, you need to know light leaves every other point • Reflectance modeling is concerned with the BRDF • Hard because BRDFs are high dimensional functions that tend to change as surfaces change over time CS 559, Fall 2001

6. Classifying Rendering Algorithms • We can’t solve the general global illumination equation • But we can solve some special cases, to some degree of accuracy • We can classify rendering algorithms according to the type of light interactions they capture • For example: The OpenGL lighting model captures: • Direct light to surface to eye light transport • Diffuse and rough specular surface reflectance • It actually doesn’t do light to surface transport correctly, because it doesn’t do shadows • We would like a way of classifying interactions: light paths CS 559, Fall 2001

7. Classifying Light Paths • Classify light paths according to where they come from, where they go to, and what they do along the way • Assume only two types of surface interactions: • Pure diffuse, D • Pure specular, S • Assume all paths of interest: • Start at a light source, L • End at the eye, E • Use regular expressions on the letters D, S, L and E to describe light paths • Valid paths are L(D|S)*E ? Light Eye CS 559, Fall 2001

8. Simple Light Path Examples • LE • The light goes straight from the source to the viewer • LDE • The light goes from the light to a diffuse surface that the viewer can see • LSE • The light is reflected off a mirror into the viewer’s eyes • L(S|D)E • The light is reflected off either a diffuse surface or a specular surface toward the viewer • Which does OpenGL (approximately) support? CS 559, Fall 2001

9. More Complex Light Paths • Find the following: • LE • LDE • LSE • LDDE • LDSE • LSDE Modified Cornell box, due to Henrik Wann Jensen CS 559, Fall 2001

10. More Complex Light Paths LE LDDE LSDE LSE LDSE LDE CS 559, Fall 2001

11. The OpenGL Model • The “standard” graphics lighting model captures only L(D|S)E • It is missing: • Light taking more than one diffuse bounce: LD*E • Should produce an effect called color bleeding, among other things • Approximated, grossly, by ambient light • Light refracted through curved glass • Consider the refraction as a “mirror” bounce: LDSE • Light bouncing off a mirror to illuminate a diffuse surface: LS+D+E • Many others CS 559, Fall 2001

12. Raytracing • Cast rays out from the eye, through each pixel, and determine what they hit first • Cast additional rays from the hit point to determine the pixel color • Shadow rays toward each light. If they hit something, then the object is shadowed from that light, otherwise use “standard” model for the light • Reflection rays for mirror surfaces, to see what should be reflected in the mirror • Transmission rays to see what can be seen through transparent objects • Sum all the contributions to get the pixel color CS 559, Fall 2001

13. Raytracing Shadow rays Reflection ray Transmitted ray CS 559, Fall 2001

14. Recursive Ray Tracing • When a reflected or refracted ray hits a surface, repeat the whole process from that point • Send out more shadow rays • Send out new reflected ray (if required) • Send out a new refracted ray (if required) • Generally, reduce the weight of each additional ray when computing the contributions to surface color • Stop when the contribution from a ray is too small to notice • What light paths does recursive ray tracing capture? CS 559, Fall 2001

15. PCKTWTCH by Kevin Odhner, POV-Ray CS 559, Fall 2001

16. Kettle, Mike Miller, POV-Ray CS 559, Fall 2001

17. CS 559, Fall 2001

18. Raytracing Implementation • Raytracing breaks down into two tasks: • Constructing the rays to cast • Intersecting rays with geometry • The former problem is simple vector arithmetic • The intersection problem arises in many areas of computer graphics • Collision detection • Other rendering algorithms CS 559, Fall 2001

19. Raytracing Summary • Raytracing can do reflection and refraction, its primary advantage over OpenGL’s model • Raytracing can also do: • Soft shadows from area light sources • Texture, bump and displacement mapping, easily • Distributed ray tracing: Depth of field, motion blur and soft reflections • Relatively simple to implement • A basic raytracer can be written in a few hundred lines of code • But it’s slow: fails to take advantage of coherence CS 559, Fall 2001

20. Distribution Raytracing Depth of Field CS 559, Fall 2001

21. Raytracing And Light Paths • A ray can be traced from its origin through any number of specular bounces, until it hits something diffuse • We know which way to send the ray after a specular bounce • We don’t know where to send it after a diffuse bounce • Rays do Origin-S*-Hit • Which light paths does a basic raytracer capture? • Which can it not capture? CS 559, Fall 2001

22. “Correct” Raytraced CS 559, Fall 2001

23. Missing Paths • Basic recursive raytracing cannot do: • LS*D+E: Light bouncing off a shiny surface like a mirror and illuminating a diffuse surface • LD+E: Light bouncing off one diffuse surface to illuminate others • Problem: The raytracer doesn’t know where to send rays out of the diffuse surface to capture the incoming light • Also a problem for rough specular reflection • Fuzzy reflections in rough shiny objects CS 559, Fall 2001

24. Bi-directional Raytracing • Cast rays from the light sources out into the scene • “Light-ray” tracing, starting at the light • When a ray hits a diffuse surface, accumulate some light there • Surfaces record the amount of light that hits them • Store the light in texture maps • Store the light in quadtrees • Store the light in photon maps • Cast rays from the eye out into the scene • When a ray hits a diffuse surface, look up the amount of light that hit it in the light-ray phase • What paths does it capture? • What sort of visual effects do you see? CS 559, Fall 2001

25. Caustics Standard raytracer Bi-directional raytracer More rays in the light pass Note the LS*DS*E paths CS 559, Fall 2001

26. Refraction caustic CS 559, Fall 2001

27. Refraction caustics CS 559, Fall 2001

28. Still Missing… • LD*E paths – Diffuse-diffuse transport • Formulated and solved with radiosity methods • L(S|D)*E paths • Solved with Monte-Carlo renderers • Send out random rays of light and see where they go • Very very inefficient (in terms of time) • Also solvable with multi-pass methods, but also very very inefficient (in terms of space), and subject to aliasing • An unsolved (unsolvable?) problem CS 559, Fall 2001

29. Real World LD*E Paths CS 559, Fall 2001

30. Radiosity Assumptions • All surfaces are perfectly diffuse • Means that is doesn’t matter which way light hits or leaves a surface • Illumination is constant over a patch • Can break the world up into a discrete number of pieces • Problems at sharp illumination boundaries - shadows • Ways around these problems, but less efficient and less able to manage scene complexity • Assumptions allow us to solve for LD*E paths CS 559, Fall 2001

31. Radiosity Equation • Derived from the global illumination equation using radiosity assumptions • Bi is the radiosity (brightness) of patch i • i is the diffuse reflection coefficient • Fij is the form factor, which quantifies how much light patch j contributes to patch i • The brightness of each patch depends on how much light it gets from all the others, and its diffuse reflection CS 559, Fall 2001

32. Solving the Radiosity Eqn • Radiosity algorithms use one of several methods to solve the radiosity equation • Basically a very large linear system, so techniques can all be mapped onto linear system solvers • A large part of the computation is in finding form factors • Describe how much light gets from each patch to every other patch • Geometric in nature - do not depend on the illumination, just the layout of the scene • Another key factor is finding good meshing strategies - ways of laying out the patches CS 559, Fall 2001

33. Radiosity Example • Color bleeding is extreme in this example • Textures are applied after solving for illumination • Some meshing artifacts are visible - note the banding around the pictures on the wall CS 559, Fall 2001

34. Radiosity Meshing • Each patch is colored with its illumination • Note the discrete nature of the solution • The previous image was obtained by pushing color to vertices and then Gourand shading CS 559, Fall 2001