SPPM renderer (CPU-only)

Discussion related to the implementation of new features & algorithms to the Core Engine.

Moderators: jromang, tomb, zcott, coordinators

Re: SPPM renderer (CPU-only)

binarycortex wrote:
Guibou, I don't suppose you would like to take a look at EXPM now, since it exhibits the same behavior and is already biased.

yes please look also at velvet material behaviour, it seams to generate increasing lightened splotches with sppm and exphotonmap.
thanks

patro

Posts: 1798
Joined: Fri Feb 29, 2008 9:06 pm
Location: mount Etna

Re: SPPM renderer (CPU-only)

I was doing some tests with the luxball, this is with a matte base and a glass2 shell:

Glossy instead of matte doesn't exhibit this, it only seems to happen when glass2 and matte are in contact.
-Jason

J the Ninja

Posts: 2212
Joined: Wed May 19, 2010 9:54 pm
Location: Portland, USA

Re: SPPM renderer (CPU-only)

J the Ninja wrote:I was doing some tests with the luxball, this is with a matte base and a glass2 shell:

It is just me or it is a general problem of glass2 not related sppm (i.e. like carpaint)

This is a rendering with MTL/BiDir of a Glass cube:

and this with Glass2:

What kind of material is Glass2 supposed to be ? The second rendering doesn't look right.

Posts: 4800
Joined: Sat Apr 19, 2008 6:04 pm
Location: Italy

Re: SPPM renderer (CPU-only)

Hi,

Glass and glass2 basically use the same code to compute the shading, however the dta handling in the material makes extensive use of volumes with glass2, so you have to carefully check that everything is fine there.
I'll try to have a look at it if nobody finds what's wrong before.

Jeanphi
jeanphi

Posts: 6580
Joined: Mon Jan 14, 2008 7:21 am

Re: SPPM renderer (CPU-only)

J, can you reproduce the problem in a simple scene (i.e. cube over a plane) ? I'm unable to reproduce the problem (sppm+glass2+volume):

It seems to work fine in this case.

Posts: 4800
Joined: Sat Apr 19, 2008 6:04 pm
Location: Italy

Re: SPPM renderer (CPU-only)

The trouble seems to start when you fully enclose the scene, and the glass intersects the floor (left cube is glass2, right is glass):

Intersecting:

~1.5mm above the floor:

Scene files here, for the intersecting version: http://dl.dropbox.com/u/1706676/glass.zip

Technically, this could be considered a modeling mistake in the luxball scene, as the objects aren't supposed to actually intersect.
Last edited by J the Ninja on Sun Mar 13, 2011 4:07 pm, edited 1 time in total.
-Jason

J the Ninja

Posts: 2212
Joined: Wed May 19, 2010 9:54 pm
Location: Portland, USA

Re: SPPM renderer (CPU-only)

Hi,

If the floor has an external medium defined, it might reset the medium inside the glass cube in the intersecting case, thus leading to a wrong shading computation when the ray exits the glass cube (I'm not sure about it but it might explain the difference between glass and glass2).

Jeanphi
jeanphi

Posts: 6580
Joined: Mon Jan 14, 2008 7:21 am

Re: SPPM renderer (CPU-only)

jeanphi wrote:Hi,

If the floor has an external medium defined, it might reset the medium inside the glass cube in the intersecting case, thus leading to a wrong shading computation when the ray exits the glass cube (I'm not sure about it but it might explain the difference between glass and glass2).

Jeanphi

The lamp position might have something to do with it too, it is off to the right side of the image, and not angled exactly between the two:

(The floor does have an external medium though, same one as the lamp and the two cubes)
-Jason

J the Ninja

Posts: 2212
Joined: Wed May 19, 2010 9:54 pm
Location: Portland, USA

Re: SPPM renderer (CPU-only)

Here is my humble test of SPPM render of glass2 (glass, water, bubbles, icecubes), matte (backdrop) and glossy (straw).

Integrator parameters used:
Code: Select all
SurfaceIntegrator "sppm"   "integer maxeyedepth" [16]   "integer maxphotondepth" [16]   "integer photonperpass" [250000]   "float startradius" [0.300000000000000]   "float alpha" [0.8]   "string lookupaccel" ["hybridhashgrid"]   "bool includeenvironment" ["true"]

The render went to #6500 passes (= 22 hours rendering)

For comparison the same scene rendered with BiDir+Metropolis (ignore slightly different glass color - it was changed accidentally):

And ExPhotonMap:

My observations:

Pros:
1) SPPM generally converges much faster than BiDir+Metropolis (even with the same picture resolution) and slightly faster than ExphotonMap
2) SPPM produces much sharper picture (in all renders antialiasing settings were identical). For me sharper picture looks much better and gives impression of better realism.
3) The glass (including red fluid) looks clearer. This was the first scene element that got cleared just after a few minutes of render. Neither BiDir nor ExPhotonMap achieved such a crystality even after days of render. This was the most astonishing surprise of SPPM for me.

