SPPM renderer (CPU-only)

[SATtva]

I changed two default behavior in SPPM:

- direct lighting is now ON by default (Any reason to switch it off is a bug and should be reported so we can fix it)
- PPM proba is now ON by default (I'm planning of removing the old heuristic soon, so please, give feedbacks)

Seems to be a typo in the commit comment:

- use direct lighting is not true

You've meant "is now true", right?

And yes, it's a huge pile of commits!

[guibou]

I changed two default behavior in SPPM:

- direct lighting is now ON by default (Any reason to switch it off is a bug and should be reported so we can fix it)
- PPM proba is now ON by default (I'm planning of removing the old heuristic soon, so please, give feedbacks)

Seems to be a typo in the commit comment:

- use direct lighting is not true

You've meant "is now true", right?

Yes... sorry.

The day spell checker will also check grammar and read my mind will be a great day

And yes, it's a huge pile of commits!

I'm a big fan* of atomic commits. Especially it helps a lot for others to track and understand changes and also it may help for bisecting bugs. Usually cleaning and splitting commits take me more time that doing the actual coding


[*] (is this right in English, or did I just qualified myself as a big *wind producer*

[Pilchard123]

I'm a big fan* of atomic commits. Especially it helps a lot for others to track and understand changes and also it may help for bisecting bugs. Usually cleaning and splitting commits take me more time that doing the actual coding


[*] (is this right in English, or did I just qualified myself as a big *wind producer*

Yup, it is correct.

[SATtva]

A couple of issues here. These are not regressions as they seem to exist in revision 615410aec0a1 too.

1. Trying to load a SPPM film (with Load FLM option in Lux GUI) leads to segmentation fault in liblux. But resuming rendering from the saved film works fine.

2. Periodically saved images look like they include eye paths only:

SPPM periodic LDR output

On the contrary, manually saving an image from the GUI (Export to Image) makes it correct:

SPPM manual LDR output

[guibou]

1. Trying to load a SPPM film (with Load FLM option in Lux GUI) leads to segmentation fault in liblux. But resuming rendering from the saved film works fine.

Resuming/loading of FLM is NOT supported with SPPM. The same goes for MLT sampler or network rendering.

2. Periodically saved images look like they include eye paths only:

auto-save.jpg

On the contrary, manually saving an image from the GUI (Export to Image) makes it correct:

manual-save.jpg

Weird... I don't think it is an issue in SPPM, but perhaps in core lux, because SPPM uses two buffers for storing eye pass or photon pass. Both seems mixed in manual save, but not in periodically save.

[Rom1]

You have to select "random" as your sampler with direct light sampling, or else it will crash. No clue why, but that's what happens.

The default settings in sppm from guibou will include to have "random" as sampler instead of metropolis, which is the default settings

[SATtva]

1. Trying to load a SPPM film (with Load FLM option in Lux GUI) leads to segmentation fault in liblux. But resuming rendering from the saved film works fine.

Resuming/loading of FLM is NOT supported with SPPM. The same goes for MLT sampler or network rendering.

Well, technically FLM resuming and network rendering are more or less working (although i can see the problem with radius reduction messed up), but that's not the point. SPPM still has an ability to write film to disk, so why simply loading it into the GUI (not even to resume, but just to adjust tonemapping or output a LDR) causes a crash?

[B.Y.O.B.]

Well, technically FLM resuming and network rendering are more or less working (although i can see the problem with radius reduction messed up)

Maybe the latest used radius could be saved in the FLM file?

[guibou]

Well, technically FLM resuming and network rendering are more or less working (although i can see the problem with radius reduction messed up)

Maybe the latest used radius could be saved in the FLM file?

There is many issues in fact.

a) The radius should be stored in the FLM, but we can solve this issue pretty easilly (in fact, using PPM proba version, we only needs to store one float in the FLM, but this is not currently possible)
b) the pass number should be stored in the FLM (same issue as a)
c) We must ensure that the render is not stoped during a pass, or only store the result of the previous passes in the FLM

[Chawl]

Here's another quick test. Still there seems to be issues with secondary glossy reflections.

Check the reflection of the sun from the glossy door to the glossy floor. No matter how long you render, this does not clean up.

It seems that code tries to do something right but fail

Tx.

SPPM, Direct Light

SPPM, Direct Light, Store Glossy

SPPM, Store Glossy

SPPM only

MLT