Personal Information

Name: George Bernard Laskowsky Ziguilinsky
E-mail address: georgelaskowsky@gmail.com
Nick: glaskows

Idea to Implement

Synopsis and Goals.

Irradiance Caching (IC from now on) is a technique for computing global illumination on diffuse surfaces reasonably fast. Its concern is the indirect illumination bouncing from one diffuse surface to another.

The main idea is to implement IC inside Yafaray's two-pass photon mapping algorithm, specifically for improving the speed and quality of indirect illumination on diffuse (Lambertian) surfaces, which is the most costly component to compute in a Monte Carlo ray tracer (this is the case even if we only compute the first bounce of diffuse illumination, like in Final Gather).

Detailed description.

The problem with techniques for indirect illumination is that for every intersection/reflection we need to calculate a Monte Carlo integrator for the incoming radiance. In Yafaray it is used a simplification which consist in using the integrator only at the accurate computation and the global photo map in the approximate evaluation.

IC can exploit the main characteristic of indirect illumination (without caustics, which use another photon map): its slow rate of change (spatial coherence). Instead of integrating in every bounce, we can use past results saved on a cache for estimating the irradiance in p by interpolation.

It is utterly crucial to have a good way to tell when we can use cached result and when we need to make a new Monte Carlo ray trace. Special cases must be dealt if we want to have noiseless pictures.

The main steps of the IC should be, for every reflection:

• Check if we can use cached irradiance through interpolation:
  • Weight function (taking into account irradiance gradients) result is positive. This create a validity area for the record which can be tuned by the user through a constant. The bigger the constant, more records will be used, resulting in a larger interpolation error. I propose using Tabellion and Lamorlette version for a smother result.
  • "In front" test (Ward et al. suggestion). This eliminates the lack of indirect illumination provided by step like elements.
• If there is more than one record in the set, interpolate irradiance at p using their values and gradients.
• If there isn't any useful cached irradiance, calculate a new record through Monte Carlo.
  • Special care must be taken when computing the distant to surfaces (via harmonic mean or minimum length), being the record weight proportional to it.  In corners this value is too small, and then we have too many samples. In open spaces, lots of rays are lost, then the value is too large and we have a sparse cache. I propose at least clamping to a maximum and minimum in screen space and using the neighbor clamping technique.

In the photon integrator of yafaray (photonintegr.h, .c) there an option to include IC. In photonIntegrator_t::integrate(), where all the integration occurs, the call to irradianceCache_t::gatherSamples() start the IC process. The current implementation is incomplete and presents bad results, so there is a great need for fixing this.

There should be at least four classes (two of them are pure virtual):

1. irradianceRecord_t: has the irradiance information, the gradients (rotation and translation) and the weight. 
2. irradianceCache_t: creates, stores, searches and interpolates irradiance records with the aid of an octree. It should use two virtual helper classes: one for deciding the validity of a record (irradianceDiscriminator_v) and the other for the creation of records (irradianceCreator_v). The last one not only computes the weights but also should worry for special cases, like when it is used normal maps and displacement maps on the geometry.

Different algorithms should be implemented in different classes using the correct interface (following the strategy software pattern). This kind of modularity (decoupling) allows me to check and perform automated tests with different configurations, combining different algorithms for best speed or quality.

The drawback is the overhead in the virtual methods table. In the final release I should promote the best implementing classes and discard the virtual ones.

Finally, I should incorporate two techniques: importance sampling, it uses the radiance in the photon map so the sampling in the Monte Carlo method is directed to the regions with more flux, and, two-pass image rendering, which try to eliminate the "miss contribution" problem by populating the IC first and then making a second pass for the actual render.

Workflow and Usability

 The final user should be able to set at least three main parameters. One for turning IC on and off, a constant K and the number of radiance samples per irradiance record. K control the area of validity for each record (quality v/s speed).

Tentative schedule

• April 12 - April 18: finish my rgbe plugin for Yafaray. Only exporting is available at the moment. Current code can be found on [4].
• April 12 - April 25: read pbrt book for inspiration. Answer the questions of my mentor and community.
• Start
• April 26 - May 23: learn in depth the guts of Yafaray. Implement main classes and most naive algorithms (starting point for profiling)
• May 24 - July 15
  • May 24 - July 7: weight functions, gradients, ray length (minimum and mean)
  • July 8 - July 15:  clamping weigh to a maximum and minimum in screen space and using the neighbor clamping technique, "front" test.
