Quasirandom sampler
Re: Quasirandom sampler
Keep in mind that there is a difference in samples/sec mostly because the scene is too simple. In any no trivial scene, the difference should be negligible. You can use one of the scenes at https://github.com/LuxCoreRender/LuxCoreTestScenes to check.
- alpistinho
- Developer
- Posts: 198
- Joined: Thu Jul 05, 2018 11:38 pm
- Location: Rio de Janeiro
Re: Quasirandom sampler
I am on Linux, sorry. I will try to compile the debug version now, but it takes ages on my computer
I've noticed that when I used Bidir, even in this simple scene.Dade wrote: ↑Wed Mar 06, 2019 4:06 pm Keep in mind that there is a difference in samples/sec mostly because the scene is too simple. In any no trivial scene, the difference should be negligible. You can use one of the scenes at https://github.com/LuxCoreRender/LuxCoreTestScenes to check.
Do you think it is worth to investigate it a bit more and fix it for PhotonGI? Sobol is pretty state-of-the-art as far as I could research and I don't know if it is likely that this sequence is capable of surpassing it. The implementation is much simpler, though
Re: Quasirandom sampler
I doubt it can provide any significative improvement over Sobol too.alpistinho wrote: ↑Wed Mar 06, 2019 9:25 pm Do you think it is worth to investigate it a bit more and fix it for PhotonGI? Sobol is pretty state-of-the-art as far as I could research and I don't know if it is likely that this sequence is capable of surpassing it.
There is one aspect of Random/Sobol samplers you could look into: the adaptive aspect. For instance, one part to improve is that they are currently skipping samples instead of just progressing slower on some (already converged) pixel. The current advantage is that there is one single global "pass" instead of a "pass" for each pixel. It saves some ram but it is pretty bad for sampling.
- alpistinho
- Developer
- Posts: 198
- Joined: Thu Jul 05, 2018 11:38 pm
- Location: Rio de Janeiro
Re: Quasirandom sampler
Seems nice, I will have a look into it.Dade wrote: ↑Wed Mar 06, 2019 11:09 pm There is one aspect of Random/Sobol samplers you could look into: the adaptive aspect. For instance, one part to improve is that they are currently skipping samples instead of just progressing slower on some (already converged) pixel. The current advantage is that there is one single global "pass" instead of a "pass" for each pixel. It saves some ram but it is pretty bad for sampling.
Maybe something like that: https://jo.dreggn.org/home/2009_stopping.pdf
Shamelessly taken from: https://github.com/oktomus/gsoc-2018/bl ... -report.md
Re: Quasirandom sampler
Unfortunately, it is the kind of stuff would never work on a GPU.alpistinho wrote: ↑Wed Mar 06, 2019 11:46 pm Maybe something like that: https://jo.dreggn.org/home/2009_stopping.pdf
Shamelessly taken from: https://github.com/oktomus/gsoc-2018/bl ... -report.md
- alpistinho
- Developer
- Posts: 198
- Joined: Thu Jul 05, 2018 11:38 pm
- Location: Rio de Janeiro
Re: Quasirandom sampler
Hum, they claim the opposite "Due to this simplicity it can be easily integrated in GPU based ray tracing systems", but I have very little knowledge about GPU computation.
Any other suggestions?
Re: Quasirandom sampler
I wasn't suggesting to look for a totally new solution, I was suggesting to improve the current one
- alpistinho
- Developer
- Posts: 198
- Joined: Thu Jul 05, 2018 11:38 pm
- Location: Rio de Janeiro
Re: Quasirandom sampler
Why is it bad for sampling that some pixels are skipped?Dade wrote: ↑Wed Mar 06, 2019 11:09 pm There is one aspect of Random/Sobol samplers you could look into: the adaptive aspect. For instance, one part to improve is that they are currently skipping samples instead of just progressing slower on some (already converged) pixel. The current advantage is that there is one single global "pass" instead of a "pass" for each pixel. It saves some ram but it is pretty bad for sampling.
I am currently trying to integrate the error metric mentioned on https://jo.dreggn.org/home/2009_stopping.pdf to improve the issue lacilaci was reporting a while ago here: viewtopic.php?f=4&t=712&p=7328#p7328
A drawback for this metric is that it is not measured in the same dimension pixel is, but pixel/sqrt(pixel), making more difficult to compare the performance between the two methods.
From that I hope to build up something that could improve the current solution.
Re: Quasirandom sampler
Do you have already a good idea how to write the implementation in OpenCL for GPUs ?alpistinho wrote: ↑Sun Mar 10, 2019 10:37 pm From that I hope to build up something that could improve the current solution.
- alpistinho
- Developer
- Posts: 198
- Joined: Thu Jul 05, 2018 11:38 pm
- Location: Rio de Janeiro
Re: Quasirandom sampler
Not yet, I will install the AMDGPU-pro in my Linux box to do that.
Is the structure significantly different from the C++ code? I have never coded for GPU but I understand that the architecture is very different, so I know I need to be careful not to tank the performance.
Right now I am experimenting with some statistic based solution that doesn't require changing anything outside the FilmConvTest::Test() function.