© 2005 University of Wisconsin Last Time More LTE Path Tracing 02/14/05 © 2005 University of Wisconsin

© 2005 University of Wisconsin Today Re-using paths Irradiance Caching Photon Mapping 02/14/05 © 2005 University of Wisconsin

Pure Path Tracing: the Good Path tracing concentrates on important paths only Those that hit the eye Those from bright emitters/reflectors No need for meshing General surfaces – only requires ray intersections Unbiased estimates – at any point, the expected value is correct (although variance might be high) 02/14/05 © 2005 University of Wisconsin

Pure Path Tracing: the Bad It treats every pixel independently, and every point on every surface independently Good for specularities, which vary quickly over surfaces Bad for diffuse illumination, which varies very slowly over surfaces (except at sharp shadow boundaries) Effort is wasted getting good estimates for Direct illumination, which is responsible for the most obvious illumination discontinuities (edges) Diffuse illumination, which varies slowly over a surface 02/14/05 © 2005 University of Wisconsin

© 2005 University of Wisconsin Path Re-Use Consider a diffuse surface for which we want an outgoing radiance estimate Typically, we would cast more rays to get it, but what if we already know what happened at a nearby spot? 02/14/05 © 2005 University of Wisconsin

© 2005 University of Wisconsin Diffuse Dependency Diffuse reflectance depends only on the irradiance at the surface point The total amount of light arriving – incoming direction is irrelevant This tends to vary slowly over a surface Directional light gives constant irradiance over a planar surface Point light varies only with the cosine of the angle – slowly What leads to sharp changes? 02/14/05 © 2005 University of Wisconsin

© 2005 University of Wisconsin Basic Idea Store information about previous paths When the irradiance at a point is required, construct irradiance estimates from the stored data Variants on what you store and how the estimate is computed, as we’ll see The sub-problems are: How do you get the samples in the first place? How to you store them? How do you construct the estimate? 02/14/05 © 2005 University of Wisconsin

Irradiance Caching (PBR 16.4) Start with a basic path tracing algorithm, but … Maintain a spatial data structure storing examples of irradiance arriving at points If you hit a diffuse surface, try to build an estimate of irradiance at that point – but always compute direct lighting explicitly If the estimate is good, use it If not, use path tracing to estimate the irradiance and store it Some questions: How do we store the samples? How do we decide whether to use an old value, or compute a new one? 02/14/05 © 2005 University of Wisconsin

© 2005 University of Wisconsin Storing Samples It doesn’t much matter how you store the samples Data structure must support insertion of new samples, and search for nearby samples, indexed on position The RADIANCE system is an implementation of Irradiance Caching, and it uses Octrees Question of precisely what to store: Irradiance (how we compute this comes next …) The location The normal at that location (more later …) The distance that we went to find nearby surfaces (more later …) 02/14/05 © 2005 University of Wisconsin

© 2005 University of Wisconsin Computing Irradiance Use standard Monte Carlo estimator for Irradiance Use path tracing to get samples of the incoming radiance – just like estimating incoming radiance to a pixel Stratify outgoing directions according to cosine weighted distribution 02/14/05 © 2005 University of Wisconsin

Quality of Existing Data The quality of an estimate is based on geometric considerations Examine: Surface curvature between the required point and the existing data diffuse illumination changes with curvature Brightness and the distance to other surfaces Influences how fast incoming illumination can change Assume extreme variation in incoming radiance If existing values are used, weigh contribution by quality 02/14/05 © 2005 University of Wisconsin

© 2005 University of Wisconsin Geometric Factors Small distance, but maybe big change in irradiance Points and normals should be close Distance to nearby surfaces should be large – corners lead to fast changes in irradiance 02/14/05 © 2005 University of Wisconsin

Locations of Estimates PBR Fig 16.10 02/14/05 © 2005 University of Wisconsin

Trading Variance for Bias Irradiance Caching is a biased algorithm – there is no guarantee it computes the right result Where does the error come from? PBR Fig 16.9 02/14/05 © 2005 University of Wisconsin

© 2005 University of Wisconsin Implementation Notes In a full system, choices must be made as to what constitutes a diffuse surface PBRT assumes anything that isn’t specular Error goes up as reflectance varies further from diffuse Specular bounces are traced through to a diffuse surface Have to be careful not to double count, but not too much of a problem Also have to make sure that direct lighting is not double counted Must account for transmission and reflection Separate irradiance estimates for both sides of a surface 02/14/05 © 2005 University of Wisconsin

