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

[Scott Wilson]

Sounds like an interesting idea. What about cases where there is a plane
moving perpendicular to the camera, and there is a massive lighting,
texturing, or reflectance change from the previous frame to the current
frame? From how I understand your proposal, this case will fail, since you
would be copying the values from the previous frame. Also, what about cases
where you are rendering on a farm? It isn't guaranteed that the frame you
are rendering will have access to the previous frame.
On Jun 19, 2014 7:54 AM, "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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-cycles/attachments/20140619/853e395e/attachment.htm