6.849: Geometric Folding Algorithms: Linkages, Origami, Polyhedra (Spring 2017)

Prof. Erik Demaine; Martin Demaine; Dr. Jason Ku; TAs Adam Hesterberg & Jayson Lynch

[Home] [Problem Sets] [Project] [Lectures] [Coauthor] [Accessibility]


2017 Projects

Here is a selection of the 24 projects, and resulting publications, from 6.849 in 2017:


Other than problem sets, the main requirement for this class is the project. The project consists of at least two components:
  1. A paper describing what you did.

    This should be a well-written document describing the problem you tackled (be it an artistic, implementation, mathematical, or writing challenge), what approaches you took, what difficulties you encountered, and what results you found, in addition to citing the relevant literature.
    Aim for on the order of 10 pages, say in the range 5–20 pages.

  2. A presentation describing what you did (or how far you've gotten at the time of presentation).

    You should prepare slides as PDF or PowerPoint, and you may also demo any software you wrote. All files should be sent to the staff by noon on the day of your presentation so that they can be loaded onto our laptop. Any complicated setups (in particular software) should be sent by noon the previous day so that we can test. If you absolutely must use your laptop, let us know ahead of time. Pure blackboard presentations are discouraged except for the experienced.
    The exact length is to be determined, but the presentations will be during normal lecture time.

  3. If your project involves writing software, then you should submit the source code.
    If your project involves a physical object, you should show it during your presentation.
Projects can take many different forms. Here are the five main general categories:
  1. Build or design a physical structure that uses ideas from this class.
    The structure might be furniture, architecture, sculpture, tool, or illustration. Your work should be both aesthetically compelling and technically grounded (though the latter need not be explicitly visible). The structure can be physical or virtual, though in the latter case the standards will be higher because of the reduced challenge. (One way to compensate is to make several virtual structures, e.g., connected in a theme.)

  2. Implement an algorithm, an illustration of a result, or a tool for experimenting with a problem.
    Typically, a good format for such an implementation is a web applet (written in CoffeeScript, JavaScript, Java, or Jython) but other environments are fine too.

  3. Pose one or more open problems.
    You might pose open problems related to another field of research with which you are familiar, or pose something that comes to you out of the lectures. You should think about solving the problem, and how it relates to other problems.

  4. Research: Try to solve an open problem.
    This is the most ambitious kind of project, so the expectations in terms of results are correspondingly lower. What is important is to describe a clear problem, take (at least) one good approach to that problem, and describe to what extent it worked or did not work. You should not feel pressure in terms of grades to produce results, but you should spend substantial time thinking and trying to solve the problem. (In particular, if you succeed, you/we can write a research paper and try to publish it.) Collaboration is particularly encouraged for projects of this type, as is participation in Coauthor and the open problem solving sessions during class.

  5. Survey a collection of 2 or 3 or more related papers.
    You should avoid overlap with the textbook, Geometric Folding Algorithms: Linkages, Origami, Polyhedra.
    Often it is appropriate to combine with the next type of project:

  6. Wikipedia: Write or substantially improve the Wikipedia articles for several geometric folding topics.
    Here overlap with the textbook is OK. Be sure to follow Wikipedia guidelines.


No matter what you choose, project proposals must be approved by the course staff. Project proposals are due Wednesday, March 15, 2017, and should be submitted via Gradescope (as a group submission if you have more than one person). See Problem Set 5 for details.

By MIT policy, the paper is due on the last regularly scheduled lecture of this class, Wednesday, May 17, 2017. The presentation is due somewhat earlier depending on when it gets scheduled into a lecture slot; if your presentation is earlier, you are expected to have made less progress, but you should still give a clear description of the problem you are tackling and what you plan to do.


Collaboration is strongly encouraged, especially for research projects—this is often the key to successful research in theoretical computer science. You can work in a group of students in the class if you find common interests. (Students listening to the class will likely have less time to devote, but they are welcome to participate in a project too.) In particular, we expect that many projects will naturally grow out of the collaborations during the interactive portions of class. We have higher expectations of projects by larger groups.

You are also welcome to collaborate with anyone outside the class, including your research supervisor (if you have one) and including the course staff. The only constraint for the class is that your own contribution should be substantial enough, both in terms of solving problems and writing it up. (To evaluate “substantial enough”, talk to the course staff.) In any case, collaborators should be clearly marked in the project proposal, paper, and presentation.


Many of the in-class discussions/results are suitable for extension into projects. In addition, here is a list of possible project ideas, or seeds of project ideas, extracted from Fall 2012 lecture (L) and class (C) notes and Fall 2010 lecture notes (O). You can also see some sample past projects from Fall 2012. Your project proposal would need to flesh out these ideas into a project scale (in particular, significantly larger than a problem set, and in proportion to your group size).


Coding Open Problems