[Bf-committers] Cycles: Optimizing render speed?

[Jaros Milan]

Hi,

I tried some implementation:
https://developer.blender.org/D2662

You can see there is a problem with tiles. I changed scalar sample (in task, tile, filter, ...) to vector of samples and it works ( I did not create a patch yet ) - each pixel has own number of samples.

There is many method for stopping criterias I used most simple based on changes of value in render-buffer.

There is other option which could help - using progressive rendering - check OpenMPDevice ( the loop over samples could be outer loop of the loop over pixels ). In this case the nonprogressive rendering takes same rendering time like progressive rendering.

The next feature which could help is not using tilemanager but samplemanager ( each thread computes one sample ).

Best regards
Milan

Dne 19. 11. 2018 19:01 napsal uživatel Brecht Van Lommel <brechtvanlommel at gmail.com>:
We would like to add adaptive sampling, it's just a matter of someone
writing a good implementation which is not trivial.

On Thu, Nov 15, 2018 at 7:15 AM Kurt Weiss <fundev at kwnet.at> wrote:

> Sampling, Path Tracing:
> Samples: e.g. 70.
>
> Cycles renders all 70 Samples, regardless of whether the tile is
> changing or not.
> Often that's not neccessary in the main parts of the picture...
>
> Maybe it's a idea to add a possibility to define a threshold by
> comparing new an old images of the tile. (e.g. max. change of RGB value
> in pixels)
>
> Especially in areas where only background is present, the engine could
> abort sampling after one or two samples. This would save a lot of time
> at unattended rendering.
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>
_______________________________________________
Bf-committers mailing list
Bf-committers at blender.org
https://lists.blender.org/mailman/listinfo/bf-committers