System for animating program operation and displaying time-based relationships

I claim:

1. A method for controlling behavior of model embodiment as a group of interactive objects in an object oriented computer programming system, wherein the method is executed by a computer, comprising the steps of:

storing in memory means data describing the behavior of said model according to set of constraint on said behavior of said model, at least one of said constraints describing a temporal behavior of said model;

determining actions to be performed by said interactive objects and times at which said actions are to be performed according to said set of constraints;

generating events, each event comprising a representation of a message to be sent to said model for causing said model to perform one of said actions;

each event further comprising a time stamp representing a time at which the message is to be sent; and

generating a visible output in response to at least one of said actions performed by said interactive objects

2. The method according to claim 1 further comprising the steps of:

storing said events in an event queue;

incrementing a variable representing time; and

transmitting to said model a message representing by an event stored in said event queue when the value of time represented by said time variable rises at least to the time indicated by the time stamp.

3. A method for controlling behavior of a model embodied as interactive objects in an object oriented computer programming system, wherein the method is executed by a computer, comprising the steps of:

defining the behavior of said model in response to a triggering event by a network of constraints, including temporal constraints, on the state of said model following said triggering event;

creating and storing in a memory, representations of messages to be sent to said model;

creating and storing in said memory a separate time stamp associated with each message representation, each said message causing aids model to perform an appropriate action at a time indicated by the associated time stamp to satisfy said network of constraints;

incrementing a variable representing time;

transmitting each of said messages stored in memory to said model when time represented by said time variable rises at least to the time indicated by the time stamp associated with the message; and

generating a visible output in response to at least one of said actions performed by said interactive objects.

4. A method for simulating interactive elements utilizing a model embodied within an object oriented computer programming system wherein said model exhibits temporal behavior, wherein the method is execute by a computer, comprising the steps of:

instantiating a time management object for executing procedures embodying the temporal behavior of said model, including adjusting the value of a variable representing time and maintaining an event queue for storing events, wherein an event comprises a representation of a message and wherein an event further comprises a time stamp indicating a time at which said message is to be sent, said time management object being adapted to send a message to said model when the time represented by said time variable rises at least to the time indicated by the time stamp;

instantiating a temporal constraint object comprising a description of a triggering message for the model and a description of a temporal constraint on the behavior of the model in response to said triggering message;

compiling a response procedure to be executed by said time management object for storing a response event in said event queue, said response event comprising a time stamp indicating a future time and representation of a temporal constraint satisfaction message to be sent to said model for causing said model to satisfy said temporal constraint; and

generating a visible output in response to said behavior of said model.

5. The method according to claim 4 wherein said response procedure is compiled in response to said triggering message.

6. The method according to claim 4 further comprising the step of executing said response procedure whereby said time management object stores said response event in said event queue and then sends said temporal constraint satisfaction message to said model when said time represented by said time variable surpasses said future time.

7. The method according to claim 4 wherein said triggering message described by said temporal constraint object comprises a message sent to said model and wherein said temporal constraint is a relationship between objects comprising said model which said model satisfy when the time represented by said time variable is incremented by a predetermined amount.

8. The method according to claim 4 wherein said triggering message described by said temporal constraint object comprises a time incrementing message sent to said time management object for incrementing time represented by said time variable.

9. The method according to claim 4 wherein the step of generating a visible output in response to said behavior of said model comprises displaying an image on a screen of a computer terminal, the appearance of said image being controlled according to the behavior of said image being controlled according to the behavior of said model.

10. A method for simulating a collection of interactive elements utilizing a model embodied within an object oriented computer programming system, wherein said model exhibits temporal behavior, the method being executed by a computer and comprising the steps of:

instantiating a time management object for executing procedures embodying the temporal behavior of said model, including adjusting the value of a time variable representing time and maintaining an event queue for storing events, wherein an event comprises a representation of a message and a time stamp indicating a time at which said message is to be sent, said time management object sending said message to said model when the time represented by said time variable rises at least to the time indicated by said time stamp;

