11/29/01CS 559, Fall 2001 Today Photorealistic rendering Algorithms for producing high-quality images Ways of deciding which algorithm for use

11/29/01CS 559, Fall 2001 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

11/29/01CS 559, Fall 2001 The Light of Mies van der Rohe Image by Henrik Wann Jensen

11/29/01CS 559, Fall 2001 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 Light leaving Emitted light SumReflection: BRDF Incoming light Incoming light reflected at the point

11/29/01CS 559, Fall 2001 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

11/29/01CS 559, Fall 2001 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

11/29/01CS 559, Fall 2001 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 ? LightEye

11/29/01CS 559, Fall 2001 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?

11/29/01CS 559, Fall 2001 Modified Cornell box, due to Henrik Wann Jensen More Complex Light Paths Find the following: –LE –LDE –LSE –LDDE –LDSE –LSDE

11/29/01CS 559, Fall 2001 More Complex Light Paths LE LDDE LDE LSDE LSE LDSE

11/29/01CS 559, Fall 2001 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

11/29/01CS 559, Fall 2001 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

11/29/01CS 559, Fall 2001 Raytracing Shadow rays Reflection ray Transmitted ray

11/29/01CS 559, Fall 2001 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?

11/29/01CS 559, Fall 2001 PCKTWTCH by Kevin Odhner, POV-Ray

11/29/01CS 559, Fall 2001 Kettle, Mike Miller, POV-Ray

11/29/01CS 559, Fall 2001

11/29/01CS 559, Fall 2001 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

11/29/01CS 559, Fall 2001 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

11/29/01CS 559, Fall 2001 Distribution Raytracing Depth of Field

11/29/01CS 559, Fall 2001 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?

11/29/01CS 559, Fall 2001 “Correct”Raytraced

11/29/01CS 559, Fall 2001 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

11/29/01CS 559, Fall 2001 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?

11/29/01CS 559, Fall 2001 Caustics Standard raytracerBi-directional raytracer More rays in the light pass Note the LS*DS*E paths

11/29/01CS 559, Fall 2001 Refraction caustic

11/29/01CS 559, Fall 2001 Refraction caustics

11/29/01CS 559, Fall 2001 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

11/29/01CS 559, Fall 2001 Real World LD*E Paths

11/29/01CS 559, Fall 2001 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

11/29/01CS 559, Fall 2001 Radiosity Equation Derived from the global illumination equation using radiosity assumptions B i is the radiosity (brightness) of patch i  i is the diffuse reflection coefficient F ij 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

11/29/01CS 559, Fall 2001 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

11/29/01CS 559, Fall 2001 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

11/29/01CS 559, Fall 2001 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