I multiplied the speed by 10. now I get 15mill samples within half an hour.

Also some bugfixes

7 hours, 150mill samples:

Progressive Photon Mapping 2.

(After about 15 million samples and 7 hours)


The code for the progressive photon mapping is finally written. For the same number of samples, the algorithm does look better than path tracing, but the sample speed is far worse. While I am not quite doing it in the same way as the paper describes, my method has the same, if not better big-O time per sample. A proof has yet to be done for that. Right off the bat I can think of a couple of optimizations: the first two nodes on the photon can be ignored and not added to the map, and the direct lighting can be computed explicitly. I say this because it seems as though this algorithm is much slower for direct lighting, where graininess and complex lighting is not a problem, and fails completely for antialiasing, which is only really important under direct lighting.

4000 samples:

17000 samples:

1million samples:

DOF!!! (and new matts)

path traced

note: checker pattern+ improved glossy+glossy refraction

The dragon

FINALY AVAILABLE!

http://people.brandeis.edu/~mirman/

yay- 4000 spp

I fixed boolean opperations, and I have a webpage.

http://people.brandeis.edu/~mirman/

anybody who can, can yall try to open tlrcam's jar and see if you can read the source?

at 900 spp.

i ran some tests and found that path tracing runs at about 8000 mps on this image, and mlt/this runs at 7000 mps. not as big a difference over the long run as i though. it means i can stop trying to optimize it as much.

Problem: both mlt, this, and path tracing start out rendering at about 30000 mps, then go on to an average of 20000 mps for about 5 miniutes, (the warm up ends after about 1 miniute), and then finally jumps down to below 10000 mps. I have no idea why it is doing this.
ideas: Java's garbage collector not acting up...
mt random number generator something
memory leak.
no clue.

Any ideas?