• Midterm Deadline
• July 17 - August 9
  • July 17 - July 25: two-pass image rendering and bump maps.
  • July 26 - August 9: displacement maps and importance sampling.
  • August 10 - August 15: Clean code, correct documentation, find final bugs.
• Sleep

Biography

 I am a last year CS student at Federico Santa Maria University, in Valparaiso, Chile, South America, Planet Earth (http://tinyurl.com/ycd9je7).

Currently I work as a researcher in a high energy physics lab (www.silab.fis.utfsm.cl), developing a cosmic ray detector (software and hardware). I have always been interested in computer generated graphics, but I haven't done anything big, mainly old style opengl and some hlsl in XNA (also, I did implement a couple of simple programs that calculated the flux of photons on a optic fiber using the simplest optic equations). I am proficient in C, C++, Python, Java, Javascript and some other languages. I have been a basic user of Blender for some time.

Appendix: mathematical foundations

 In this section I want to present most of the equation I'll be using in the IC implementation. This is just a summary, not an in depth explanation.

Indirect Irradiance Calculation

Irradiance at a point p with normal n can be obtained from the incoming radiance over the hemisphere, ,

wich can be approximated through an stratified Monte Carlo estimator, which, for this particular case, yields the final irradiance estimaror ,

where L_j,k is the incoming radiance sample computed by tracing a ray in the direction ,

where  are two uniformly distributed random numbers in the range [0, 1), N denotes the number of divisions along Φ (azimuth) and M the number of divisions along Θ (elevation) in the hemisphere.

Irradiance Gradients

The calculus of the irradiance on a given point through interpolation can be greatly improve if we know how the irradiance in the cached samples changes when we move it over a surface or change it's orientation. The irradiance in a scene is a five dimensional scalar field and the gradient on each point can be represented through a five dimensional vector. In the program we will use 2 vectors, one for translation and one for rotation, and both will "live" in the tangent plane of the surface, so each one only represents two dof. For the calculations we use the same rays from the irradiance integral.

• Rotation gradient: it gives us a first order approximation of the irradiance change with rotation. Its direction is the axis of rotation that produce the fastest change in irradiance, its magnitude expresses how quickly the irradiance changes. This gradient is estimated using ,
  where v_k is a base-plane vector in the direction .
• Translation gradient: In this case we need to take in account the effect of parallax, where distant objects move slower than near ones, so in this case the lengths of rays are important. The gradient is estimated using ,
  where the minus and plus sign means going to border with the adjacent cell in the hemisphere.

Interpolation

The irradiance at p is equal to the weighted average of the "near" cached records 

E_i(p) equals to the irradiance contribution of sample i extrapolated to the point p 

Only If the weight w_i is bigger than 0, we add the cached record to the set S(p). where  

The term R_i is the approximated distance to the surfaces visible from the record p_i location. It is common to use the harmonic mean of the ray lengths (assuming a split sphere model)  or just the minimum .

Problem arise near corners where R_i is small even at close distances, so too many samples are cached. The opposite occurs in open spaces, where too many rays are lost in the distance. We need to clamp  R_i for preventing this.

There is also another test that check if record p_i is "in front" of p, where step like features, just besides p, which can contribute to indirect lighting, are ignored because p_i is near enough, if d_i is less than a small negative value then p_i is excluded from interpolation set. 

References

1. Henrik Wann Jensen. "Realistic Image Syntethis Using Photon Mapping". A K Peters. 2001.
2. Jaroslav Krivánek and Pascal Gautron. "Practical Global Illumination with Irradiane Caching" In Synthesis Lectures on Computer Graphics and Animation. Morgan & Claypool. 2009.
3. Matt Pharr and Greg Humphreys. "Physically Based Rendering: from Theory to Implementation". Morgan Kaufmann. 2004.
4. http://alumnos.inf.utfsm.cl/~glaskows/yafaray/code/rgbeUtils.h http://alumnos.inf.utfsm.cl/~glaskows/yafaray/code/rgbeHandler.cc