Designing and Scripting on the Spot



Programming animation requires a patience in tryout. To get a scene that looks right needs hundreds of adjustments in color, size, speed, position, motion track, layout, timing, lighting, sound effect, etc. One change may effect another, requiring a further change. For example, changing the size of a spirit may hide something so you need another position change. Without viewing results, the effect of the change on other objects can hardly be figured out.

Using a language without a capability of dynamic design and script, you cannot see the result of the adjustment until you re-compile, re-link, and re-load the program after each change. No matter how fast computer is, a fairly large program still needs one or two minutes to go through the re-building process. You might have to spend a whole day to get one of hundreds scenes done in your animation through hundreds of rebuildings. To complete the whole animation title, a whole year might be spent.



Using languages with a capability of dynamic design and script, you may have different problems. Most problems are performance-related. Other problems may relates to the limitation in the provided built-in features.

A typical solution is to use two different languages: a static and efficient language like C/C++ to implement basic animating objects as models in larger granules; and another dynamic script language for application users to design their animation titles. The basic animation models are implemented by professionals who know every trick to improve the performance. Therefore, this two level development process may achieve higher performance than a single level process in which unskilled programmers do it from scratch.

But the basic models cannot cover every thing that application developers need. Advanced application development kits usually provide a hook to lower level programming. Therefore, a high level design language has to provide a link for users to program in the lower level language. Many high level dynamic languages lack the sufficient facility to describe the behavior of an object efficiently, which is required frequently in animation programming. Animation programmers have to resort to low level languages, and drown in the annoying building cycles. Worst of all, this approach makes programming all the harder by demanding users to be bi-lingual.

My column in the February issue described an advanced dynamic/static typing transformation approach by using the Transframe language. A class can be melted to dynamic status, providing the capability of dynamic design and script.

With a single language approach, we do not turn a two-level development process (model level and application level) into a single level. Instead, the development in multiple levels is encouraged in an integrated environment. For example, the basic 3D models is the lowest level for 3D animations. Above the basic models, people can develop various domain-specific models such as animals, human beings, buildings, transportations, etc. Animators can use these domain-specific models as clip arts and build their animation titles quickly.

Each model can be modified and customized into a new model with the full help of the language. This is usually done by subclassing: you create a dynamic subclass based on the existing model (class), and then freeze the subclass when you finish your design.

The major advantage of this single language approach is that both application developers and model implementors can get rid of the rebuilding cycle. They stay in the dynamic programming environment until their animating models are satisfactorily tested.

A second major advantage is that a model developed with the help of dynamic design and script can be frozen into a static model for performance.

The freeze/melt example I gave in my last column is an embedded system. What follows is another freeze/melt approach supported by Transframe: design by example.

To design a system model (class), you first create an object (example) of your incomplete design. Then, you make dynamic changes on the object. You re-architect the structure of the object, add, delete or change the functionality of the object, and test the response and actions of the object the same time. Finally, when you get the object behaving exactly like the one you need, you classify this object into a class by classification.

Classification is a reverse step of object instantiation. It freezes a design encapsulated in a dynamic object into a class. This method provides a useful incremental development process. During dynamic object design, no edit-compilation-test cycle is involved.

Consider an example to illustrate the benefit of this method in creation of an animation model. Suppose you want to design a new creature based on an existing animal model. You can create a dynamic object as an instance of a generic animal class or an animal class that resembles the vague creature in your mind. Then, you re-design the animal in the dynamic visual programming environment by changing shapes of each components, setting new skin texture, modifying existing reactions, adding new behaviors, etc. You may need hundreds of tryouts and changes before you get the creature you want. After each change, you can see the result of the change immediately without waiting for rebuilding. You can even use preview function for an uncertain change, or, if you find something wrong with your new settings, you can undo the change. When you get the satisfactory result, you then freeze the creature into a class, which will be used by the rest of your animation title or by other animators.

Speaking in a Native Language