RE: [Algorithms] FPS Questions

[Graham S. R. <gr...@se...>]

> Also, consider motion blur.  Without being too technically accurate about
> how cameras work, lets simplify and state that a camera is actually
> recording all the information available.  Whilst it does chop up the 'real
> stream' into (eg.) 24 fps, during each interval it is capturing the
> remaining information by allowing light into its sensor (film etc) for the
> full timeslice, resulting in motion blur.
>
> ie. motion blur actually represents all the 'missing' information in slow
> fps media.  That's why without it, computer graphics need a much
> higher fps to get a similar feeling of smoothness.
> --
> gl

Yes, that's right. There is information in a real camera frame beyond just
24 fps of geometry positions that helps the eye extrapolate more detail.
Such subtlety. Perhaps we can do with 60-100fps, but with at *least* 10
samples into an accumulation or T-buffer to get a nice, smooth (unbanded)
motion blur effect. If we're actually redrawing entire scenes to get those
10 motion-blur samples (e.g., objects *and* the camera are moving), then
we're once again up to sort of needing 500-1000 fps drawing rate. At least
we can avoid the issue of monitors not being able to do huge, huge refresh
rates. A bit easier to achieve if only a few small objects are moving, and
the camera is not moving.

Graham Rhodes