Sparsed render pass #49225

New Issue

Ilia · 2016-09-01T18:02:08+02:00

Ilia commented

2016-09-01 18:02:08 +02:00

I still can't use OpenCL by some magic reason https://developer.blender.org/T48880 but I need cycles to work faster. I have done little improvement ( bpatch.diff - it can be applied at least at 96dd1943af ) but now it is more proof of concept - works only with cpu render and not in batch mode (some code placed into BlenderSession::do_write_update_render_result because it have code retrieving render result for tile)
The main idea is to skip pixels which not changed since last pass more than some value (currently it about 1% from sum of both last and current values). But each N pass (currently 8) render as usual (this amnesty-like step may be not needed, but I'm in doubt).

I still can't use OpenCL by some magic reason https://developer.blender.org/T48880 but I need cycles to work faster. I have done little improvement ( [bpatch.diff](https://archive.blender.org/developer/F349799/bpatch.diff) - it can be applied at least at 96dd1943afc4f08e4befb44602a3c621a446c678 ) but now it is more proof of concept - works only with cpu render and not in batch mode (some code placed into BlenderSession::do_write_update_render_result because it have code retrieving render result for tile) The main idea is to skip pixels which not changed since last pass more than some value (currently it about 1% from sum of both last and current values). But each N pass (currently 8) render as usual (this amnesty-like step may be not needed, but I'm in doubt).

Ilia commented

2016-09-01 18:02:08 +02:00

Changed status to: 'Open'

Ilia commented

2016-09-01 18:02:08 +02:00

Added subscriber: @inferrna

Aaron Carlisle commented

2016-09-02 18:14:40 +02:00

Added subscribers: @Sergey, @brecht

Sergey Sharybin commented

2016-09-02 18:22:40 +02:00

Changed status from 'Open' to: 'Archived'

Sergey Sharybin closed this issue

2016-09-02 18:22:40 +02:00

Sergey Sharybin self-assigned this 2016-09-02 18:22:40 +02:00

Sergey Sharybin commented

2016-09-02 18:22:40 +02:00

There was more sophisticated approach tested by Lukas in D808.

And now when there's a good progress with denoiser it means we can do smarter decisions where we can denoise and where we need to throw more samples.

It's good to see interest in such features, but current approach is this particular patch isn't really a proper one.

There was more sophisticated approach tested by Lukas in [D808](https://archive.blender.org/developer/D808). And now when there's a good progress with denoiser it means we can do smarter decisions where we can denoise and where we need to throw more samples. It's good to see interest in such features, but current approach is this particular patch isn't really a proper one.

Ilia commented

2016-09-16 18:40:18 +02:00

bpatch.diff - new version of the patch - now with flexible options in interface
- render with same total sampleswidthheight (calculated by subtract skipped pixels) as in patched result (330 samples)
- render using same time as with patched version (about 40 minutes on my pc, 360 samples)
- patched render, maximum 500 samples, ~40 minutes on my pc

current problems:

it works bad with alpha channel even in cases where alpha is flat zero when render is unpatched.
it still need visualization pass, so it doesn't working in batch mode and with progressive refine enabled.

And now when there's a good progress with denoiser it means we can do smarter decisions where we can denoise and where we need to throw more samples.

is it already in mainline or in some separate branch? Currently my result looks little smoother even for a same time renders.

[bpatch.diff](https://archive.blender.org/developer/F361255/bpatch.diff) - new version of the patch - now with flexible options in interface ![willys.orig.png](https://archive.blender.org/developer/F361257/willys.orig.png) - render with same total samples*width*height (calculated by subtract skipped pixels) as in patched result (330 samples) ![willys.orig.l.png](https://archive.blender.org/developer/F361259/willys.orig.l.png) - render using same time as with patched version (about 40 minutes on my pc, 360 samples) ![willys.sp.no_alpha.png](https://archive.blender.org/developer/F361262/willys.sp.no_alpha.png) - patched render, maximum 500 samples, ~40 minutes on my pc current problems: 1. it works bad with alpha channel even in cases where alpha is flat zero when render is unpatched. 2. it still need visualization pass, so it doesn't working in batch mode and with progressive refine enabled. > And now when there's a good progress with denoiser it means we can do smarter decisions where we can denoise and where we need to throw more samples. is it already in mainline or in some separate branch? Currently my result looks little smoother even for a same time renders.

Brecht Van Lommel commented

2016-09-18 02:57:32 +02:00

The denoiser is in the soc-2016-cycles_denoising branch , there is no code for adaptive sampling based on it currently.

To make adaptive sampling robust is a very hard problem, and we would be unlikely to accept an intermediate solution that gives only marginal improvement and doesn't work together with the denoiser.

The denoiser is in the [soc-2016-cycles_denoising branch ](https://developer.blender.org/diffusion/B/history/soc-2016-cycles_denoising/), there is no code for adaptive sampling based on it currently. To make adaptive sampling robust is a very hard problem, and we would be unlikely to accept an intermediate solution that gives only marginal improvement and doesn't work together with the denoiser.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Sparsed render pass #49225