pysmooth - When are
computer-generated animations smooth ?
Pysmooth is a very simple python program written to check and proof how
a computer-generated animation is perceived as "perfectly smooth" by
the eye.
I could be wrong (please tell me !), but here is my theory about this :
Eye-remanence is a fact. It means that if the computer-generated
animation is updated below the eye-remanence time, the eye will
perceive the movement as jerky :
- If the movement is really too slow (image is updated below 24 times
per second). Then the eye clearly sees each image as single and
understands the intended animation is only a sequence of moving images.
- As the framerate increases (each single image stays less longer on
screen, framerate is 24-48 images per second), the eye begins to see a
"doubled" image, because within its remanence time, the moving object
has been updated (only) twice.
In order to solve this problem, standard movies, running at only 24
fps, shot the action in a motion-blurred way. This confuses the eye
that sees a "blurred" movement, that will help it to believe the motion
was smooth. Why ?
Yet another theory here : the eye sees a fast motion as blurred in
order to have the ability to determine the direction of the movement :
ie - some prehistoric men had this kind of ability that made them able
to avoid thrown objects, predicting their trajectory using the fact
that they no see a single object at a time, but a blurred motion that
indicates the direction of the moving object, like stones or very fast
Tyranosorus Rexes ;-)
With evolution, this "kind" of men had the ability to reproduce and
keep that gene, while the others were eaten by dinosaurs.
Back to now : If we see an blurred moving image, our brain deduces that
the object is moving. That's how the blur in movies help us to find
they are "smooth", while they are not.
But this trick is not possible on todays computers : such a motion blur
would take too much processor time to be computed accurately, so the
only way to simulate a smooth move for a computer is to draw it as
often as possible (increase the framerate), but not only as we will see
right now :
Above 48 hz, surprinsingly, the movement is still jerky (Unreal
Tournament players know it), although we are far above eye remanence
time (use pysmooth to see it).
Animation will be perceived as really smooth only if you are able to
"follow" the animated object with the eye and see it as clearly
as if it was not moving.
This is MY definition (what is yours ?) - see pysmooth again.
And how can this be reached ? Only one solution : the movement as to be
perfectly steady, in order for the animated object to be exactly at the
position the eye was waiting for it. If not, movement will not be seen
as perfectly smooth.
And how can a computer-generated animation be perfectly steady ? Only
one option : follow the screen synchronization.
Here you can tune your PC (with RefreshForce - browse the Internet) to
prove it :
pysmooth runs at 640x480, in the system default frequency used by your
PC.
If it is 60Hz (check with your monitor), then movement will be smooth
if the animation is fast enough to be perform within this 1/60 of
second, each frame showing an equally displaced object. Above this
time, image will not be moved steadily, and the eye, trying to follow a
steady movement, will detect the un-smoothness of the animation.
But this also means that if your monitor's refresh
rate is 85Hz, and if 1/85 of second is not enough to update the full
animation, then the animation will not be perceived as smooth (check it
with pysmooth and Refreshforce) !
Thus, a 70fps animation on a 85Hz display is NOT SMOOTH, while it is on
a 60Hz display !
This also means that an animation will need a lower framerate to be
perceived at perfectly smooth when the display's frequency is low.
But hey, UT players, do not immediately turn your monitor to the lowest
possible refresh rate ! There is an obvious drawback here, also visible
in pysmooth : below 75Hz, the eye is able to perceived the flickering
of the screen, mainly when there is a lot of white (and mainly with the
"corner" of the eye, the eye being more sensitive on its sides).
But it's a good idea to keep refresh rate below 85Hz to help the game
to be "in the frame".
With all there are other things to note :
Virtual screen (double buffer) : Generally, the computers and
videogame consoles use a double buffer technique (software or
hardware), meaning that the picture is not created DIRECTLY onto the
monitor/tv. In fact, the image is computed (which tamkes time) and then
"written" on a virtual screen, and, when finished, the content of this
virtual screen is copied (in a very fast way, it's just pixel to pixel
copy), to the screen, and the process go on for the next frame.
Wait for vsync : This is an option in most PC games. It
means that if the whole screen has been drawn in less than frame, then
the program will still wait for the next monitor refresh before
continuing rendering the NEXT screen. This causes time to be wasted,
but anyway, rendering a full frame before the screen has to be refresh
means that the game runs perfectly smooth, as we saw.
If this option is not set, then the computer will never stop rendering
the screen (which is done on the virtual screen as we saw before), and
then multiple images will be drawn on a single one, leading mainly to
the "vertical stairing" that can be see in this case, because the
computer has begun another rendering on the same virtual screen, but
did'nt finished in time for the nex frame : so when copied to the real
screen, the top of the frame shows the top of the N+1 frame, when the
bottom shows the bottom of the N frame.
Interlacing : Above
all this, outputting to an interlaced display is another problem (a CRT
TV at PAL 50Hz for instance).
In this case, the video board displays the image number N's odd lines
first, then displays the image number N+1's even lines, producing a 50
frame (half-image) per second animation, which is perceived as smooth,
thanks to the low remanence time.
On "normal" 100Hz CRTs, the "re-creation" of the whole image (sticking
on a same image the even and odd lines of the 2 frames), will create
combing artifacts that can be suppressed only by high-end 100Hz CRTs
(like the Sony Wega KV32FX60 in "Advanced" digital mode).
LCD users : Only low
response time (starting at 8ms and below) LCD monitors will allow to
experiment a real smooth animation. Above, screen remanence is such
that a ghosting trail follows the animated object, causing a blur that
is not interpreted by the brain as a real movement (tested with
pysmooth on a Sony SDM-P234 16/9 LCD Monitor (RT : 16ms)). Summary
and conclusion :
- Computer animation is smooth when images are displayed in a
steady
way : when FPS is above screen refresh, or said in another way, when
all the animation process is done before the screen will be updated by
the next frame.
- If you want to replace your old CRT and continue playing videogames,
buy an LCD that have the lowest possible response time, or you will see
nothing but a LOT of trails.
pysmooth - The program :
I coded in Python because Python c'est bon
and
because it's the fastest way to code something understoodable easily.
Unfortunately, the compiled version of pysmooth is not working,
crashing with a segmentation fault I was not able to correct (I you
succed, tell me !)
So in order to run pysmooth, you need Python interpreter installed, +
pygame.
I did the full install of all this in less than 2 minutes on a PC
without Python - more : this is a good excuse to install python and see
how much it is a beautiful language ! (the installer comes with IDLE,
which bring a great python "shell", where you can try command in real
time !).
This version of pysmooth has been tested on windows only, but I guess
it should work on any platform.
Unzip pysmooth.zip to a directory of your choice, and, from a
command-line, you go to this directory and type :
pysmooth_directory>\\path_to_python_executables\python.exe
pysmooth.py
That's it ! (Remember that real smoothness experience can be seen on
CRT monitors/tv only ! (test the difference, you will be suprised !)
Up and down arrows increase and decrease the framerate, while left and
right arrows control how much the object is moved each frame. Esc quits
the demo.
Feel free to tell me what you think about all this.
UPDATE !
You can download a ready-to-burn (PAL) DVD for interlaced/progressive comparison with a standard DVD player HERE.
- Useless to say, the INTERLACED part should look perfectly smooth on a
standard CRT TV, when the PROGRESSIVE version looks jerky on the same
TV set.
- On 100Hz CRTs, INTERLACED version will still be smooth if
deinterlacing algorithm is good, otherwise the 2 versions will almost
produce the same smoothness
- On (standard) LCDs/Plasmas, INTERLACED version will exhibit both
combing effects and ghosting trails (urgh !), while PROGRESSIVE one
will "only" show ghosting trails and jerkyness. But sets with
deinterlacing onboard can remove combing artifacts of INTERLACED
version and make it look like PROGRESSIVE one, leaving all other LCDs
problems on.
- But now (!) some LCDs feature 100Hz technologies, that insert a
calculated frame between real ones and so at double-the frequency of
the original signal, thus limiting trails and smoothing the animation
at the same time.
I only saw DVD versions of this technology (trying to find a shop ready to let me try pysmooth is not an easy job ;-).
For me, as the animation is smoother, it is more realistic, thus
better. For some, the "cinema" aspect (the jerkiness !) disappears and
then films look like video, throwing away the "magic". Tell me what YOU
think !
