RE: [Algorithms] FPS Questions

[Tom F. <to...@mu...>]

There's a fade in as well as a fade out. Motion blur is "forwards" as well
as backwards. The exception to this is bright lights that "burn" the retina
(they don't really) - they don't have a fade-in, just a fade-out (as the
retina cells recover). But they're special cases - most stuff fades in as
well as out, so a straight summing of n rendered frames, each with
timestamps distributed over period is the right thing to do.

Tom Forsyth - Muckyfoot bloke.
Whizzing and pasting and pooting through the day.

> -----Original Message-----
> From: Jim Offerman [mailto:j.o...@in...]
> Sent: 02 August 2000 08:18
> To: gda...@li...
> Subject: Re: [Algorithms] FPS Questions
> 
> 
> > you can use a accumulation buffer (or t buffer) to do proper motion
> blur...
> > there's nothing that prevents you from using it to do the 
> averaging of the
> > multiple frames for each displayed frame, and that's 
> probibly the best way
> > to go about it.
> 
> To simulate motion blur, rather than average a few frames, 
> shouldn't we have
> a function like:
> 
> P(1) = R(1) - C * P(0)
> 
> Where P(0) and P(1) are the color values of some pixel in the 
> (accumulation)
> buffer at t = 0 and t = 1 and R(1) is the color value for the 
> same pixel,
> resulting from the rendering of a frame at t = 1. C is a 
> constant, which
> controls the decay of light / the amount of motion blur.
> 
> Note that P(2) = R(2) - C * P(1) = R(2) - C * (R(1) - C * 
> P(0)) and so forth
> for P(3) to P(n).
> 
> Probably (and I am guessing here), C shouldn't be a constant 
> at all, but
> rather dependent on the velocity (both linear and radial) of 
> the viewer, as
> I think that motion blur increases with velocity.
> 
> Jim Offerman
> 
> Innovade
> - designing the designer
> 
> 
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
>