motion blur with curve-based deformation...

(L) [2007/07/10] [Lynx] [motion blur with curve-based deformation...] Wayback!

Motion blur has bugged me for ages...especially with deformed objects.
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:
[IMG #1 Image]

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...

[IMG #1]:

(L) [2007/07/10] [Lynx] [motion blur with curve-based deformation...] Wayback!

Motion blur has bugged me for ages...especially with deformed objects.

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:

[IMG #1 ]

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...

[IMG #1]:

(L) [2007/07/11] [fpsunflower] [motion blur with curve-based deformation...] Wayback!

I'm curious if there's any real visual difference between your quadratic interpolation vs. two linear segments (same number of control points). The only problem I see is that at t=0.5 you won't pass through the center control points with a bezier (which may or may not be an issue depending on where you sampled from in your animation timeline).

Most production rendering tends to use a single sample of deformation (so a single linear segment - two points). While this isn't very nice looking in some extreme cases, its fine for 99% of the cases. The memory overhead of storing an extra copy of the verts (and normals usually) would be pretty big I think.

(L) [2007/07/11] [Lynx] [motion blur with curve-based deformation...] Wayback!

>> fpsunflower wrote:I'm curious if there's any real visual difference between your quadratic interpolation vs. two linear segments (same number of control points).
Can't provide that right now, maybe i'll try to cook something on my next flash of weird experiments.
Currently i'm working on finishing some other experiment...or at least, getting it working in some way.
>> fpsunflower wrote:The only problem I see is that at t=0.5 you won't pass through the center control points with a bezier (which may or may not be an issue depending on where you sampled from in your animation timeline).
Uhm not sure what you mean, maybe i wasn't clear enough: One of the reason i chose bezier is because you can fit the curve through 3 given points easily. Let me show with a litlle picture:
[IMG #1 Image]
The red points you take from 3 time steps provided by the animation software of your choice. The green point gets calculated so that the beziér goes through all three points. You'll also see the problem that the control points are a pretty pessimistic bound of the actual curve.
>> fpsunflower wrote:The memory overhead of storing an extra copy of the verts (and normals usually) would be pretty big I think.

Yes it's not exactly memory friendly, but then again memory is cheaper then ever, and often the amount of deformed geometry is only a fraction of the scene (i hope...).

About the pixar paper, do you mean this one?
[LINK http://www.seanet.com/~myandper/abstract/rt06.htm]
At first glance i didn't find much about motion blur, only a short paragraph...and what the heck is a "Kay Kajiya tree"?

[IMG #1]:

(L) [2007/07/12] [fpsunflower] [motion blur with curve-based deformation...] Wayback!

>> Lynx wrote:The red points you take from 3 time steps provided by the animation software of your choice. The green point gets calculated so that the beziér goes through all three points. You'll also see the problem that the control points are a pretty pessimistic bound of the actual curve.

Oh I see ... that's good then [SMILEY :)] 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 [SMILEY :(]

>> Lynx wrote:At first glance i didn't find much about motion blur, only a short paragraph...and what the heck is a "Kay Kajiya tree"?

Yes - not many details. I think that means a BVH (it applies to BIH too). You store a bbox for t=0 _and_ t=1 per node. At intersection time you lerp the bbox to the right time. All that sounds super SIMD friendly (even with a single ray).

No idea how you would optimally build such a tree though.

(L) [2007/07/12] [Phantom] [motion blur with curve-based deformation...] Wayback!

Isn't it rather complex to calculate the control point so that the bezier goes through the three red points? If you use a Catmul-Rom spline instead, you get this property for free. See here: [LINK http://www.mvps.org/directx/articles/catmull/]

Theoretically, you need more than three points, but the extra points are only used to calculate the tangents at the start and end points.

I used this once to move a camera along a path in a mobile phone game. [SMILEY Smile]
_________________
--------------------------------------------------------------

Whatever

(L) [2010/09/28] [playmesumch00ns] [motion blur with curve-based deformation...] Wayback!

>> Lynx wrote:Yes it's not exactly memory friendly, but then again memory is cheaper then ever, and often the amount of deformed geometry is only a fraction of the scene (i hope...).

Scene complexity will always increase faster than the amount of available RAM [SMILEY :)]
>> Lynx wrote:About the pixar paper, do you mean this one?
[LINK http://www.seanet.com/~myandper/abstract/rt06.htm]
At first glance i didn't find much about motion blur, only a short paragraph...and what the heck is a "Kay Kajiya tree"?
Kay-Kajiya tree is indeed a BVH.

motion blur with curve-based deformation... back