# Project: Terrain simplification

Develop C/C++ code to simplify a (grid) terrain into a TIN that approximates it within a specified error threshold.

The default interface is the following: your code will take on the command line the name of the grid to be simplified, the desired error epsilon, and the name of the output file where you'll write the resulting TIN. This is just a suggestion, feel free to change it as necessary.

./simplify set1.asc 10 set1.10.tin


The program should simplify the grid, time it, print a summary, and then render the TIN. The function to simplify the grid should be separated from the render and timed. The summary should include how many points are left in the TIN (both in absolute value and percentage of the number of points in the input grid), and total time for simplification. The time for simplification should not include the time to read the grid into memory, or to write the TIN to a file. In summary, one should expect to see the following on the screen when running your program:

./simplify set1.asc 10 set1.10.tin
total xxx seconds.
---------
starting simplification
n=184552.
...
done. n'=2019 (1.09% of 184552)
total time xx seconds
---------
writing TIN to file set1.10.tin


## The TIN file

We need to decide on the format of the TIN file, so that it's the same for everyone.

One possibility is the following:

nb points in TIN
nb triangls in TIN
point0_x point0_y point0_z
point1_x point1_y point1_z
...
0 5 9
10 7 8
...

Each triangle is specified by the indices of its vertices.

## Error

The error epsilon on the command line should be interpreted as an absolute value. Example: the command above produces a TIN that is within a distance of 10 (units) from the grid. The units here are the same as the units used for height in set1.asc.

When run with a large enough value, your program should output only the 4 corners of the grid.

When run with epsilon=0, your program should eliminate all the flat areas (including those formed by NODATA). If there is no flat area then running with epsilon=0 will not eliminate any points.

## Possible extensions

You can do several things to tailor this project to your tastes:
• simplify images instead of grid files. You'll get to write a reader of the image, and tweak the distance function to handle colors instead of heights.
• simplify a point cloud--- this will be really cool! once you sit down and think of how much of the algorithm for point clouds is same as for grids, maybe you'll see that it will be manageable, and fully worth it!
• Your do not need to compute a Delaunay triangulation. This may allow you to take some shortcuts and simplify your data structures, and even parallelize the algorithm! go ahead and use threads!
• interactive rendering: if you would like to do interleave the rendering and the refinement, you'll need two separate threads. Make sure the refinement thread still prints the running time.

## Writing the project report

You will use LaTex. If this is the first time you use Latex, check the WWW for more info about how it started and who started it.

I am providing a Latex template that you could use for the paper here:

http://www.bowdoin.edu/~ltoma/teaching/LatexTemplate/

To install Latex on your computer, you could try MacTex:
http://tug.org/mactex/

There are many latex guides online, if you should need anything beyond the template.

Here is a suggested outline for the paper:

1. [Section 1] Introduction and background:

A short description of what the problem is, how it is defined, why it is important and how its used. General level and relatively brief, at least for this report.

2. [Related work]:

In a research paper you would have a section in which you would discuss the related work, and how your proposed work addresses some of the questions left open in the previous work. This is not the case for this project report.

3. [Section 2] The simplification algorithm:

Here you describe, at a general level, the approach to simplification by incremental refinement. Don't go into implementation details here (wait until next section). Make this section pretty generic and at a high level. Mention that in order for the algorithm to be efficient, it would have to avoid re-computing the errors and find the smallest error fast. The reader should be able to understand how the algorithm works, but not necessarily how the pieces are implemented.

4. [Section 3] Implementation:

Here’s where you describe in detail your implementation: its main steps, and how they are implemented.

And also analyze the running time of your implementation function of n and m: for notation, assume you have a grid of n points, and you simplify down to m points. Each iteration adds one point, therefore iteration i works with a TIN of O(i) points. Your simplification stops after m interations, when the TIN has reached m points. Analyze the running time of one iteration, and the total time of the whole simplification. It would be very nice if you would state the results of your analysis as a theorem:

\begin{theorem}
The simplification algorithm described above runs in ...
\end{theorem}

5. [Section 3] Data structures:

This section goes even further into the implementation details. Describe in detail the data structures you use to store the vertices and the TIN. Assume you reached a TIN of m vertices — how much space your data structures occupy in total, as function of n and m. For example, if your data structure would be a vector of n points, each points stores its x,y,z coordinates as floats, the total size of the vector would be 3n sizeof(float) = 12n.

If you don't know the size of a basic type, you could start 'gdb' and print it:

[ltoma@dover:~]$gdb (gdb) print sizeof(int)$1 = 4
(gdb) print sizeof(int*)
\$3 = 4
(gdb) quit


6. [Section 5], Experiments:

Here I would like to see a table with the following test cases:

set1, error 0, 10, 50, 100
brunsdem, erro 0, 10, 50, 100
kaweah , error 0, 10, 50, 100
sierra , error 0, 10, 50, 100
portland_me, error 0,10, 50, 100

For each test case, record the running time (exclude render), and the number pf points in the simplified terrain.
7. [Section 6] Conclusion and future work:

Describe what you learnt in this project, what went well and what went wrong, what you wish you had done differently, any related stories that you want to share, any questions you ran into, any insights, and of course why you liked this class!

## What to turn in

1. The code for your project.
2. The project report (paper).

Make a folder called simplify in your svn folder on microwave. Include both yoru code and your paper.

There will be a prize for the fastest code! And also for the slowest code! (but don’t necessarily aim for it)

Enjoy!