Just some facts:
- 600x600 pixels
- 17,250 seconds / 4.79 hours rendertime
- 2,534,120,000 rays ( 2.534 billion )
- 200 samples per pixel
- maximum path length is 25
- objects (from left to right): glossy mirror, diffuse sculpture, diffuse box, glossy mirroring totem (and a surrounding diffuse box)

And now, have a look:

Farewell, dear Photons ...

It was smeary, hard to optimize on huge scenes, but I gotta say, it was straightforward and somewhat easy to implement. But I won't use it until further notice. It's about photon-mapping.

The "bads" owned the "goods". One great disadvantage of photon-mapping is the big amount of memory. I'm a little poor guy. Trainee. Not employee. And trainees don't have the money for big server clusters. They are happy when they are able to buy some gasoline for their 10l/100km-car.

The image following this phrase was the state-of-the-art before I removed the photon-mapping:

Not bad. But this rendering took 50 layers (re-rendering the same scene with different initial photon-parameters)

So, farewell, dear Photons! Good bye. Maybe we meet again. Maybe.

More Objects. Regarding the quantity

I actually had a kd-tree in the tracer. But it did not increase the performance. Nope and negative, the opposite was the case. I started a little discussion about it on ompf.org; at that time I thought it has something to do with the parametric nature of the spheres (In contrast to meshed objects which are often build of thousands or even millions of triangles). You can find it here. Take some minutes to read if you want to. If you have not read it: The tree-creation was buggy. I just forgot to initialize the bounding boxes of the nodes ... blame on me.

It was pure accident that I found the bug and holy nature, it took days of disencouraging debugging sessions... I was somewhat close to rewriting the whole kd-stuff.

But now, it's working fine. Have a look at a first image:

This one took 20 minutes including soft shadows and multiple reflections

And after that rendering, I wanted to know the truth. I made some sessions with (in relation to sooner images) very high object-count:

From left to right: A)1k or 2k spheres including soft reflections; B)I think it was 6k spheres; C)25x25x25=15625 spheres and finally D)the same one but with indirect lighting, making the inner spheres more lit

"Hybrid, you removed the photon maps, now *spelling it long and dismissive* show me some indirectly lit scenes"

Huh, whattup? You've seen one in the previous chapter! It was the 25x25x25 spheres picture on the right; but maybe the following images will calm you down:

These images show indirect lighting. But they are unrealistic due to the wrong lighting math implemented yet

"Okay, they calmed me a bit. But in the meantime, sorry, spheres suck." *hybrid thinking and being jiggered* man, he seems to be very aggressive today. got to do something.

More objects. Regarding the types.

I had the feeling that the time had come to implement some more types of primitive. I couldn't just render spheres again and again. And a cornell-box (http://www.graphics.cornell.edu/online/box/), which is practical for testing purposes, does not consist of spheres only. That motivated me to implement triangles at first right after the spheres. Via ompf.org I found a sweet repository of models on the mesh compendium. I decided to use the 100k-triangles dragon. I rendered some test-images with increasing realism. Please click on the image to get a comparison between direct lighting only and indirect lighting (global illumination):

Please click on the image to get some more detailed information

Thanks for reading so far and have a look at the last chapter (no more reading, promised!).

Current state-of-the-art

1024x1024, took 35k seconds (9,76 hours), 11 shadow rays, 100 samples (maximum path length is 5)

Test scenes in the spirit of the cornell-box

It has been a while since the last update in the glass log. Where should I begin? (thinking about it while having a look at the image gallery...;)

At first
I skipped the glass-raytracer version 2. The last feature: Some monte-carlo-raytracing to get sweet soft shadows. No attempt for real global illumnation, but I got the basics. This is the last edition 2-rendering:

Doing it object-oriented
Then I have begun to write the third edition: glass++. From now on glass++ is my pretty-tracer family, object oriented to the bones. The glass-tracer (without "++") in contrast will be focused on realtime-raytracing. So, to sum it up: "glass++" will produce nice and realistic images, "glass" will produce images fast with triangles being the only type of primitive.

Introducing Mr.Jensen
At the moment the most important glass++-feature is photon-mapping (an efficient technique which helps to approximate the rendering equation, http://graphics.ucsd.edu/~henrik/papers/ewr7/egwr96.pdf). Take a look at this first try:

Getting on GI
To further improve the quality I let the photons shot out by the lights bounce of the surfaces they hit, let them be reflected and refracted:

Memory. A lot of memory.
Applying higher detail of lighting meant increase the number of photons meant increased memory-usage (a lot of, believe me): A photon is saved with a position (12Bytes), a direction (12Bytes) and a color (16Bytes). Shoot millions of them and store them into a kd-tree for faster tracing and hope you got memory. A lot of it (I know I've already said that).
And if you don't have enough of that rare resource called memory? Why not render the same scene not only one time but again and again and finally combine them, each time with different photon-directions?

from image to image the number of layers is increased from 1 to totally 417 layers

Current glass++-state-of-the-art (50layers)

I had a try on global illumination. Pics gonna be better....