Cookie Cutter
Group 4

Jason Winokar, Lyubov Golub, Mark Berman


Player Development

Minimal Width
We started by finding the orientation of the cookie resulting in the smallest width.

Bounding Box
Our initial idea was to create a rectangle around each cookie and then place the rectangles on the sheet. Rectangles are positioned in columns from top to bottom. When no more space remains vertically, a new column of cookies starts.

Physics Simulator
Our group was fascinated by the idea of using a physics simulator to solve this problem. If the cookies are dropped into a bag such that no cookie can overlap another, will optimal positioning occur?

To find out just what we were getting into we searched the internet for information on rigid body motion. A series of papers written by Chris Hecker was particularly helpful. We realized that implementing a physics simulator was feasible. It was a matter of detecting collisions and programming the correct response to them. As our simulator only needs to handle 2D shapes, collision detection is simple. Collision response is much more difficult. It involves using equations to find the linear and rotational velocities of colliding objects. Unfortunately, at this point we had less than two weeks to program our simulator. Since the physics we needed involved equations as frightening as this:

we decided to use general ideas about collisions and approximate the results. The final product is a simulator where cookies "fall" to the left side of the sheet, bouncing off and spinning around other cookies on the way.

Collision detection, as mentioned earlier, was simple. We checked whether any edge of a cookie intersected with any edge from every other cookie. We were able to use the property that all of our shapes are two dimensional and equal in size.

Translations are also handled in a very simple manner. Instead of calculating velocities and exact points of intersection, we simply consider cookies that are overlapping in some way. For each cookie that is colliding with another cookie, we create displacements that would make the cookies travel opposite to the other cookie's center. We use this displacement and add it to an accumulator for each cookie. At the end of all the collision checks, we apply the accumulated displacement for each cookie. We iterate this process until either there are no more overlaps or we reach a maximum number of iterations. This is not the most natural way of doing translations, but it simplifies the problem greatly with out much loss of realism. This method has the ability to out perform real physics. In the case of two flat objects resting on each other, as long as their centers are not perfectly aligned, they will try to make room for each other. But this method also has the ability to be less optimal than real physics because it does not translate the objects along the edge of collision.

Rotations are handled in the following way. For every point of a cookie inside another cookie, a vector is drawn from each center of mass to that point. The center of mass is approximated as the centroid of the cookie. The cross product of the two vectors determines the direction each cookie rotates. The cookies are then rotated by a constant scale factor.

The vectors we used in rotating overlapping cookies

Collisions with the boundary are handled similarly to collisions between cookies. When such a collision occurs, the center of mass of the "wall" is approximated as the projection onto the wall of the center of mass of the cookie. This is done so that collision responses do not depend on where on the boundary the collision occurs. Vectors to the point of intersection are then found and their cross product is used to rotate the cookie.

The vectors we used to handle collisions with walls

Inside our player, we pass each cookie shape, the number of copies, and the initial bounding box placement to the simulator. We then run the simulator a certain number of times, depending on the total number of vertices. There is no guarantee that running the simulator 100 times will produce a better answer than running it, for example, 50 times. For this reason, the simulator keeps track of the best move found so far and returns that move to the Cookie Cutter.

A sample run of our player using the simulator

Tools

Physics Simulator GUI
Our Physics Simulator shows us the progression of cookies falling to the side. The application allows us to set a cookie shape from a gamefile and the number of copies we want to see of the cookie. All of the copies initially appear in the center of the screen. Once we click "Step" the simulation begins. The cookies move apart so that they are not overlapping. Each subsequent step brings the cookies further along their fall. The step size can be increased to allow more steps for each click of the button.

This program was extremely useful in detecting errors. A cookie turns red when it overlaps with another cookie or the walls. The overlapping region is a deeper shade of red. With the help of this program we were able to visualize collision responses which aided us greatly in designing our fake physics.

This image shows two shapes colliding. The overlapping sections are a deeper shade of red.

After several steps, the cookies have gathered at the left wall.

Analysis

Advantages
The simulator produces very good results for convex and simple concave cookies. It likes triangles and v-shaped cookies, but isn't smart enough to handle cookies that fit into each other, such as the spiral shape we saw in class. For less complex shapes it produces results comparable to those we have seen from the greedy-algorithm players.

Here we can see our player performing slightly better than a greedy algorithm player. 

Boat Ten Copies
	Physics Simulator
	A greedy algorithm player (Group 2)

Disadvantages
The physics simulation is very time consuming. Each step involves performing collision detection and collision response. Collision detection must iterate through every vertex, sometimes multiple times. Collision response loops through every vertex several times more as resolving one collision may lead to another collision. For example, if cookie 1 has collided with cookie 2, cookie 2 will be pushed to the right where it collides with cookie 3. In order to ensure that every step produces a correct result, at the end of collision response the simulator checks every vertex for collisions with boundaries or other cookies, and moves cookies to the right if necessary.

For a large number of copies our player's performance deteriorates. The first few copies of the cookie have reached the left wall, but the rest of them have not traveled far enough to achieve good packing. More steps are needed to achieve the same performance with a larger number of cookies. 

Here you can see that the last two cookies have not had time to move closer to the rest of the pack.

Tournament Results
A few tournament results were surprising. We expected our rankings to have an inversely proportional relationship with the number of copies. Rather, the results more closely resembled a bell curve or zig-zag. Our rankings would peak at three or four copies and only then would drop. We did not optimally place one cookie assignments. Perhaps other groups checked angles at smaller increments than we did. We used a large margin between the cookies and border which also accounts for low one-cookie rankings.

Rankings for Boat. 1 indicates first place. 

With 2-5 copies our player used the maximum number of steps. The cookies were pushed to the side as far as they can go. However, for 20 or more copies our player was consistently ranked last among players who made valid moves. This occurred because, in order to save time, our player used less steps for a large number of cookies.

Our times ended up being huge for the implementation reasons stated above. In most cases, our time was larger than that of greedy and state-space search players. State-space and greedy algorithms take exponential time. Our player runs in high polynomial time with large coefficients.

The performance of our player is very shape-dependent. We originally thought that it would perform badly for shapes that fit into each other. However, we found that it performed equally well for these concave cookies as for convex ones. It did not find the puzzle pieces that fit but still managed to arrange the shapes well.

Concave cookies in tournament

Large cookies such as L.out, Group7Tournament, and Group6Tournament were a bigger problem. These cookies do not have a lot of room to rotate around each other and slide into optimal placements. They end up not moving much from their initial positions. For L.out, Group6 and Group7 we never ranked higher than 5th place, while for most other cookies we were able to reach at least third place.

Our player can be seen in all its glory in the boat tournament. This cookie is the perfect shape for the physics simulator. The many corners nudge each other and the cookies rotate around one another until they reach their final placement.


Improvements
We can greatly improve our players' performance for a large number of copies by handling the cookies in sections. For a batch of ten, it would be much faster to run the simulator on two batches of five. The cookies would not have to travel as far and good packing would require less steps.


Conclusions
Physics simulation was an interesting idea worth developing. We found that the simulation results in a very good placement of the cookies. However, the computation time for this method is prohibitive. Before physics simulations can be used in cookie factories further research must be devoted to reducing computation time.


Acknowledgements
Group 2 explained how the margins work in the Cookie Cutter. The algorithm for determining whether a point is inside a polygon was brought up by another group in class. The papers consulted can be found at http://www.d6.com/users/checker/dynamics.htm. Thanks to Prof. Ross and Abhinav for showing our Physics Simulator GUI during lecture.