<p dir="ltr">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.</p>
<div class="gmail_quote">On Jun 19, 2014 7:54 AM, "<a href="mailto:x3108@chello.at">x3108@chello.at</a>" <<a href="mailto:x3108@chello.at">x3108@chello.at</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Guys, i have an absolutely great idea :-D (i hope so!!!!) increasing render speed up to 10000% for animations i think :-D<br>
<br>
1. You take the z values of every pixel in the buffer<br>
2. You compare them with the geometry and see if the previous frame intersects the same geometry ray.<br>
3. You can now HEAVILY pre estimate the sample color only after way fewer samples, basically CLAMPING the result BASED on the previous data!!!<br>
4. Also you have the motion vectors, and if the threshold fails, ONLY THEN you render full sample that pixel!<br>
<br>
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!<br>
Also the clamping would not cut any dynamic range/highlights, because it is driven by the pre estimated buffer data, which is full range.<br>
<br>
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.<br>
I think it needs to be part of the cycles code for ray calculations, its not a post operation i think.<br>
<br>
Brecht... maybe before you leave ? ;-)<br>
<br>_______________________________________________<br>
Bf-cycles mailing list<br>
<a href="mailto:Bf-cycles@blender.org">Bf-cycles@blender.org</a><br>
<a href="http://lists.blender.org/mailman/listinfo/bf-cycles" target="_blank">http://lists.blender.org/mailman/listinfo/bf-cycles</a><br>
<br></blockquote></div>