Irradiance Caching Failure Modes? Under what circumstances will irradiance caching fail? What direction does it trace rays from? What does it assume about BSDFs? The commercial-quality implementation of this algorithm allows users to mark “secondary light sources” The outgoing radiance field of these surfaces is estimated in a pre-process, then they are treated as light sources 02/14/05 © 2005 University of Wisconsin

© 2005 University of Wisconsin Particle Tracing Some sub-paths are best sampled from the light Anything where light is focused – caustics Situations where most of the light’s energy goes to a small region of the world We can fill our cache of radiance values by sampling from the light – particle tracing Several variants … 02/14/05 © 2005 University of Wisconsin

Basic Particle Tracing Send out packets from light sources, distributed according to a particular model (eg spotlight, area light, …) Store some portion of the energy at each surface, on a predefined mesh – typically use textures for storage Trace eye rays to render final image, or render textures directly 02/14/05 © 2005 University of Wisconsin

Adaptive Radiosity Textures Heckbert 90 Store intensity in textures attached to the surfaces Works for anything with reasonable texture coordinates Texture is stored as a quadtree, and adapted Shoot from lights to add intensity to textures Also shoot from bright surfaces to get diffuse-diffuse transport Eye ray trace to render, with direct lighting operation at each visible pixel 02/14/05 © 2005 University of Wisconsin

© 2005 University of Wisconsin Photon Mapping A very well thought out version of particle tracing Break LTE into several components LDS*E and LS*E paths LS*DS*E paths L(S|D)*DDS*E paths Use a different technique for each component Note that S*E part is common – always start by tracing rays from the eye through specular bounces to a diffuse surface (or a light) This is the “gather” operation for a pixel 02/14/05 © 2005 University of Wisconsin

© 2005 University of Wisconsin Gathering Phase For each pixel cast ray and get hit point Compute three contributions Direct illumination (and shadows) Caustic illumination from a caustic map Indirect illumination: sample reflection directions and estimate incoming power from a global map 02/14/05 © 2005 University of Wisconsin

© 2005 University of Wisconsin Why Gather? PBR Fig 16.17 Photon map lookup at first hit Lookup for indirect only 02/14/05 © 2005 University of Wisconsin

© 2005 University of Wisconsin What’s in the Map? Photon maps store Position Incoming direction Incoming proportion of light’s power (radiant flux, ) Optional: store a normal Estimation from map: Find nearest neighbors (ignore those with very dissimilar normal) Compute estimate of outgoing radiance 02/14/05 © 2005 University of Wisconsin

Building the Photon Maps Randomly sample paths from the light Randomly choose a light/position/direction, cast a ray Store a sample where it hits A sample is: position, direction, weight Sample a direction from the hit pt’s BRDF, cast a ray Degrade weight according to BRDF Repeat using Russian Roulette If the path only experiences specular bounces form the light, store in the caustic map, otherwise in the global map 02/14/05 © 2005 University of Wisconsin

© 2005 University of Wisconsin Photon Locations Doesn’t tell you power – not all photons are equal PBR Fig 16.14 02/14/05 © 2005 University of Wisconsin

© 2005 University of Wisconsin Effects of Gather PBR Fig 16.20 Direct lighting Photon map directly Photon map indirect 02/14/05 © 2005 University of Wisconsin

© 2005 University of Wisconsin Caustic Example PBR Fig 16.18 02/14/05 © 2005 University of Wisconsin

© 2005 University of Wisconsin Sample Image © Henrik wan Jensen 02/14/05 © 2005 University of Wisconsin

© 2005 University of Wisconsin More Impressive © Henrik wan Jensen 02/14/05 © 2005 University of Wisconsin

© 2005 University of Wisconsin Photon Map Summary Combines various techniques depending on the situation Produces very good results reasonably efficiently Geometric problems can still cause bleeding Sampling from the light can cause problems if most of the light’s power fails to reach the image 02/14/05 © 2005 University of Wisconsin

© 2005 University of Wisconsin Photon Map Failure 02/14/05 © 2005 University of Wisconsin

© 2005 University of Wisconsin With Better Sampling 02/14/05 © 2005 University of Wisconsin

© 2005 University of Wisconsin Next Time Radiosity 02/14/05 © 2005 University of Wisconsin