instantiating a temporal constraint object comprising a description of a triggering message and a description of a temporal constraint on the behavior of time model in response to said triggering message;

compiling a response procedure to be executed by said time management object for storing a response event in said event queue, said response event comprising a time stamp indicating a future time and a representation of temporal constraint satisfaction message to said model for causing said model to satisfy said temporal constraint, said response procedure being compiled in response to said triggering message;

executing said response procedure whereby said time management object stores said response event in said event queue and then sends said temporal constraint satisfaction message to said model when said time represented by said time variable rises at least to said future time; and

displaying an image on a screen of a computer terminal, the appearance of said image being controlled according to the temporal behavior of said model.

11. A method for animating the operation of an algorithm utilizing a model embodiment within an object oriented computer programming system, wherein said model exhibits temporal behavior in response to messages sent thereto, the method being executed by a computer and comprising the steps of:

instantiating a time management object for executing procedures embodying the temporal behavior of said model, including adjusting the value of at time variable representing time and maintaining an event queue for storing events, wherein an event comprises a representation of a message and wherein an event further comprises a time stamp indicating a time at which said message is to be sent, said time management object sending said message to said model when the time represented by said time variable rises at least at least to the time indicated by said time stamp;

instantiating a temporal constraint object comprising a description of a triggering message indicating performance of an action performed by said algorithm and a description of a temporal constraint on the behavior of said model in response to said triggering message;

compiling a response procedure to be executed by said time management object for storing a response event in said event queue, said response event comprising a time stamp indicating a future time and a representation of a temporal constraint satisfaction message to said model for causing said model to satisfy said temporal constraint; and

generating a visible output in response to said behavior of said model, said visible output representing operation of said model.

12. The method according to claim 11 wherein said response procedure is compiled in response to said triggering message.

13. The method according to claim 11 further comprising the step of executing said response procedure whereby said time management object stores said response event in said event queue and then sends said temporal constraint satisfaction message to said model when said time represented by said time variable rises at least to said future time.

14. The method according to claim 11 wherein said triggering message described by said temporal constraint object comprises a message sent to said model and wherein said temporal constraint is a relationship between objects comprising said model which said model must satisfy when the time represented by said time variable is incremented by a predetermined amount.

15. The method according to claim 11 further comprising the step of displaying an image on a screen, the appearance of said image being controlled according to the temporal behavior of said model and representing said action performed by said algorithm.

16. A method for animating the operation of an algorithm utilizing a model embodied within an object oriented computer programming system, wherein said model exhibits temporal behavior, the method being executed by a computer and comprising the steps of:

instantiating a time management object for executing procedures embodying the temporal behavior of said model, including adjusting the value of a time variable representing time and maintaining an event queue for storing events, wherein an event comprises a representation of a message and a time stamp indicating a time at which said message is to be sent, said time management object being adapted to send said message to said model when the time represented by said time variable rises at least to the time indicated by said time stamp;

instantiating a temporal constraint object comprising a description of a triggering message indicating performance of an action performed by said algorithm and a description of a temporal constraint on the behavior of said model in response to said triggering message;

compiling a response procedure to be executed by said time management object for storing a response event in said event queue, said response event comprising a time stamp indicating a future time and said response event future comprising a representation of a temporal constraint satisfaction message to said model for causing said model to satisfy said temporal constraint, said response procedure being compiled in response to said triggering message;

executing said response procedure whereby said time management object stores said response event in said queue and then sends said temporal constrain satisfaction message to said model when said time represented by said time variable rises at least to said future time; and

displaying an image on a screen of a computer terminal, the appearance of said image being controlled according to the temporal behavior of said model and representing said action performed by said algorithm.

Description Submit all comments and votes

BACKGROUND OF THE INVENTION

This invention relates in general to computer-based simulation systems and in particular to a system employing constraint satisfaction for temporizing a simulation.