Cons:
4) SPPM has some essential problem with glossy material. The straw is glossy with roughnesses of 0.000010 and it can't get rendered after 22 hours. It's too dark and still has some white fireflies.
5) Matte backdrop lacks smoothness. Even with "set smooth" applied in Blender you can easily see the seams.
6) Generally lighting is harder in SPPM. I tried to compensate it by tonemapping, but without much success. The contrast is very high. (It can be slightly dimmed by increasing gamma from nominal 2.2 to ~3 and lowering postscale in Reinhard from 1.0 to 0.9).

In general I like the overal sharpness of the image. It is really impressive. I couldn't obtain such an effect in any other algorithm. Also rendering speed is awesome for some materials (apart from glossy, which hopefully will be fixed in future releases?).

Regards
Rafal
rafal

Posts: 53
Joined: Thu Aug 05, 2010 8:28 am

Re: SPPM renderer (CPU-only)

rafal wrote: SurfaceIntegrator "sppm"
"integer maxeyedepth" [16]
"integer maxphotondepth" [16]
"integer photonperpass" [250000]
"float alpha" [0.8]
"string lookupaccel" ["hybridhashgrid"]
"bool includeenvironment" ["true"]

Your startradius is very very low. This will make it very very difficult to converge a scene. Yes the caustics will converge pretty fast because of the small search radius, but that makes it very hard to converge everything else, especially the matte walls. Here is how it works (as I understand it). SPPM starts with the startradius and is reduced every pass by the alpha amount. So if you start with a start radius of 2.0 and you have an alpha of 0.8 the second pass will be 1.6, the third pass will be 1.28 and so on. You could start with the defaults, startradius 2.0 and alpha 0.7, and the caustics would still converge because of the alpha setting.

rafal wrote:4) SPPM has some essential problem with glossy material. The straw is glossy with roughnesses of 0.000010 and it can't get rendered after 22 hours. It's too dark and still has some white fireflies.

SPPM is still in the very early stages, so this should improve. However there are some things you can do. First, the roughness you have set is nearly a mirror and highly unrealistic for a straw. 0.01 is probably still to shiny for a straw. Keeping the photon count low will help with you perform more passes. And with glossy materials you need more eye passes for them to converge.

rafal wrote:6) Generally lighting is harder in SPPM. I tried to compensate it by tonemapping, but without much success. The contrast is very high. (It can be slightly dimmed by increasing gamma from nominal 2.2 to ~3 and lowering postscale in Reinhard from 1.0 to 0.9).

I haven't had any issues with the lighting, I haven't changed anything in my scenes and they look nearly identical to mlt+bidir.
Competition Coordinator.
Current Competition: Math is Beautiful / Abstract Wallpaper

Member of the first official jeanphi-fan club

binarycortex

Posts: 1503
Joined: Fri Feb 22, 2008 10:44 pm

PreviousNext