Most renderers i know either do post-processing (which in most cases looks rather crappy) or render the image at different time steps (which is either very slow or looks crappy). Or they don't support deformed geometry blurring at all.
I had talked a bit about motion blur with fpsunflower a while ago (uhm...sunflow pre-0.5 times!), he suggested to calculate the bounding box of each primitive over the frame time and build the acceleration structure as usual, and then do time-based intersection. Because linear interpolation seemed too crappy for real motion, i wanted to use some sort of curves. Since the only kind of curves i am really familiar with are béziers, i gave them a try.
The simplest ones are quadratic béziers (as used by true-type for example), they seem reasonably fast to evaluate, reasonably compact (3 control points) and calculating a bounding box is easy because of the convex hull property, so that was my choice. Also, the first and the last control point lie on the curve ends and the remaining control point is simple to compute from the curve point at t=0.5 (i simply assume that using the relative frame time as the curve parameter "t" works well enough). If c0-c2 are the control points and p0-p2 are the points on the curve at t=0/0.5/1 then the curve is:
c0 = p0
c1 = 2*p1 - 0.5f*(p0 + p1)
c2 = p2
As bounding box of a triangle i simply use the bound of all control points of the 3 vertices. Because a bounding box is a convex hull of the points inside, this should guarantee a valid bound for the 3 curves.
Triangle intersection first has to find the three curve points of course, then the usual triangle intersection follows.
The first (and currently only) test image i got:
Unfortunately testing with yafray is rather complicated, because the blender export currently cannot get mesh points at different times yet. The above scene is tediously stitched from 3 successive frames. I'm hoping for the render API that blender is supposed to get with the google summer of code projects...
The image above uses 16 samples per pixel, time intervals are uniform and only offset quasi-random between pixels, giving this noisy effect. This trivial scene with just over 200 triangles and a directional light took 5sec to render (one thread). Smoothed surface normals are not implemented yet...
Limitations/things to improve:
- convex hull of control points is a pessimistic bound (subdivision can provide better bound though)
- possibly huge performance hit on high-poly geometry due to large spatial overlap of bounds
- single quadratic bézier curves can only form simple shapes, no "s" shape and only poor approximation to spherical arcs
Looking forward to any kind of feedback...
But from the same picture, two line segments joining the red points isn't _too_ far off from the bezier curve itself. Thats why I have a feeling the spline gives little improvement except in situation with really long and curvy blurred motion. And those pessimistic bounds seem like a big problem 