[Bf-cycles] Potentially incredible fast rendering idea :-D

[Brecht Van Lommel]

There are various papers making use of this kind of temporal
information, for example:

* Reprojection Cache (various papers)
* Temporally Coherent Irradiance Caching
* Statistical Acceleration for Animated Global Illumination

For final renders, I haven't seen a reliable algorithm. It's similar
to other recent GI filtering techniques I think, you can get a
significant speedup but there are also persistent errors. These
methods work with heuristics to determine if you can interpolate or
reuse some values. They get it wrong for some % of pixels and you
can't efficiently detect when it happens because there's so many
things influencing the color of a pixel.

For preview renders it could be useful, though I would first try
spatial instead of temporal filtering because it's much easier to fit
in. For final renders, I would not advise to do it.

Brecht.

On Thu, Jun 19, 2014 at 4:54 PM, x3108 at chello.at <x3108 at chello.at> wrote:
> Guys, i have an absolutely great idea :-D (i hope so!!!!) increasing render speed up to 10000% for animations i think :-D
>
> 1. You take the z values of every pixel in the buffer
> 2. You compare them with the geometry and see if the previous frame intersects the same geometry ray.
> 3. You can now HEAVILY pre estimate the sample color only after way fewer samples, basically CLAMPING the result BASED on the previous data!!!
> 4. Also you have the motion vectors, and if the threshold fails, ONLY THEN you render full sample that pixel!
>
> This would NOT be an interpolation, of pixels, but only a smart way of NOT rendering the same noise again and again making use of temporal information. This would speed up especially slow GI scenes a LOT with way less noise and NO new BiDir hokus-pokus calculations!
> Also the clamping would not cut any dynamic range/highlights, because it is driven by the pre estimated buffer data, which is full range.
>
> Imagine this like a temporal denoiser, BUT driven with the information of ray intersection/geometry and motion vectors up to a certain threshold of lets say 32 Samples. And if the threshold is not reached, full render sampling is invoked for that pixel.
> I think it needs to be part of the cycles code for ray calculations, its not a post operation i think.
>
> Brecht... maybe before you leave ? ;-)
>
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> http://lists.blender.org/mailman/listinfo/bf-cycles
>