The goal of this project is to develop a tool for terrain simplification. This tool will allow the user to load a grid, convert it to a triangulation, run the simplification routine, and visualize the resulting simplified triangulation.

**Interface:** The interface is open-ended. One possibility is
to have a `loadgrid`

command that loads a grid, converts it
to a triangulation and displays it; an approximation command
`approx`

that approximates the current triangulation within
a specified error threshold and displays it; and a save command
`saveTIN`

that writes the current approximated
triangulation to a file (You do not need to implement a
`saveTIN`

command, but it may be useful to look at your
output for debugging purposes; if you implement it pick a simple
format for storing a triangulation on file; you do not need to write a
function to load a triangulation from file). For instance:

lynx20: > makeitsimple makeitsimple> loadgrid set1.asc ..Loading set1.asc makeitsimple> approx set1.asc 3 ..Approximating set1.asc with error threshold e=3 makeitsimple> saveTIN set1.TIN-3 makeitsimple> exit ..Bye. lynx20: >

**Grid simplification: ** In the first project you used a simple
heuristic for implementing resolution on grids: for a given *r*,
you replaced every subgrid of *r* by *r* points with its 4
corner points; in other words, starting from the entire grid, you
*dropped* all points *(i,j)* in the grid such that either
*i* or *j* is not a multiple of *r*; or, equivalently,
starting from the 4 corners of the grid, you
*added* all points *(i,j)* in the grid such that *i*
and *j* are both multiple of *r*. This is a primitive
implementation of two standard approaches to terrain simplification:
*decimation* and *refinement*.

- With the decimation approach, we start with all points in the terrain, and iteratively drop points until the error of dropping any further point of the terrain is above the error threshold.
- With the refinement approach, we start with the four corners of the
terrain and incrementally add points until all remaining points are
within the error threshold of the simplified terrain.
The two papers below provide a detailed description of these two approaces and a discussion of possible optimization and their effect on the worst-case and expected running time:

- Fast Polygonal Approximation of terrain and height fields, M. Garland and P. Heckbert, CMU, 1995.
- Algorithms for triangulated terrains. M. van Kreveld. In Proc. XXIV-th SOFSEM, number 1338 in Lecture Notes in Computer Science, pages 19--36. Springer-Verlag, 1997.

Read these papers carefully and understand the effect of the
optimizations and the analysis of the running time. Then pick one
method (decimation or refinement) and implement two versions of it: a
brute-force one, and an improved one. For the first version, keep it
simple: Remember, the first goal is to have a simplification algorithm
that `runs`

. The second goal will be to speed it up. You
will not have time to do all the optimizations described in the
articles above; but you will have to do `something`

to
speed it up. To compare the two procedures you will time each of them
on the sample datasets and plot the running time as function of
dataset size.

To optimize an algorithm is a bit of an art. Not always what is optimal in theory will be fast in practice..however understanding the theory is essential. One rule of thumb to use is: if 80% of the total running time is spent in routine A then optimize routine A first.

For this project you need to work in teams of two people. The goal is to think more systematically about the structure of the project before starting the programming. Of course this means that you will end up doing less coding and more thinking (..is that good or bad?).

**Useful links:**

- Plane equation
- Point in triangle test
- Ray intersect triangle test
- CGAL (Computational Geometry Algorithms Library)

**What to turn in:** Each team will turn in a tar file with the
project sources and a brief writeup summarizing the method you chose
(decimation or refinement), the difference between the unoptimized and
optimized algorithms, and a table with the running times of your two
algorithms on the sample datasets. To time a program make sure nobody
else is using the machine and do not run any other process while the
program is running.

**Project demo:** At the project demo we will time the optimized
programs. The fastest one will be the winner. There will be prizes
(suggestions welcome!)