"Tek" <tek### [at] evilsuperbraincom> wrote:
> Darren New <dne### [at] sanrrcom> wrote:
> >
> > Couldn't you have the original being 110 frames long, then, blended down to
> > 100 frames?
>
> The motion blur is meant to be the movement that occured whilst the camera
> shutter was open for that frame, so it needs to uses images from periods of
> time in-between frames, not overlapping with other ones. So the first frame
> needs multiple samples of the motion that occured in the first 1/30th of a
> second, the second needs the next 1/30th of a second. I chose to take 10
> samples of the movement over the course of a frame, hence I need to render
> 10 times more frames.

I generally use 10-frame 'batches' as well--seems to be a good compromise
between motion-blur quality and rendering time (creating all those static
images.)

Lately, I've been experimenting with a subtle alteration of how those initial
frames are generated, to try and get more of a 'motion-picture camera' look to
the blur: Since a real camera usually has what's called a 180-degree shutter
(where any film frame sees only 'half' the blurred action--1/60 sec. in your
example, though I use 1/48-- then the shutter blocks the other half while the
film is being transported), I've duplicated that by altering POV's clock value
(plus other stuff). Here's the code I use:

#declare SF = 10; // the number of animation frames to render for each
// averaged batch.
#declare I = frame_number;
#declare D = I*(1/SF); // If the averaged batch size is 10, this counts up in
// 10th's of a frame_number; at frame 10, D = 1; at frame 20, D = 2, etc.
#declare jumper = ceil(D)*SF*clock_delta - SF*clock_delta;
#declare CK = jumper + clock_delta*frame_number; // the new CLOCK (substitute
// it everywhere clock is used in scene). BTW, clock_delta*frame_number is
// probably just clock.

And in my INI file, Initial_Clock is set to 0, and Final_Clock will always need
to be 1/2 of whatever it would normally be.

So every 10 frames, the value of CK jumps ahead, which causes all the
clock-based equations to skip the next 10 frames worth of action. No useless
'black' frames are generated, and the resulting frames can be averaged as usual.

But does it 'look' more realistic? Hmm, probably a matter of taste.

Ken

Post a reply to this message