<p>Lerping the ray positions/directions between keyframes should be equivalent to lerping the inverse matrices between keyframes and transforming by the lerped matrix. Trouble is, if the keyframes have different rotations, that lerped matrix will in general be something "weird", with shearing, nonuniform scale, etc.</p>

<p>I wouldn't be surprised if some of your intersection and shading routines don't work properly in such a distorted coordinate system, unless you've specifically tested and hardened them against such cases. (For example, taking the dot product of two unit vectors doesn't give the same answer in a sheared coordinate system as in an orthonormal one.)</p>

<p>This is just a guess, but it might work better if you choose an interpolation method where the translation, rotation, and scale (if applicable) are lerped separately (using quaternions for the rotation part) and re-combined.</p>

CC BY-SA 3.0
2015-10-14T19:41:56.740Z
Are you sure lerping the forward transformed object is the same as lerping the backward transformed ray? For example, I can renormalize the ray after the lerp (and scale the hit distance accordingly). This doesn't change the result.
geometrian
CC BY-SA 3.0
2015-10-14T20:46:39.937Z
@imallett Lerping the ray should be equivalent to lerping the inverse matrices, but not necessarily to lerping the forward matrices or lerping the object (as inversion isn't a linear operation). And I don't think renormalizing the ray after the lerp fixes things entirely - you can still be in a sheared, nonuniformly-scaled coordinate system that can screw up the math in your intersection routines and suchlike.
Nathan Reed
CC BY-SA 3.0
2015-10-14T21:01:21.383Z
[See edit; better picture] At least, I do think renormalizing should rule out problems with the intersection--but that is what I thought; lerping the ray isn't lerping the object. In your answer you suggested lerping [inverse?] TRS and then recombining. Is this the way production renderers do it?
geometrian
CC BY-SA 3.0
2015-10-14T17:48:09.203Z
2015-10-14T17:48:09.203Z
Nathan Reed
<p>I don't think you'll get terribly far with, AFAICS, a single linear approximation to a rather non-linear interpolation, but perhaps this <a href="http://fileadmin.cs.lth.se/graphics/research/papers/2013/highorder/" rel="nofollow">paper / presentation</a> by Gribel et al on motion blur in rasterisation may help.</p>

CC BY-SA 3.0
2015-10-14T19:45:49.290Z
I break it down into a linear approximation, which is quite typical. One can handle more complex transforms with multiple such steps.¶ My problem is not in making the transform nonlinear, but in making the linear approximation to it correct.
geometrian
CC BY-SA 3.0
2015-10-14T17:56:16.040Z
2015-10-14T17:56:16.040Z
Simon F
<p>My raytracer supports a wide variety of objects.  To intersect them, I use the standard technique of transforming rays into object-space.  This works fantastically until I add motion blur.</p>

<p>I model motion blur as a sequence of transforms (to simplify discussion, let's say exactly two) instead of one.  My approach is to take the inverse transform of the ray at both keyframes and lerp the positions/directions.</p>

<p>This seems to work fine for translations, but it breaks down for rotations.  E.g. here are two triangles undergoing 30 and 90 degree rotations:</p>

<p><a href="https://i.sstatic.net/DRHf1.png" rel="noreferrer"><img src="https://i.sstatic.net/DRHf1.png" alt="rotation1"></a><br/>
<sup>(4 samples, MN reconstruction, the red samples came from near the two keyframes)</sup></p>

<p>At the corners, I would expect the lerped samples to lie on a straight line between the the two vertices.  Instead, they bulge outward.  This is wrong.  In more interesting scenes with more interesting transformations, it causes a variety of failure modes.  E.g. here's a propeller undergoing a 45 rotation:</p>

<p><a href="https://i.sstatic.net/8kcIi.png" rel="noreferrer"><img src="https://i.sstatic.net/8kcIi.png" alt="rotation 2"></a><br/>
<sup>(100 samples, normals visualized)</sup></p>

<p>Some problems are due to the BVH breaking (it assumes the extrema of objects lie at keyframes), but even a brute force render is incorrect.</p>

<p>I can fix all this by doing forward transforms only (transform object, not the ray), but this only works for objects where that is possible (only triangles, really).</p>

<hr>

<p><strong>How can I make my raytracer produce linear approximations to transformation (especially rotation) by transforming rays, not objects?</strong></p>

<raytracing><transformations><motion>
Ray Transformation to Object Space for Motion Blur
geometrian
# Ray Transformation to Object Space for Motion Blur

(Asked by: username_0 on 2015-10-14)

My raytracer supports a wide variety of objects. To intersect them, I use the standard technique of transforming rays into object-space. This works fantastically until I add motion blur.

I model motion blur as a sequence of transforms (to simplify discussion, let's say exactly two) instead of one. My approach is to take the inverse transform of the ray at both keyframes and lerp the positions/directions.

This seems to work fine for translations, but it breaks down for rotations. E.g. here are two triangles undergoing 30 and 90 degree rotations:

[![rotation1](https://i.sstatic.net/DRHf1.png)](https://i.sstatic.net/DRHf1.png)  
(4 samples, MN reconstruction, the red samples came from near the two keyframes)

At the corners, I would expect the lerped samples to lie on a straight line between the the two vertices. Instead, they bulge outward. This is wrong. In more interesting scenes with more interesting transformations, it causes a variety of failure modes. E.g. here's a propeller undergoing a 45 rotation:

[![rotation 2](https://i.sstatic.net/8kcIi.png)](https://i.sstatic.net/8kcIi.png)  
(100 samples, normals visualized)

Some problems are due to the BVH breaking (it assumes the extrema of objects lie at keyframes), but even a brute force render is incorrect.

I can fix all this by doing forward transforms only (transform object, not the ray), but this only works for objects where that is possible (only triangles, really).

---

**How can I make my raytracer produce linear approximations to transformation (especially rotation) by transforming rays, not objects?**

**Tags:** raytracing, transformations, motion


---

## 2 answers

### Answer by username_1 on 2015-10-14. Score: 7 | Accepted answer

Lerping the ray positions/directions between keyframes should be equivalent to lerping the inverse matrices between keyframes and transforming by the lerped matrix. Trouble is, if the keyframes have different rotations, that lerped matrix will in general be something "weird", with shearing, nonuniform scale, etc.

I wouldn't be surprised if some of your intersection and shading routines don't work properly in such a distorted coordinate system, unless you've specifically tested and hardened them against such cases. (For example, taking the dot product of two unit vectors doesn't give the same answer in a sheared coordinate system as in an orthonormal one.)

This is just a guess, but it might work better if you choose an interpolation method where the translation, rotation, and scale (if applicable) are lerped separately (using quaternions for the rotation part) and re-combined.

> **Comments:**
> **username_0**: Are you sure lerping the forward transformed object is the same as lerping the backward transformed ray? For example, I can renormalize the ray after the lerp (and scale the hit distance accordingly). This doesn't change the result.  
> **username_1**: @imallett Lerping the ray should be equivalent to lerping the inverse matrices, but not necessarily to lerping the forward matrices or lerping the object (as inversion isn't a linear operation). And I don't think renormalizing the ray after the lerp fixes things entirely - you can still be in a sheared, nonuniformly-scaled coordinate system that can screw up the math in your intersection routines and suchlike.  
> **username_0**: [See edit; better picture] At least, I do think renormalizing should rule out problems with the intersection--but that is what I thought; lerping the ray isn't lerping the object. In your answer you suggested lerping [inverse?] TRS and then recombining. Is this the way production renderers do it?  

---

### Answer by username_2 on 2015-10-14. Score: 3

I don't think you'll get terribly far with, AFAICS, a single linear approximation to a rather non-linear interpolation, but perhaps this [paper / presentation](http://fileadmin.cs.lth.se/graphics/research/papers/2013/highorder/) by Gribel et al on motion blur in rasterisation may help.

> **Comments:**
> **username_0**: I break it down into a linear approximation, which is quite typical. One can handle more complex transforms with multiple such steps.¶ My problem is not in making the transform nonlinear, but in making the linear approximation to it correct.  

---

