When two objects rebound after colliding with each other, it is due to a spring force, even though it may not look like it. When two billiard balls collide, the compression of the ball is limited to a miniscule fraction of its width but it still happens.

Using a spring force requires higher model rates to realistically collide faster, harder objects. The fps display in the demo shows the actual frame rate. The movie itself is set to 999 fps. On a 1.3 GHz P3 it averages about 980 actual fps.

repeat with s = 1 to 4
if s <> me.spritenum then
spOther = sprite(s)

–distance components
distX = (spOther.x) – x
distY = (spOther.y) – y

–pythagorean theorem to get distance
dist = sqrt(power(distX,2) + power(distY,2))

–spring force
xSpring = 0
ySpring = 0
minDist = (sp.width + spOther.width) / 2.0 - 10
if dist < minDist then
springF = (minDist – dist) * .02
xSpring = springF * -(distX/dist)
ySpring = springF * -(distY/dist)
end if

xTotalForce = xTotalForce + xSpring
yTotalForce = yTotalForce + ySpring
end if
end repeat

The algorithm is almost identical to general gravity, so only the repeat loop is shown. Instead of calculating gravity, it calculates spring force. Spring force only acts when the objects are within a certain distance of each other, expressed as dist < minDist.

The magnitude of the spring force is given by minDist – dist. This is the restPosition – position equation from the Spring Forces section. Scaling by .02 puts the force into proportion with other values in the animation. It can be considered the stiffness of the object, the higher it is the stiffer the object.

This demo gives each object a mass, and uses the mass in the
accel = force / mass equation. The behavior of the large object shows how mass affects acceleration. When two objects collide, each experiences the same amount of force, acting in opposite directions. This force translates into a smaller acceleration for more massive objects.

Mass can be set however you’d like. In this demo it is set to the cube of the sprite width, which would roughly correspond to its mass if it was a
3-dimensional sphere.

The type of collision modelled in this demo is for round objects with no friction between them. Friction or non-round shape would cause part of the energy in the collision to go into rotational velocity, making the objects spin.

For comments on the rest of the script, see General Gravity.

Mass is a measure of how much matter an object is made of, and is related to weight. In physics it appears in the equation

acceleration = force / mass

which is one of Newton’s three famous laws. Notice that the larger the mass, the lesser the acceleration given the same force. If you push with the same force on a ’78 Impala and a shopping cart, the cart will accelerate much faster. In the demos so far mass has been left out of the equation:

acceleration = force

which is simply giving mass a value of 1.

In animation, you may want to include mass in the equation so that you could give many objects the same behavior but different masses. For example, it would be useful in making collisions of objects of different sizes look realistic.

When using different masses with gravity, the equation used should be the general gravity equation, not the specialized one given in surface gravity.

Related Topics:
Space Viewport
Perspective & Other Depth Cues
Data Structures and Recursion

Space Viewport 2.0 – source movie

This demo builds on the first version by giving universe elements a depth and rendering with some depth cues, and also storing the universe model in a tree rather than a list.

Depth & Perspective
The field of action is still two dimensional, but adding depth makes the visuals more interesting. It’s pretty simple to do. Each element is given a z coordinate which is used for perspective and for blendlevel (haze) and locz (z-axis blocking).

Notice how the method uniToView() which maps universe to screen coordinates now makes use of the perspective value. First the offset from the camera is found (vec – camVec), then perspective is applied, then zoom and shifting:

on uniToView(vec)
vec = (vec – camVec) * persp
loch = vec.x * zoomLevel + viewRect.left + viewRect.width/2
locv = vec.y * zoomLevel + viewRect.top + viewRect.height/2
return point(loch, locv)
end

Tree Structure for the Model
Instead of being stored in a list, the objects of the universe are now stored as a tree. The universe object is the tree root, and each object’s position is relative to its parent. The circling planets show how the tree structure simplifies the programming—the planet script doesn’t need to take into account how the sun fits into the rest of the scene. For more on using a tree and transforms in animation see 3D World and the other 3D quad demos.

Migrating to a tree structure was made much easier by inheritance. Simply making the treeNode script the ancestor of universeElement gave all the model objects the properties and methods of a tree node.

This demo is a relatively rare example of the use in Lingo of a series of inheritance, where a script’s ancestor itself has an ancestor. For example, ship inherits universeElement which inherits treeNode. Does it make a difference if universeElement and treeNode are reversed in the order? It wouldn’t to the ship script, but there are reasons to arrange it the way it is. Abstractly, according to the “is a” relationship of inheritance, universeElement is a treeNode but treeNode is not a universeElement. Practically, if you wanted a node just for grouping in the model you can now just use a universeElement object (because it inherits from treeNode).