I thought that I would devulge the information I know about this subject as well as why I sincerly doubt that Impulse will include this feature in any of the upcoming upgrades. I will also give some hints as to how to simulate motion blur (actually it really isn't simulating, it is the real thing) using Imagine (or any other rendering program for that matter) and an image processing package.
The human eye does not see motion as most com puter renderers see it. The human eye does not see motion as a continuous set of instantaneous pictures. The human eye sees motion through persistence of vision. Our eyes are constantly taking visual data from our surroundings, the data our eyes feed to our brains is not sampled.
This is a difficult effect to achieve on the computer. There are algorithms that allow a computer to achieve real motion blur, but these tend to be really slow if your using a large number of polygons. They get even more complex, and even slower, if you start moving objects along spline paths (if you're interested, and have access to a good library, check out Computer Graphics, Volume 17, Number 3, July 1993, Temporal Anti-Aliasing in Computer Generated Animation). Much faster ways of approximating motion blur exist. These approximations hide some of the temporal-aliasing (aliasing over time) while the real motion blur method completely eliminates it.
Some programs use a method much like the way Imagine casts multiple rays while ray-tracing to eliminate regular (spacial) aliasing. This method is called distributed ray-tracing. While Imagine (3.0) can cast many rays through the area of a pixel to approximate the pixel's average color value, motion blur casts many rays over time through the area of a pixel to determine that pixel's average color value (note that both methods can be combined without necessarily increasing the rays cast. Realistically the number of rays should be increased, perhaps by a factor of two, because when combined the two methods tend to have a negative impact on each other's approximations).
Distributed ray-tracing is fairly easy to implement _when ray-tracing_. It becomes infinitely more difficult when using a scanline renderer (so difficult, in fact that I won't even discuss it).
As pointed out above, motion blur is hellishly hard to implement in scanlining (because scanlining does hidden surface removal on a line, actually a plane, that passes through a row of pixels). I'm sure that this method can, and has, been implemented, but by a company much larger and richer than Impulse (like Pixar).
Problems exist in the distributed ray-tracing method as well. For this method to work it must have information about every objects position over time (or at least the frame to be traced and the two adjacent frames). Imagine's global effects are given access to much information about a _single frame_, and they can be used to control the renderer (as in depth of field), but I'm guessing that they can't access anything but the information about the current frame. So, Impulse would have to over-haul Imagine to implement motion blur. If you look at versions 2.0, 2.9, 3.0 and soon 3.1, you'll notice that almost all the new features are add-ons and really aren't integrated into imagine as a whole. It's great that Impulse planned far enough ahead to allow Imagine to be so modular that these new features are just added-on. Unfortunately, I really don't think Imagine's modularity goes far enough to allow an easy addition of motion blur. So until Impulse completely rebuilds Imagine (something, I for one, think is due) I sincerely doubt that we will see motion blur in Imagine. Of course I sincerely hope that I am absolutely wrong in the above and that Imagine isn't designed the way I think it is, then perhaps we might see motion blur in one of the next few updates.
Motion blur is quite easy to approximate on your own. However, it does have costs, namely, increased rendering time (everyone knew that one was coming), and an increase in storage space for the individual frames before they are compiled into an animation. There is a slight increase in the space the animation will take too.
Simply put to acheive motion blur render more frames than you actually need. So, depending on the amount and speed of the motion in an animation, you render perhaps 3 times as many frames as you want to be in your animation. So if you have a 10 second animation (300 or 240 frames) render 900 or 720 frames. Then use an image processing package to average 3 frames into one. So for frame 1 in the animation you will average frames 1,2 and 3 (DTA does this on the PC, the command for compiling the above example into an FLC file would be <dta pic*.tga /a3>)
The real trick here is to figure out how much motion blur you need, if you need it at all. Generally, I find that if an object moves across the whole screen in one frame I will want about 30 sub-frames per frame (big hint: avoid the above case). So if it moves across half the screen I will want about 15 sub-frames per frame. It's also nice to always use an odd number of sub-frames. That way you know the objects exact location at any given frame (in the middle sub-frame).
Another problem arises when working on looping animations. The first and the last frame will not look correct. What you have to do is tack on some extra frames before the first and after the last frames. The number you add depends on the number of sub-frames you are using. If N is the number of sub-frames you are using you have to add (N/2)-1 frames to each end of the animation. You then have to set up in the action editor so that the first (N/2)-1 frames look like the last (N/2)-1 frames and vice-versa.
Sometimes you have a scene where motion blur is only needed for a few frames or to one degree or another. This is where scene planning comes into play. Personally I haven't had enough practice in doing this to tell anyone how to achieve this. I have had some success at this, I just haven't yet realised a good method of approaching the problem. A good work around is to plan your camera angles so that you cut from one degree of motion blur to another when the camera changes views. If you have no choice but to have one consistent camera angle then start drawing time-lines, make lots of copies of the whole project (one for each degree of blur), and think hard about what your going to do before commiting yourself to the final render. Of course if you have a Pentium 100 and a couple gigabytes of hard drive space you may be able to use brute force and just do everything at the maximum needed degree of blur (not recommended, as you'll save yourself more time by setting up everything the hard (or is that the easy) way, especially if this is a long animation).
If you have more interests in motion blur try Computer Graphics: Principles and Practice, Fundamentals of 3D Computer Graphics, the comp.graphics, comp.graphics.algorithms, newsgroups, or contact me.
Last Update: July 13, 1995