Light sampling

[J the Ninja]

Quick question about light strategies I don't quite get: how is allpowerimp different from powerimp and all? As I understand it, "all" starts a path from all lamps, and powerimp chooses a lamp by its power and importance. How exactly do you combine that? Do all lamps start at least one and the brighter/more important ones start several?

[J the Ninja]

Btw, I've committed luxblend support for it here: http://src.luxrender.net/luxblend25/rev/eca0c3fc6525

I actually only meant to commit the contrast tonemapper fix but forgot this was in my repo too, but I guess i'll leave it since it was finished. The reason I hadn't already committed though is i'm not 100% sure about the best way to expose this. Atm, it uses the value for light strategy unless advanced options are enabled. Let me know if you think we should change it.

[jeanphi]

Just so I get this straight, for the "all" type strategies, you now construct multiple light paths, and connect them all to the eye path?

Exactly, multiple light paths for a single eye path. When we'll have neighborhood connections, this is going to rock.

Quick question about light strategies I don't quite get: how is allpowerimp different from powerimp and all? As I understand it, "all" starts a path from all lamps, and powerimp chooses a lamp by its power and importance. How exactly do you combine that? Do all lamps start at least one and the brighter/more important ones start several?

That's almost it, if you have n lights, allpowerimp will sample lights n times according to the importance. So you'll have n samples but some lights might not be sampled while others might be sampled several times.

Jeanphi

[guibou]

Just so I get this straight, for the "all" type strategies, you now construct multiple light paths, and connect them all to the eye path?

Exactly, multiple light paths for a single eye path. When we'll have neighborhood connections, this is going to rock.

Quick question about light strategies I don't quite get: how is allpowerimp different from powerimp and all? As I understand it, "all" starts a path from all lamps, and powerimp chooses a lamp by its power and importance. How exactly do you combine that? Do all lamps start at least one and the brighter/more important ones start several?

That's almost it, if you have n lights, allpowerimp will sample lights n times according to the importance. So you'll have n samples but some lights might not be sampled while others might be sampled several times.

Jeanphi

Huhu, finally it is like combinatorial path tracing !

Jeanphi, I love you

[J the Ninja]

One extra feature idea I had, is it possible to add a function to start multiple light paths from the same lamp? For example, if you set this parameter to 2 and lightpathstrategy to all, every lamp would start 2 light paths? (or if you used "one" and 3 light path samples, that chosen lamp would start 3 light paths)? Might be helpful on some scenes with difficult lighting? (kinda along the lines of SPPMs photons per pass, allows you to balance which direction the samples are coming from)

[jeanphi]

Hi,

Yes, along the lines of the shadowraycount parameter. That is not currently possible but should be quite straightforward to add.

Jeanphi

[J the Ninja]

Hi,

Yes, along the lines of the shadowraycount parameter. That is not currently possible but should be quite straightforward to add.

Jeanphi

Ah, good to hear.
Speaking of shadowraycount, is that still alive? You mentioned in the first post it might not work after these changes?


Thanks a ton, jeanphi!

[jeanphi]

Speaking of shadowraycount, is that still alive? You mentioned in the first post it might not work after these changes?

Yes it's still working, but in some cases slightly differently than before.

Jeanphi

[jeanphi]

Next step: have hybrid bidir work with all light sampling strategies and have other integrators work with light sampling strategies.

I hadn't really looked at the hybrid bidir code yet, and I just did. The current architecture will make it extremely difficult to support all light sampling schemes.
Dade, since you know the code better, could you voice an opinion about the following wild ideas:
1- use the same vertex structure for standard and hybrid bidir
2- trace eye and light paths with the GPU
3- have a possibly unbound (or really much higher in the worst case) number of paths to trace on the GPU

The rationale is the following:
1- it would allow to reuse a lot of proven code from the standard version, most notably the MIS weighting, which I think will be flawed if you don't store more data
2- why not?
3- if 2 is done you could have to trace: paths continued from previous steps (both direct lighting and eye/light paths connections going through passthrough materials), direct lighting connections for the current eye vertex, eye/light paths connections for the new vertices, with the light sampling schemes, direct lighting connections can grow quite high, and you can have several light paths in flight at once

I guess the main issue would be memory.

Jeanphi

[Dade]

The rationale is the following:
1- it would allow to reuse a lot of proven code from the standard version, most notably the MIS weighting, which I think will be flawed if you don't store more data

Mostly because I was trying to learn how it works (i.e. BiDir and MIS) on my own so I re-wrote the code from scratch. However it is quite hard to extract the correct PDFs for me (i.e. there are several details of the current infrastructure I don't know, for instance if some PDF is expressed in solid angle or area, etc.).

Indeed BiDir and Hybrid BiDir can share about all code (and they should) however it would be a lot easier to write that code for you than for me (i.e. I have no clue about all the corner cases handled by the normal BiDir code) ... if you want to write I will be more than happy

2- why not?

I don't think is a good idea:

1) the code for tracing eye/light paths on CPU is a lot simpler to write instead of having to trace a single ray of the paths at time like with hybrid path;

2) tracing eye/light paths on CPU uses a lot less ram because you don't need to save the state of the path tracing and resume. In my opinion, we have learned from hybrid path tracing that tracing a single ray at time doesn't work well (i.e. requires a lot of ram and it is slow). It is a lot better when you can send large set of rays to trace in a single hit (i.e. all shadow rays and next path vertex ray).

3) it could be slower. I have not tried but my feeling is that the cost, in term of ram and time, of sending a single ray to trace to the GPU is higher than just tracing the single ray on the CPU.

3- if 2 is done you could have to trace: paths continued from previous steps (both direct lighting and eye/light paths connections going through passthrough materials), direct lighting connections for the current eye vertex, eye/light paths connections for the new vertices, with the light sampling schemes, direct lighting connections can grow quite high, and you can have several light paths in flight at once

The idea in current hybrid BiDir is to send all the rays to trace on the GPU in one single shot. I trace the eye and light path on the CPU and then I build all the rays (i.e. direct light sampling rays, eye/light path connection rays) to trace on the GPU in just one step. I think this is the most efficient (i.e. minimize memory and time) way to work for hybrid rendering.

This scheme can be easily extended to work with multiple light paths and different direct light sampling strategies, there will be just more rays to trace (that is a very good and useful thing).

The steps done by the current hybrid BiDir code are:

1) CPU: generate eye and light path;
2) CPU: fill the RayBuffer with all rays required for direct light sampling and eye/light connection (often several hundred of rays). Store on CPU ram the potential Contribution to the Sample for each ray;
3) CPU: send the RayBuffer to the GPU;
4) GPU: trace the rays;
5) CPU: read back the RayHits;
6) CPU: for each RayHit if ray hits nothing => add the stored Contribution to the Sample;
7) CPU: for each RayHit if ray hits something => check if is a pass-through BSDF and continue to trace the ray on the CPU if required.
8) goto 1

This scheme requires less ram (i.e. requires a lot less states) and it is faster than the one used in hybrid path tracing.