next up previous contents
Next: Results Up: Methods Previous: Rendering

Animation

The original L-system models the growing plant by showing the interpretation of each step of the string growing. It is obvious that these models are discrete both in time and space. This presents a problem in animation. Instead of branching suddenly, all the branches of natural plants grow continuously in time. The existing method [&make_named_href('', "node22.html#Prus90","[Prus90]"), Page 135,] is to add space and time parameters to the symbols in the L-system string. Though it's a complete resolution to a smooth animation, much more complexity is brought into the system. We have the danger of losing the beauty of the L-systems' simplicity. And as we have mentioned, to reproduce a specific plant's growing in detail is not the goal of our project.

By this observation, we build the animation based on the discrete L-system. Though gaps can be seen during the plant growing, we see clearly how the underlying L-system's strings grow.

When it comes to animation, the key to success is timing. To show a fluid animation, the delay between each frame must be exactly the same. Sometimes it is difficult to keep the frame rate, especially due to the multitasking nature of modern operating systems. Suddenly some task comes up from nowhere and grabs all the system resources, causing the user to notice a small glitch in the animation sequence. If we built our animation as usual by delaying some specific period of time and then returning control to the system, the system would return to the user function at some time larger than the original delay time, sometimes quite unpredictable.

We used a special method to protect the animation from losing timing. This can be done by obtaining global time in the user function and comparing it with the accumulated delay time. By subtracting the already elapsed time from the time the program is going to sleep, the new method makes sure the program doesn't sleep too long. If the delay for some reason is already too long, the program will panic and do whatever it can to catch up without any delay at all between the consecutive frames.

The other problem faced by all windows systems is flickering. Suppose we have ten balls on the screen to bounce around. Normally we have to clear the old frame and draw ten balls separately on the screen to complete a new frame. But the problem is we cannot predict exactly when the system will draw ten balls and sometimes only nine balls are drawn before the next frame shows up. This will cause an annoying flicker.

The solution of this problem, called ``double buffering'', is used in almost every game program. We first draw on a virtual screen in the memory, and after everything is complete, the virtual screen is simply pasted to the physical screen. The operation of pasting the data from the memory to the physical screen is quite fast in Java and produces very smooth animation.

The main animation flow shows a three-dimensional plant growing, and after it stops growing, it starts turning around under the light source.


next up previous contents
Next: Results Up: Methods Previous: Rendering

Tong Lin (tlin2@cs.umbc.edu)