> I think motion blur is a matter of speed of objects relative to the camera.

	Yeap.

> And if only the camera moves, one
> could say the objects are moving relative to the camera too.

	But when the objects _and_ the camera are both moving in space
following complex paths (and e.g. another look_at path for the camera),
then you start having trouble since it becomes much more difficult to
transform object moves into camera space.

> So I think it's
> better to say that motion blur is both object property and camera property.
> The faster objects move compared to the shutter speed of the camera, the
> "longer" the blurs will be.

	But that's still the effect of a camera-only property. Objects
do not even know about camera shutter speed. It's similar to focal blur
(replace 'faster' by 'farest' and you get the idea).

	Okay. The point here is that I'd like to discuss about the SDL
for motion blur (implementation can be completely different). IMHO in
the camera definition there should be a parameter like shutter_speed
given in s^{-1} for instance. The objects would eventually have a flag
like 'motion_blur on/off' to tell the camera they are moving ot not
(in case, for any reason, one wants to disable this on per-object basis
while still defining the object move using the clock value). The motion
blur effect would require POV to calculate an animation of at least two
frames (or maybe 3) to calculate (backward and) forward moves. The amount
of accuracy in the motion blur of the objects could be controlled by a
set of parameters similar to those used in focal blur. A moving camera
would be just like any moving object.
	[I don't remember how MegaPOV was defining the object moves, but
I guess it was using the clock value to duplicate objects in the scene
along their path, for a single frame. So basically that was preventing to
calculate whole animations with motion blur in the standard way (I'm
probably wrong here, should re-read the docs).]

	- NC

Post a reply to this message