A couple of questions for Nick...

[IanT]

... or anyone else who knows the answer

I've been experimenting with MLT for the past couple of days and have managed to get some code up and running quite quickly in my own renderer.

In the spirit of "open collaboration", I was wondering about how Indigo handles some aspects of MLT, specifically:

- are paths restricted to implicit, or are explicit paths (i.e. ones that don't hit a lightsource and are explicitly connected to one) used too?

- what is the strategy for choosing mutations? Does Indigo decide what mutations could be applied to the path and then randomly choose between them, or is it based on path importance or some other metric?

- If "new path" mutations are forced every so often, how often?

- Is direct lighting handled separately or does Indigo handle all lighting effects via MLT?

Would just like to say ... it was Indigo's very existence, and some of the unbelievable renders, that inspired me to look at MLT more closely. Keep up the excellent work. Indigo is easily the highest quality free renderer out there and long may it remain so.

Thanks in advance

Ian.

[OnoSendai]

are paths restricted to implicit, or are explicit paths (i.e. ones that don't hit a lightsource and are explicitly connected to one) used too?

Well this depends if we're talking backwards path tracing style or bidirectional style MLT.

what is the strategy for choosing mutations? Does Indigo decide what mutations could be applied to the path and then randomly choose between them, or is it based on path importance or some other metric?

The Mutation scheme i used is based on this paper:
http://www.iit.bme.hu/~szirmay/paper50_electronic.pdf

If "new path" mutations are forced every so often, how often?

It's user configurable as "large_mutation_prob"
the default is 0.4, ie 40% of the time.

Is direct lighting handled separately or does Indigo handle all lighting effects via MLT?

Hard to say, depends on if using bidir or not.

Would just like to say ... it was Indigo's very existence, and some of the unbelievable renders, that inspired me to look at MLT more closely. Keep up the excellent work. Indigo is easily the highest quality free renderer out there and long may it remain so.

heh, thanks

[IanT]

Thanks Nick,

I think I've already answered my first question during implementation, which is currently backwards path-tracing only, not bi-directional. I do have some bi-directional code which I'll plug in at some point in the future, but I wanted to get the basic MLT loop working correctly first.

And thanks for the link to that paper.

The question about direct lighting could be rephrased as ... are direct light paths ignored by the MLT code (e.g. paths of the form E(S*)DL ) and handled by a separate path-tracing integrator, or are they subjected to mutations and accumulated in the MLT histogram along with everything else?

From seeing Indigo renders in progress and comparing them to mine with/without special handling for direct lighting, I'd bet on the latter, but I just wanted to make sure.

Thanks again,

Ian.

[OnoSendai]

You guessed right, there is no special handling of direct lighting.

[chaff.g]

I'm also working on an MLT implementation and have some similar questions. Kelemen's mutator mutates the current sample by mutating the random numbers used to generate the sample (instead of the samples directly). So does Indigo implement this by mutating the random numbers of a single vertex of the current path or all the numbers for all the vertices of the current path? The latter seems to work better for me, but I'm wondering if you've seen better results otherwise?

[IanT]

Ah, someone else taking the plunge with MLT Not easy is it? It took me about 2 days to get the basic architecture in place to do MLT, basic mutations etc. and then another week to find-tune all the rules about when and how often to do mutations. It's definitely worth perservering with because I've not found ANYTHING yet that is as robust and fast as MLT.

Example...

http://www.trackvids.co.uk/radium/galle ... ltered.jpg

This took around 8.5 hours to render and my program's Java. The lighting is a physical sun/sky and some of the caustics on the floor would probably have taken several days to converge with plain path-tracing. Slightly quicker with bi-directional path tracing but not much I suspect.

Having read the Kelemen paper, I'm sure that he proposes a small step in the whole n-dimensional cube, which would mean a change to all the random numbers (like a tiny walk in 3D space but extended to n dimensions). In advance of Nick replying, I'm guessing this is how Indigo works.

I'm actually still getting good results (see above) with plain old multi-chain and caustic perturbations, even with a 10,000 luminosity sun in the sky, but the Kellemen stuff really intrigues me

Ian.

[chaff.g]

Cool, nice render! I'm still rendering Cornell Boxes . In my experiments, mutating all the coordinates of the hyperpoint rather than a single coordinate seems to produce a result that converges faster.

Have you tried implementing bidirectional path tracing yet? For my (simple) scene, bidirectional path tracing is much faster than MLT.

[IanT]

Yeh, I have some bi-directional code but I've not hooked it up to MLT yet. I want to get the path-tracing implementation sorted out first and then I'll go to bi-dir.

Ian.