I have rewritten my renderer from scratch because the old code was too ugly to add anything useful on top of it . The new design is mainly based on pbrt , I’m also being inspired by other open source ray tracers like Picogen and LuxRender .

It now uses a sah based kd tree with a building  complexity of O (nlog(n)^2) to make the geometry intersection tests faster , I also made it multithreaded thanks to the simplicity of openmp.

Unfortunately even with these improvements my ray tracer struggles in scenes with strong indirect illumination , so I added metropolis light transport as proposed by Kelemen et a.l. , the result is impressive despite the fact that my implementation is unstable :

And another render showing the glossy dielectric material ( image rendered with path tracing + explicit direct light connection )

There is still a lot of improvement to be made,for example i can use a better heuristic to combine the paths (Balance heuristic,power heuristic…) ,but for now i’m going to stick with my current implementation and probabily move to another topic ,may be acceleration structures or BRDFs or even Fractal Flames…I don’t know

I didn’t posted since a while and i thought may be i should write something about my progress…

My current project is a Monte Carlo bidirectional path tracer aiming to be robust and fast  as much as it can be.One of its main  goals is to familiarize myself with Monte Carlo Methods and how we can apply various variance reduction  techniques to better solve the rendering equation.Obviously,the first step that i did is to implement the Light Tracing Algorithm which is very good at handling paths of the type L***DE,the second step is to find a way to combine a Light Path with an Eye Path and this is where all my nightmares began.To do so , I have two options:

-A uniform weighting scheme which treats all the paths as if they are “equal” .A major drawback of this technique is that the estimand can  have high variance and as a consequence all of the advantages of the light tracing step will be buried under the ground.

-With variable weights (as described in [1]) ,it weights  the paths based on their importance (i.e. important paths have weights closer to 1 and vice versa).

My implementation only supports uniform weighting scheme to combine the two paths ,and as it can be seen below in the images ,a naive BDPT can perform slightly better than a PT  for diffuse  scenes.

And here is another image which compares Light Tracing (left) to Path Tracing (right):

[1] Optimally Combining Sampling Techniques for Monte Carlo Rendering, Eric Veach Leonidas J. Guibas

I think depth of field is not well explained in most of cg papers that’s why I’ll shortly describe the algorithm to calculate it:

• First ,we need to specify how farther our focal plane is from the camera origin (this is called the focal distance)
• Second ,we calculate our ray direction as we normally do
• Third,we calculate our point in focus for that given pixel (point=ray.origin+ray.direction*focal_distance)
• Fourth,we calculate a random point on the lens and displace the ray origin by the coordinates of this point
• Finally ,the new ray direction is ( point-ray.origin).normalize()

Sorry for the excessive use of the word “calculate”

Here’s my results:

Thanks to lyc ,I’m now interested in fractals ,I wrote a program to render the Mandelbrot set and the Julia set ,it’s  quite an easy task ,what impress me though is that how such simple formulas (Zn+1=Zn*Zn+C where Zn+1,Zn and C are complex numbers) can generate very beautiful shapes.

The first image represents the Mandelbrot set, the second and the third ones are the Julia set with different values of C.

I’ve been experimenting  lately with the Preetham’s daylight model,i only implemented the skylight part ,at first it sounds really complicated ,a lot of formulas and numbers plus the color conversion (from xyY to XYZ to RGB) .But in the end , it is really not that complicated and it gives a good sense of realism to the scene ,even though i struggled to implement it correctly.Below are two images representing the sky at sunset and at daytime.

As you can notice , I’ve added a procedural texture (checkerboard) which is quite simple to implement.Here’s my code to generate such a texture.

Color3f getColor(HitRecord *record)
{
float s=2.0;//the size of the square
int x=(int)floor(record->pHit.x/s);
int y=(int)floor(record->pHit.y/s);
int z=(int)floor(record->pHit.z/s);
if ((x+y+z)%2==0)
return m_c1;//the white color
else
return m_c2;//black color
}

This paper “Day light sky color”  helped me a lot to implement the Preetham’s skylight model , basically it provides all the necessary data to go from xyY to RGB color space plus the basic steps to get the sky color, so it’s a good read.

To see the difference , here’s a scene (138 902 traingles) rendered with naive path tracing (1 samples/pixel)  in 15 seconds (some little details are lost due to jpg compression):

and here’s the same scene after adding explicit direct lighting:

Dragon (203 000 triangles):

Image resolution:1000*1000,number of sample for AA: 10 (random sampling),render time:38 minutes

Suzanne (4000 triangles):

Image resolution:500*500,number of sample for AA: 10 (random sampling),render time:1min30s

Bunny(16000 triangles):

Image resolution:500*500,number of sample for AA: 10 (random sampling),render time:2 minutes

the same scene but it is path traced with 1000spp (render time:2hours)

The render time is really shocking for a such a simple scene (approximately 11h35min using 1000spp).This is actually made me think seriously about acceleration structures for ray  tracing .

Next thing to implement  is Bounding Volume Hierarchies .

By the way here’s some more images rendered by my ray tracer:

But now , I had a much more serious problem , It is how to pick a random direction on the unit hemisphere centered at the normal of the intersected point.At first ,I didn’t bother at searching for a good approach ,I just used the classic method which is :

-Pick two random number between 0 and 1 (say n1 and n2)

-theta=2*PI*n1

-phi=0.5*PI*n2

And then the random direction is :

x=cos(theta)*sin(phi)

y=sin(theta)*sin(phi)

z=cos(phi)

But this method turns out to be not efficient as I thought , a “strange” shadow in the back of the sphere has appeared , take a look:

So I looked over the internet to find another method for hemispherical sampling and I end up with this one:

pick two random numbers (e1 ,e2) the spherical angles (theta and phi) are then given by :

theta=2.0*PI*e1,phi=arccos(sq rt(e2)).

The shadow thing is somehow fixed but another bug has appeared , check it out:

I know that it is less probably that someone is visiting my blog right now but if you passed by and have a solution , please let me know!

Thanks

Edit:

After some searching , I found out that my problem was that I’m not actually constructing a coordinate system such as the unit hemisphere is centered around the normal at the intersected point so the good way is to sample the hemisphere using a pdf  then creating the random direction by multiplying each component of the random direction (on the unit hemisphere) by the axis u,v,w respectively with w  set to be the normal at the intersected point (must be normalized) , u=CrossProduct(t,w)/length(CrossProduct(t,w)) , t is a vector equal to w except that the smallest absolute value component of t  (x,y or z) is set to 1 and finally v=CrossProduct(w,u).

Now the  Cornell Box looks much more better:

Thanks for reading!