13
$\begingroup$

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
(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
(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?

Improve this question
$\endgroup$

2 Answers 2

Reset to default
7
$\begingroup$

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.

Improve this answer
$\endgroup$
3
  • $\begingroup$ 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. $\endgroup$
    – imallett
    Oct 14, 2015 at 19:41
  • $\begingroup$ @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. $\endgroup$
    – Nathan Reed
    Oct 14, 2015 at 20:46
  • $\begingroup$ [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? $\endgroup$
    – imallett
    Oct 14, 2015 at 21:01
3
$\begingroup$

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 by Gribel et al on motion blur in rasterisation may help.

Improve this answer
$\endgroup$
1
  • $\begingroup$ 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. $\endgroup$
    – imallett
    Oct 14, 2015 at 19:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.