Page MenuHome

Sparsed render pass
Closed, ArchivedPublic

Description

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 (

- 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).

Details

Type
Patch

Event Timeline

Sergey Sharybin (sergey) closed this task as Archived.Sep 2 2016, 6:22 PM
Sergey Sharybin (sergey) claimed this task.

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.

- new version of the patch - now with flexible options in interface
- render with same total samples*width*height (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:

  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.

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.