SPPM renderer (CPU-only)

[Dade]

Yes it's just in the exporter. What happens is after a while, the passes go so fast that CPU usage looks like this:

As last resort, you can just edit by hand the .lxs file change the value.

[binarycortex]

Yes it's just in the exporter. What happens is after a while, the passes go so fast that CPU usage looks like this:

As last resort, you can just edit by hand the .lxs file change the value.

Jtheninja verified that there is not maximum in lb25. I just changed lb24 and raised the max from 10 million to 1 billion. I hope that's enough for your supercomputer A-man.

EDIT: It was changed to 1 billion, not 1 trillion. Also, in order to keep the unbiased nature of SPPM intact, alpha has been limited to 0.01 and 0.99 for min/max. Dade, should these be more flexible? Something like 0.0001 to 0.9999 for the range?

[A-man]

I realized on my way to school today that I could simply change this value in the exporter script, which I did, and it works perfectly Is that what you did binarycortex?

[binarycortex]

I realized on my way to school today that I could simply change this value in the exporter script, which I did, and it works perfectly Is that what you did binarycortex?

Yes, I changed the maximum in the exporter and committed the changes.

[guibou]

Ok, the side test should (definitely, I hope) be fixed

Attached a small test image. The object in the middle have only one side, so we can see backface and frontface. the background plane is in fact two plane, with normal facing front and backward. There is two lamp, one near the camera, which is blue, and one behind the background plane, which is red. The hitpoints stored on the background plane are correctly gathering the two lamps (because the plane is mattetranslucent). Grazing angle of the object are lit too, which was not the case with previous commit.

The only stuff that annoy me is the white line near the object middle.

[patro]

Ok, the side test should (definitely, I hope) be fixed

Attached a small test image. The object in the middle have only one side, so we can see backface and frontface. the background plane is in fact two plane, with normal facing front and backward. There is two lamp, one near the camera, which is blue, and one behind the background plane, which is red. The hitpoints stored on the background plane are correctly gathering the two lamps (because the plane is mattetranslucent). Grazing angle of the object are lit too, which was not the case with previous commit.

The only stuff that annoy me is the white line near the object middle.

great

[Dade]

Uhuhuhuh: http://graphics.ucsd.edu/~toshiya/amcmcppm.pdf

[Thammuz]

Uhuhuhuh: http://graphics.ucsd.edu/~toshiya/amcmcppm.pdf

Read it yesterday and it looks really promising! Although the "our method does not resolve flux variations due to BRDFs" part (Fig 10) is a bit worrying, it still looks better than with the "old" sppm.

[J the Ninja]

Are there plans for reducing SPPM's RAM useage any futher? It's still very high, and pretty much impossible to render things at high-resolution (2 megapixel or more) on my box (8GB of RAM). 1080p/2k animation frames and most 300dpi print renders would be out of the question with less than 12GB of RAM or so, the way things stand. These are resolutions bidir handles without difficulty on 6-8GB.

[jeanphi]

Hi,

Yes, very interesting paper, and parts of it can even be applied to standard Metropolis sampling.

Jeanphi