Computer programs have long been used for simulating the behavior of a "real world" apparatus or process and an "animation" is a simulation which includes a graphical display representing the behavior of the apparatus or process. A computer simulation of a bouncing ball might include an algorithm for computing data representing the vertical position of the ball as a function of time. The data may then be used in a display.

In addition to simulating real world appearance of things, animation is a powerful means for representing the inner workings of a process which in itself does not have a visual aspect. For example, data structures are often represented by two dimensional diagrams because they are most easily apprehended in spatial, visual form rather than as a textual description or bits in a memory bank. By extension, understanding obscure algorithms operating on data structures could be assisted through simulation of dynamic motion in such diagrams and images.

Much of the appeal of animation is in being able to simulate the behavior of an experimental design to "see how it works." For instance, if an algorithm sorts bars by length, it is helpful to see the bars move about as they are sorted. However, this appeal is diminished if an animation is laborious to construct.

Experience has shown that about 80% of the code in computer-based animation merely implements animation graphics, even in an object oriented computer language like Smalltalk-80 (hereinafter referred to as "Smalltalk") which offers a high level graphics interface. ("Smalltalk-80" is a registered trademark of the Xerox Corporation and the Smalltalk computer language is described in the book SMALLTALK-80 The Language and Its Implementation, by Adele Goldberg and David Robson, published in 1983.

Animation difficulties are further magnified if one insists an animation must be more than pictures on a screen, and that the pictures should create the illusion of things they represent for allowing a user to interact with them. For example, an animated spring desirably acts like a real one in that a user should be able to "push" it or "pull" it and observe the response. This means the animation must be designed as a fully interactive interface and the user should be able to gain access to the code which drives the animation.

The requirements outlined above suggest the components for assembling an animation should be self-contained objects simulating "things" they represent. The internal state of each object should be self-consistent, in keeping with the real-world laws governing the item being simulated, and the picture of the object should change state consistently, according to the rules of some representational scheme. One may think of an animation as the creation of an image whose state is "constrained" to bear some specified relation to the state of an object simulating a "thing".

This need for consistency of state and representation makes the use of a constraint language desirable to implement animation. Constraint languages allow the programmer to declare relations that a system of objects must satisfy; it is the job of constraint satisfaction algorithms to automatically find a way to satisfy those relationships. The declarative character is attractive since it tends to reduce the creation of an animation to the writing of an executable specification, which one may expect to be simpler than writing out detailed graphics instructions in an imperative language.

One existing constraint oriented computer programming system, "ThingLab", is described in "ThingLab--A Constraint-Oriented Simulation Laboratory", by A. H. Borning, published July, 1979 by Xerox Corporation, in Xerox Palo Alto Research Center Report SSL-79-3, and in an article entitled "The Programming Language Aspects of ThingLab, A Constraint-Oriented Simulation Laboratory", also by A. H. Borning, published in ACM Transactions on Programming Languages and Systems, October, 1981. Constraints in ThingLab are implemented as objects that represent some relation as a predicate and contain a variety of methods as code fragments which can be used to establish the relation under different circumstances, depending on what is known. For example, a constraint predicate that a=b+c would contain the expressions a.rarw.b+c, b.rarw.a-c and c.rarw.a-b, any one of which may be used to satisfy the constraint. But depending upon what values are known or have just been changed, only one expression may be appropriate. The goal of constraint satisfaction techniques is to choose and order appropriate methods so that relations throughout a network of constraints are reestablished following a change.

The act of programming in a constraint oriented system consists of specifying, preferably in a graphical way, the interconnections among objects containing code fragments embodying the functionality of the part. The job of the constraint system then is to sort out and order those code fragments so that the composite shows the desired behavior of a coherent whole. One of the most attractive features of constraint languages is that they are fundamentally descriptive as opposed to imperative. The drudgery of hand-coding animations is in having to give explicitly imperative commands for everything that is to happen and appear on the screen. It is easier to merely describe in general terms how things should appear and let the system generate the code that would make it so.

The animated, dynamic responses of a system like ThingLab are user driven in response only to a command to "satisfy all constraints with these values now". Constraints in ThingLab are "static" rather than "temporal" in that they are satisfied in the same way for all time and are independent of time. There can be no history-dependent specifications because there is no history.

SUMMARY OF THE INVENTION

According to the present invention, a constraint system models time in order to provide meaningful and realistic animation. Time requires special treatment and cannot simply be inserted as another variable in a constraint relation. Static constraints have the property of satisfying themselves in multiple directions depending on computational circumstances. If time were treated as a static constraint, time could be set forward or backward erratically because of changes occurring to values dependent on time, unless time were given special treatment to insure its steady monotonic advance. Also there is a disjunction between the inherently discrete frame-by-frame, time-slice character of computation, and the kinds of continuum statements one would like to make in describing rates of change, e.g. V=dx/dt. One must consider how to provide a system to construct discrete approximations of continuous processes, and how to treat any errors in these approximations.

According to one aspect of the invention, a group of interactive elements is simulated by utilizing a model embodied within an object oriented computer programming system and the temporal behavior of the model is controlled by a further time management object. The time management object is adapted to execute a procedure for incrementing a simulation "time" by adjusting the value of a variable representing time, and maintains an "event queue" for storing events, wherein an event comprises a representation of a message and a "time stamp" indicating a time at which the message is to be sent to the model. The time management object is further adapted to transmit any message represented by an event in the event queue to the model when time represented by the time variable surpasses the time indicated by the time stamp associated with the message. Each such message sent to the model causes the model to carry out some procedure.

The model is made to respond to a triggering message in a temporal fashion by storing one or more events in the event queue in response to the triggering message. Each event stored in the event queue includes a time stamp indicating a future time at which a response message is to be sent to effect a particular response. As the time management object increments the time variable, the response messages described by the enqueued events are sent in the order that the events are time stamped. Thus the model can carry out an action or a sequence of actions in the future in response to a current triggering event.

According to another aspect of the present invention, the behavior of the model is described according to a set of temporal constraints on the future behavior of the model (e.g., on the assignment of values to variables it controls) which are invoked in response to a triggering message. When a triggering message is sent to the model for which no procedure has been compiled for satisfying temporal constraints, a response procedure is compiled for execution by the time management object which causes one or more events to be stored in the event queue. Each of these events includes a time stamp indicating a future time and a representation of a temporal constraint satisfaction message to the model for causing the model to satisfy the requirements of the temporal constraints triggered by the triggering message.

Thereafter, as the time management object increments the simulation time, it transmits to the model a message described by an event in the event queue whenever the simulation time surpasses the time indicated by the time stamp of the event, thereby causing the model to carry out an action in satisfaction of its temporal constraints.

Thus the present invention not only temporizes the behavior of the model by providing the time management object for controlling the actions of the model to be performed at a specified future time, it also automatically determines what those actions will be in order to satisfy a set of temporal constraints on the behavior of the model.

It is accordingly an object of the present invention to provide a method for controlling the behavior of a model embodied in an object oriented computer programming system such that the model operates in satisfaction of a set of one or more temporal constraints.

The subject matter of the present invention is particularly pointed out and distinctly claimed in the concluding portion of this specification. However, both the organization and method of operation of the invention, together with further advantages and objects thereof, will best be understood by reference to the following description taken in connection with accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIGS. 1-17 depict displays on a computer graphics terminal illustrating the operation of the present invention, and

FIG. 18 is a software block diagram of the present invention; and

FIG. 19 is a flow chart illustrating the sequence of operations performed by the time management object of FIG. 18.

DETAILED DESCRIPTION

The preferred embodiment of the present invention is implemented as an improvement to the ThingLab constraint satisfaction programming system, which in turn is based on the Smalltalk programming language. Accordingly, the basic principles of Smalltalk and ThingLab will be briefly discussed in order to provide a foundation for the detailed description of the present invention. Smalltalk is an object oriented computer programming language wherein computer software is organized into "objects" each comprising a block of program instructions describing various computer operations ("methods") to be performed in response to "messages" sent to the object. Such operations include, for example, the manipulation of variables and the transmission of messages to other objects. The "state" of an object is defined in terms of the values of variables that it controls and the methods associated with each object define its "behavior" in response to the messages it receives. Thus one may "program" in the Smalltalk language by writing individual blocks of code each of which defines (or creates) an object.

The Smalltalk programming language can be used to facilitate the modeling of interactive systems in that each component of the system can be modeled with an object, the behavior of each component being simulated by the methods of the corresponding object and the interactions between components being simulated by the messages transmitted between objects. A user may also communicate with an object through its image on a computer terminal screen, utilizing a mouse to control a cursor on the screen to point to the object and buttons on the mouse or a keyboard to transmit messages to the object. An object may also provide information to the user through its image on the screen, using data readouts or graphical changes to the object image. Although the object oriented environment of Smalltalk makes simulation development more intuitive, Smalltalk programming may be considered as relatively difficult to learn.

ThingLab is a "higher level" programming language based on Smalltalk wherein a user may specify the behavior of a system of interrelated objects by indicating "constraints" that the state of each object must satisfy, rather than by directly encoding the methods which define or control each object's behavior. Once the constraints are specified, ThingLab generates the necessary code for methods which cause the network to satisfy the constraints. In ThingLab, a constraint is itself implemented as an object "owned" by an object being constrained, the constraint object comprising a set of code fragments which can be used to establish various methods for satisfying the constraint. For example, an object might be required to control the values of three variables (a, b, and c) such that a=b+c. Accordingly, the associated constraint object would contain the expressions a.rarw.b+c, b .rarw.a-c, and c.rarw.a-b, any one of which may be used to satisfy the constraint. But depending upon which values are known or have just been changed, only one of the three methods for satisfying the constraint may be appropriate.

When a system of interrelated objects is specified in terms of a network of constraints, a change in state of any one object may trigger changes in the states of other objects in order to satisfy the constraint network. ThingLab chooses and orders appropriate methods for each object so that relations throughout the network of constraints are reestablished after a change to the constraint network.

In ThingLab, the state of such a system of objects changes only when a constraint is changed or when the value of a variable is changed by some stimulus event. However, an object cannot be "constrained"to behave in a temporal fashion by changing state at some future time in response to some event which happens now, but rather can only be constrained to fully respond "now" to an event that happens now. Therefore ThingLab is not suitable, for example, for modeling an RC network since the behavior of a capacitor in such a network is necessarily temporal. When a voltage across a capacitor changes abruptly, the current through the capacitor changes not abruptly but smoothly over time according to the constraint relation that I=C*dV/dt.

In accordance with the preferred embodiment of the present invention ThingLab is utilized as the basis of a programming system, hereinafter referred to as "Animus". A Smalltalk listing implementing Animus within the ThingLab environment is included as Appendix I to this application. Like ThingLab, Animus permits a user to describe systems of Smalltalk objects according to the static constraints that they must satisfy, but in addition thereto Animus also permits systems to be described in terms of "temporal constraints" wherein objects are constrained to carry out one or more actions in the future in response to a stimulus event occurring in the present.

The Animus system is well suited to creating animated simulations of physical systems. Continuous physical processes may be described by differential equations, as for example the equations of motion for a mechanical system. Animus provides the Smalltalk class TimeDifferentialConstraint which allows the user to specify such differential equations as constraints on the system's behavior. (Standard Smalltalk typographical conventions are used throughout this application. Class names are capitalized and may be shown in bold face while instance variable names begin in lower case.) The mechanism contained in TimeDifferentialConstraint satisfies a constraint by automatically generating and executing a finite difference approximation to the behavior specified. Thus, for example, in the definition of a class MechanicalNode one may find the constraint that v=dx/dt. That is, the prototypical instance of MechanicalNode has an instance variable representing a position whose value is constrained, as time advances, to be derived from the value of the instance variable for velocity. These constraints are "simple" because the response to satisfy them consists of a single event to adjust the object's state in the next instant, as contrasted with a more complex animation response such as sending an icon out on a trajectory of many step-wise time sequenced moves.

Typical Operation

There will first be described a number of examples of how the present invention might be used, followed by a more in-depth discussion of implementation. Suppose we wished to demonstrate or investigate the behavior of a capacitor discharging through a resistor. Referring to FIG. 1, showing an "Animus Browser window" 10 displayed on the screen of a computer terminal, we would begin by defining a new prototype class, selecting "define new thing" from a menu that pops up with a mouse button click in a first pane 12 of window 10. A dialog window then appears and asks for the name of the new prototype class, to which we respond by using a keyboard to type in "RC". The line "RC" will then appear in the first pane 12 as part of a list of prototypes. We select "RC" using the mouse and begin to build a prototypical RC network by selecting picture" in a second pane 14 listing formats, and "insert" in a third pane 16 listing operations. Operations of this general type are common to ThingLab.

Prototype constraint classes for electronic components are advantageously provided in a "kit" of such classes provided within Animus and includes such things as capacitors, inductors, oscilloscopes, and signal generators, with time dependent behavior built in.

A resistor prototype kit component, for example, includes the necessary Smalltalk code for controlling the display of a representation of a resistor on the screen as well as code for maintaining variables describing the state of the resistor (such as its resistance, terminal voltages and current through the resistor) and code describing the behavior of a resistor in terms of constraints its variables must satisfy (e.g. Ohm's law). The Ohm's law constraint (V=IR) describing the behavior of a resistor is "non-temporal" in that it does not involve time: a resistor fully responds to a change in one variable such as terminal voltage) by instantaneously changing one or more other variables (such as current or another terminal voltage) in order that the constraint is satisfied. The prior art ThingLab system includes kit components such as resistors which have non-temporal constraints.

On the other hand, constraints defining a capacitor have a temporal aspect because a capacitor behaves in a temporal fashion. The relationships between voltage, current, and charge variables which describe the state of a capacitor are modeled by differential equations involving time and therefore a change in any of these variables must cause a time dependent change in one or more of the other variables in order to satisfy the constraints which define the behavior of the capacitor. Thus, in addition to the necessary Smalltalk code for controlling the display of a representation of a capacitor on the screen, for maintaining variables describing the state of the capacitor and for describing non-temporal constraints on the behavior of a kit component as provided for in the prior art ThingLab system, a prototype kit component such as a capacitor desirably also includes code describing the temporal constraints on the behavior of the capacitor. This additional code, beyond what is presently included in ThingLab kit components, is embodied by the Animus system of the present invention by an instance of a TimeDifferentialConstraint class (described in detail hereinbelow) which forms an additional part of each kit component representing an object exhibiting temporal behavior.

To construct an RC network from such kit components, we select the object "Capacitor" from a kit of previously constructed prototypes in fourth pane 18. A flashing image of a capacitor 20 will follow a cursor 21 in a display area 22 of window 10 and allow us to locate the capacitor image 20 wherever desired in area 22 by moving the cursor and clicking a mouse button. We then insert a resistor 24 into display area 22 in a similar fashion by selecting "Resistor" from pane 18. (The lists in panes 12, 16, and 18 are scrollable and only a portion of each list is displayed.) The endpoints of each lead of resistor 24 are considered "sticky" and one will "merge" with a capacitor lead to form a circuit node 25 when brought close to the capacitor lead.

FIG. 2 shows a latter stage in the construction of the RC prototype. Once the RC prototype has been assembled, it may be desirable to probe it with an oscilloscope 26 (another prototype object available in the kit) inserted into the RC prototype to view the voltage between a circuit node 25 and ground 29. The "beam" of the oscilloscope 26 is constrained so that its vertical displacement is proportional to the voltage difference between its leads, and so that its horizontal displacement tracks the value of time.

To start the animation going, we simply select "go" in the third pane 16 in order to send messages to advance a "clock", an object in Animus which maintains a global variable called "time". The capacitor prototype 20, as the charge is discharged through resistor 24, constrains the current through it to equal the change in its charge with respect to time (i=dq/dt) which is provided with an initial condition charge (which may be adjusted by the user as discussed hereinbelow). When the clock is sent a message to increment time, constraint satisfaction requires that time may only be advanced in consideration of the constraint that i=dq/dt in the capacitor. When a time incrementing message is sent, Animus compiles a new method to respond to this message which, in addition to incrementing time, enqueues an "event" in an "event queue" (discussed in detail hereinbelow). An event is a description of a message to be sent upon the next increment of time ("tick" of the clock) to adjust the charge on the capacitor 20. This change to the charge in turn triggers other constraints which define the behavior of the RC network. Animus plans and compiles the necessary methods to implement this behavior based on the constraints triggered. These include methods to change the voltage on the capacitor (V=q/C), to change text displayed adjacent to the capacitor which indicates the charge on the capacitor 20, to move the beam on the oscilloscope 26, and to change the current through the resistor 24, along with text adjacent to the resistor indicating the resistor current. This planning and compilation phase takes about 30 seconds for the circuit of FIG. 2. After the methods are once compiled they may be executed without recompilation thereafter, and once the animation begins to run, clock ticks come with a satisfying swiftness and the motion of the oscilloscope beam attains a reasonable degree of smoothness. The resulting exponential decay seen on the oscilloscope 26 is not the result of any analytical calculation of exponentials, but occurs naturally as a result of finite-difference approximations embodied in the methods generated by the system to satisfy a specified TimeDifferentialConstraint associated with each time dependent element of the RC network.

The capacitor 20 is suitably provided in the "kit" with an initial charge. To reinitialize the charge, the user can edit the capacitor directly and simply assign a new value to the charge, whereupon the animation may proceed. To perform the edit we select "edit" in the third pane 16, and in the fourth pane 18 we select the kind of object we want to edit, in this case "Capacitor." We then obtain a cursor moveable flashing image of a capacitor in area 22 that will "stick" to any capacitor we select. Animus shows us the selection by displaying a box 30 around the selected element, as illustrated in FIG. 3. Clicking a mouse button on the selection now brings up a standard Smalltalk Inspector window 31 as shown in FIG. 4 in which values of the instance variables of the selection may be examined and edited. We select the text for the magnitude of the charge by selecting "charge" in window 31, edit it, accept it, and close the window. We may then resume the RC system operation by selecting "go" in third pane 16.

The new initial charge on the capacitor changes the initial voltage across the capacitor so that the exponential decay of that voltage, viewed by the oscilloscope 26 as capacitor 20 discharges through resistor 24 following the "go" command, begins at a voltage level which may be higher or lower than the previous initial charge. The implementation of this software to bring about these results is hereinafter more fully described.

As another example, referring to FIG. 5, we may build an electrical oscillator by selecting from the "kit" an inductor 33 and connecting it with a capacitor 32 and an oscilloscope 34 to build an LC circuit 36 in window 10. The "gain" and "sweep" of the scope 34 may be adjusted by editing the instance variables for the scope in the same way that the capacitor's initial charge was changed. Numbers printed beside the components are suitably constrained with each "tick" (i.e., increment of time) to indicate the charge on the capacitor 32 and the current through the inductor 33 in arbitrary units. The inductor 33 behavior is described by a TimeDifferentialConstraint indicating that V=L*di/dt, where "L" is inductance, "V" is the voltage across the inductor and "i" is the current through the inductor. When the LC circuit 36 is built and told to "go", temporal constraints for both the capacitor and the inductor must be satisfied. The method to increment time now enqueues two events, one describing a message to adjust the charge on the capacitor 32 and another describing a message to adjust the current in the inductor 33. These messages trigger other constraints so that a reasonable set of finite difference functions are effectively generated. After the LC circuit 36 has operated for many time increments, the oscilloscope 34 shows that the voltage across capacitor 32 varies in a smooth sinusoid.

FIG. 6 shows an animation of a mechanical analog to the electrical oscillator of FIG. 5, comprising a mass 40 on a spring 42. A spring prototype containing a constraint modeling Hooke's Law F=-k/x (where F indicates a vector force and X indicates a distance vector) is provided in the kit. Hooke's Law is expressed as a static constraint between the spring's extension and the force it contributes. The mass object 40, containing constraints expressing Newton's Law F=ma and the basic kinematic relations V=dx/dt and a=dv/dt, may be attached to the end of the spring, where these kinematics are described by TimeDifferentialConstraints as above. When the system is told to "go" methods are compiled that solve the constraints directly in two dimensions. If we graphically edit the mass's position by selecting "move" in pane 16 and "MechanicalNode" in pane 18, and utilize the cursor 21 to push the mass, the system will continue to oscillate, but in a way that can account for the "push" from the cursor.

If the motion of the bouncing mass seems too jerky, we can adjust the granularity of the clock increment by selecting "tick size" in the third pane 16 as shown in FIG. 7. This brings up another prompt window 43 in which one can edit the size of the "dt" time increment. A smaller value for "dt" tends to make the animation look smoother, though of course it runs more slowly in real time.

In FIG. 8 a "hand" object 41 from the kit (pane 18) may be inserted in the prototype which is constrained to drive the spring/weight system by moving the upper end 45 of the spring up and down at a fixed sinusoidal frequency. This enables observation of the transient behavior of the spring/weight system and also demonstrates resonance phenomena. The hand 41 introduces into the system a "scripting" TimeFunctionConstraint in which the value of a variable is determined by evaluating some function of time. That is, the hand prototype definition has an instance variable, "verticalOffset," defined by a sine function, A*sine(wt).

When time is incremented, constraint satisfaction enqueues a message that assigns the value of the function at the current time into the constrained variable, the vertical offset of the hand 41 from its initial position. Since the driving hand 41 is steadily adding "energy" to the system, the oscillation amplitude would increase without bound in the absence of damping such a that due to friction, air resistance or spring inelasticity. Such damping is conveniently modeled in the mass 40 itself as a slight modification to the constraint determining the acceleration. A term f * v, is simply subtracted from the value of acceleration, where v is a vector velocity, scaled by a damping coefficient f, yielding a force component proportional to velocity and opposing the direction of motion.

The animation of discrete processes such as algorithms poses a new set of problems. It is no longer so easy to describe temporal evolution using equations, but rather one encounters event-driven causes and effects. A principal means for describing responses to events is provided by the mechanism of TriggerConstraints. A discrete process is described by its "trace", the stream of events comprising it, and a TriggerConstraint allows the animator to specify certain graphical responses to the occurrence of particular events.

FIG. 9 shows an Animus Browser window 10 displaying an animation ("sorting") created to test an algorithm for sorting numbers by magnitude. The animation consists of representing each number by a bar of height proportional to the magnitude of the number, bars being placed a graphical queue in the order that the numbers are arranged before the sort. As the algorithm reorders the numbers, the animation graphically swaps the positions of the bars in the queue to show how the sorting algorithm sorts. To build a sorting animation in Animus we select an item from the kit (pane 18) called a SortQueue which causes a queue symbol 40 including a small rectangle 40a, indicating the start of the queue, and a dot 40b, indicating the end of the queue, to be placed in the display area 22 of window 10. We then graphically add elements (bars) to be sorted, each an instance of BarMagnitude (a kit item) represented by a bar 41 in a queue 42 of such bars, each bar being inserted between the queue start symbol 40a and the queue end symbol 40b. The height of each bar may be changed utilizing cursor 44, the magnitude represented by each bar being constrained to be proportional to the bar's height. The bar width remains constant.

After bar elements have been added to the queue 42, the algorithm to be animated may be invoked, as shown in FIG. 10, by selecting "send message" in the third pane 16 and "SortQueue" in the fourth pane 18 of windo