[hdesbois]

Actually, it's a good idea, since I doubt you could otherwise get some high quality motion blur. In the present state, Maxwell does motion blur by interpolating between frames in a linear way, if I'm not mistaken. Some cases of motion blur just can't be solved that way : they need computing intermediate positions at fractions of frames along animation paths, spline, etc. Even a simple spinning object requires some animation data within the app to be done right. It's not just a matter of how many subframes you use, but rather a matter of accuracy of every single subframe. So, the renderer must be able to access some animation info.
But then, I can't imagine how Maxwell could do that without becoming application specific or developping a full blown animation system with keyframing, motion modifiers, bone system, etc. Neither of these seems a realistic option to me.
Animated camera could be a good start, then I'd say possibilty to keyframe position and rotation of individual objects along curved paths. Let say I add this on my wish list vor V2 (with "infinite" subframe motion blur, the number of subframes increasing with sampling level, as with Fprime).
HD

[Chris_TC]

Some cases of motion blur just can't be solved that way : they need computing intermediate positions at fractions of frames along animation paths, spline, etc. Even a simple spinning object requires some animation data within the app to be done right.

Very nice point. The helicopter rendering they show in the white paper got posted on these forums at some point. I remember the rotor blade ends showing incorrect motion blur - instead of a round interpolation it was just a linear blur.
Which pretty much explains why they cropped off this part for the white paper