SPPM renderer (CPU-only)

[binarycortex]

Ok, I did some difficult light path testing. I used my pool scene which has been modified so that the sunlight hits the copper sphere before going anywhere. So in these shots the sunlight hits the sphere, then gets refracted through the water, then (in the scene with suzanne) of the monkey and onto the wall of the pool.

[tomb]

Ok, I did some difficult light path testing. I used my pool scene which has been modified so that the sunlight hits the copper sphere before going anywhere. So in these shots the sunlight hits the sphere, then gets refracted through the water, then (in the scene with suzanne) of the monkey and onto the wall of the pool.

under_water.jpg

under_water_monkey.jpg

[Dade]

under_water_monkey.jpg

This is pretty awesome

[Dade]

5) Matte backdrop lacks smoothness. Even with "set smooth" applied in Blender you can easily see the seams.

This is definitively a bug, I will look for it.

[binarycortex]

Here is MLT+BIDIR at 2 hours for comparison. The caustics look great, but even at a depth of 64 the world outside the water looks very dark, as well as under water for that matter.

EDIT: The statistics say 6 hours, but that is only how long the luxrender window was open. Halttime was set for 2 hours. Is this a bug? Because, i think it should only track actual render time, also if its paused i think it should stop counting.

EDIT #2: Incase anyone is wondering Suzanne is platinum (Pt.nk) with a roughness of 0.001.

[binarycortex]

It appears that memory usage went up again by a few hundred megs of ram with the last round of updates 2 days ago. I was able to claw some of that back by using the now functional kdtree lookupaccel. It also seems to be a tad faster than hybridhashgrid as well. ^_^

[Dade]

It appears that memory usage went up again by a few hundred megs of ram with the last round of updates 2 days ago. I was able to claw some of that back by using the now functional kdtree lookupaccel. It also seems to be a tad faster than hybridhashgrid as well. ^_^

The double buffer scheme used to render the eye pass "n+1" while rendering the photon pass "n" requires to effectively store 2 set of hit points. This indeed increase a bit the ram usage but it should be about nothing compared the older versions: in my tests the older version was using something like ~6GB to render a 1000x1000 image, the single buffer version was using about 1.5GB and the double buffer something like 2GB.

[binarycortex]

It appears that memory usage went up again by a few hundred megs of ram with the last round of updates 2 days ago. I was able to claw some of that back by using the now functional kdtree lookupaccel. It also seems to be a tad faster than hybridhashgrid as well. ^_^

The double buffer scheme used to render the eye pass "n+1" while rendering the photon pass "n" requires to effectively store 2 set of hit points. This indeed increase a bit the ram usage but it should be about nothing compared the older versions: in my tests the older version was using something like ~6GB to render a 1000x1000 image, the single buffer version was using about 1.5GB and the double buffer something like 2GB.

Yes it's still down quite a bit. I just wasn't sure why the increase. But again, using kdtree for lookupaccel brings it down a bit, near to the single buffer size.

[patro]

Yes it's still down quite a bit. I just wasn't sure why the increase. But again, using kdtree for lookupaccel brings it down a bit, near to the single buffer size.

yeah that's right....
Dade which one is better to use at time, kdtree or hybridhashgrid
you says that hybridhashgrid is near by 2 time faster than hashgrid

grazie

[Dade]

Yes it's still down quite a bit. I just wasn't sure why the increase. But again, using kdtree for lookupaccel brings it down a bit, near to the single buffer size.

yeah that's right....
Dade which one is better to use at time, kdtree or hybridhashgrid
you says that hybridhashgrid is near by 2 time faster than hashgrid

It is always faster in my tests and it can not slower than kdtree (i.e. it is an hashtable with a lot of small kd-trees), the only case I can think where kd-tree is faster is when you are short in ram and the system start to swap, was that your case Binarycortex