The Collision Scenario

The collision scenario involves four balls on a (non-tracked) table with a bor-der. At the start a randomly selected ball (not selected using a Gaussian distribution) is given an initial impulse force with a random (non-Gaussian) angle and random (Gaussian) force magnitude. The ball is then allowed to move under friction, colliding with other balls and the border of the table.

When all balls have come to a standstill, another ball is randomly selected to be given another impulse force. This continues for the whole time of the scene.

The intuition for this scenario is that of a game such as pool or snooker.

Figure 5.5 depicts a frame captured from the output video of the collision sce-nario simulator. In the frame, the red ball was recently struck in the direction of the orange ball and has just glanced the pink ball out of the way. There are two points regarding the collision simulation that need to be highlighted. The first point is that the table does not have a green outline as it is not a tracked object. The second is that due to thickening the green outlines so that they are visible in a print format, it may not be noticeable that the balls objects are circular, rather than the rectangles used in the other scenarios. The reason for using a circular object representation is to produce an accurate simulation of the collision dynamics. Because of the tracker simulator still tracking the

objects as rectangles, there can be instances as shown in the figure between the red and pink balls where there is some overlap of the track boxes. This case is one of the reasons that the box overlap merging process described in section 5.2.2 has an overlap tolerance.

Figure 5.5: A sample frame from a video depicting the colliding scenario.

The balls are coloured red, blue, pink and orange. The black rectangle repre-sents the border of the table. The green outlines represent the track boxes for their respective objects.

Figure 5.6 depicts the kind of motion produced by the collision scenario simulator. As with the other two scenarios, the figure depicts 12 representative frames from a sequence of 30 frames that occurred over 1 second. The depicted motion demonstrates the fidelity of the motion simulation. The glancing blow between the red and pink balls shows that after the blow, the pink ball is slowly moving in a direction nearly perpendicular to the original motion of the red ball, as would be expected by a glancing blow between two balls in a game of pool. In addition, by the time the red ball has reached the orange ball, it doesn’t have the momentum to move the orange ball. This part of the figure’s example output showing a loss in the red ball’s momentum demonstrates two further aspects of the collision scenario simulator. Firstly it indicates the simulation of kinetic energy losses due to friction and secondly it demonstrates the simulation of imperfect collision elasticity, in this case from the glancing blow between the red and pink balls.

Each ball has four extra object parameters: the radius of the ball, the mass of the ball and an x and y velocity component. In this scenario the balls are not treated as rectangles but as spheres, though the size of the bounding rectangle is maintained in line with the ball radius. The motion function has six parameters: The elasticity of collisions between balls, the elasticity of collisions between a ball and the edge of the table, the initial impulse force mean and standard deviation, the percentage of velocity lost in each frame due to friction (the friction inefficiency) and the number of sub-frames to compute.

Figure 5.6: A selection of frames depicting the kind of movement found in the colliding scenario. The box colours are the same as in figure 5.5.

The collision detection employed is relatively simple. At each sub-frame, each ball is moved along by its velocity vector. Each ball is then compared with each other pair-wise. When the distance between two objects is smaller than the sum of their radiuses, a collision has occurred. This is the reason for a sub-frame parameter. In order to make sure that a ball does not move so fast in a single frame that it moves through a collision event instance and at the end of a frame is no longer overlapping the other ball.

When a collision event instance is detected, two stages of computation happen. First, both balls of the collision event instance are moved back along their current velocity vector so that the balls are in the position where the actual collision event instance took place. This is done proportionally to the magnitude of the velocities. The second stage is that the velocity vectors of each ball are changed based on the momentum of each ball, the angles of incidence, and collision elasticity.

The collision detection and resolution between a ball and each edge of the table is similar but simpler to that of two balls colliding. A collision is detected when the distance between the centre of the ball and the edge is less than the radius of the ball. When there is a collision, first the ball is moved back along the velocity vector to the position that the collision took place as before. Second, the component of the velocity vector that caused the ball to cross an edge is multiplied by −1, which has the effect of reversing the direction of the vector, and then the total magnitude of the vector is multiplied by the table edge collision elasticity parameter.

The final calculation that is computed in each sub-frame, after ball move-ments and collisions are detected and resolved, is the efficiency due to friction.

Each ball’s velocity magnitude is multiplied by the friction inefficiency param-eter, ensuring that all the balls that are moving eventually come to a rest.

The reason that the effect of friction is expressed as a per-frame movement

in-efficiency percentage rather than with coefficients of friction is to reduce both the number of parameters and the amount of computation required.