<html><body><pre>Agreed, the samples would have to work with depth.<br>I
actually just thougth about motion blur <br>because it's the part of
production which seems to me to be currently most heavy part <br>when
rendering animations. <br>And the idea to make it on the fly came from the
fact I couldn't imagine<br> how all samples could get stored to the
memory. Until now I didn't know about deep compositing, <br>now I read some
articles, so thanks for educating me a bit
;)<br>regards<br>Vilem<br><br><br><br><br><br><br>>I think the solution to
the antialiasing problem is deep compositing. I
>think that would be the better solution, as it seems like you would end up
>doing something similar.
>
>To resolve depth (and transparency) you'd probably end up writing to a
deep
>compositing like representation, so might as well go all the way. Vector
>blur would also use some information that's only available after rendering
>is done to fill holes.</pre><blockquote>Hello, I got an idea recently -
<br>motion blur inside of cycles is quite heavy on performance, while the
vector blur compositing node suffers aliasing problems - <br>is it possible to
actually do vector blur at the time of writing the sample into the
image?<br>This way, a fake but well antialiased and potentially fast motion
blur could be achieved?<br>regards<br>Vilem N.<br></blockquote></body></html>