Thanks @Mikhail Matrosov (ktdfly) for taking a look, and you're right, a difference can prob be seen with the attached file only when stepping through the code, not enough samples go through this code path to make a visible difference I imagine.

A couple follow-up questions for you @Mikhail Matrosov (ktdfly) and @Brecht Van Lommel (brecht):

• If you look at the code a little higher, there's a call to triangle_vertices_and_normals(), which does not take time into account (like shader_setup_from_ray() does for example with a call to motion_triangle_shader_setup()). I'm assuming the cases where that's a problem are very rare to be worth it, what do you think? You would need a significant non-uniform scaling animation or direct vertex deformation I guess?
• on the admin side, once a diff is accepted, who does the landing/commit?

In D13639#363520, @Olivier Maury (omaury) wrote:

A couple follow-up questions for you @Mikhail Matrosov (ktdfly) and @Brecht Van Lommel (brecht):

• If you look at the code a little higher, there's a call to triangle_vertices_and_normals(), which does not take time into account (like shader_setup_from_ray() does for example with a call to motion_triangle_shader_setup()). I'm assuming the cases where that's a problem are very rare to be worth it, what do you think? You would need a significant non-uniform scaling animation or direct vertex deformation I guess?

I think it's actually important to take motion blur into account. Significant vertex deformation is not that rare. A patch to fix that as well would be great.

• on the admin side, once a diff is accepted, who does the landing/commit?

I do it.