The classic origami application has been rebuilt for the web, available for free at:
finder.origami.tools
History
Reference Finder was created and released in 2003 by Robert J. Lang. The app serves a vital role to an origami designer. Briefly put,
Specify a point or a line on a unit square, the app will tell you how to reach it by using origami folds.
After a new origami design is created, typically you want to record the folding sequence, much like writing down the sheet music. You might expect to simply retrace your original steps, but this is rarely the optimal path, in most cases the folding sequence could be improved, perhaps:
- long sequences of pre-creases can be substituted for a more direct route to a crease.
- simpler folds can replace more complex maneuvers at no cost.
- the origami was designed using a computer.
Lang’s Reference Finder 4, (2003)
A more broadly-relatable example, this app will help you “divide a paper into 13ths”, or other non-simple ratios.
The new Reference Finder rebuilt for the web
Robert has more info about the app and its history on his site.
Inside Reference Finder
all possible reference marks visualized
Reference Finder works very intuitively, building a database of points and lines by simulating each fold just as a person would do, using all 7 axioms at its disposal.
Where does it start? The same way a person would, by making folds whose only dependencies are the boundary of the paper.
- (4) corners of the paper (points)
- (4) edges of the paper (lines)
- (2) diagonals (lines)
Diagonals are included, the reasoning probably being they are trivial to locate. The database build-cycle goes like this:
Given a set of input points and lines, compute every permutation of points and lines with the 7 axioms, resulting in a new set of points and lines. These become inputs for the next round. Repeat.
Each round of new data is a new rank, beginning with rank 0, the boundary marks. The original app limits the database to 500,000 entries of each type which cuts off midway through the 6th rank. This is illustrated by the image on the left, you can see that the square is more populated near the origin, the bottom left corner. This all required 50mb of memory, and impacted boot-time, making it a reasonable cutoff in 2003.
The image on the right shows the uninterrupted, complete calculation of lines up to rank 6, requiring 1,603,008 entries. The distribution is much more balanced, though you can still see a tendency to the origin. I believe it has to do with how the app prevents duplicate entries, and since geometry at each rank begins at the origin, origin-based geometry tends to win out.
API
The app is two parts, a front end built with Rabbit Ear, and an API available here:
reference-finder.herokuapp.com
To recreate this app, Lang’s original source code was used to export a sqlite database of the app’s memory contents with floating point precision to 13 decimal places. The database stores:
- every intersection point between two lines.
- each crease line and which axiom (and respective parameters) were used to form it.
Points
Lines
Querying the API will return a set of five (by default) nearest matches to your point, and include a step by step folding sequence in both machine and human-readable language.
A sample request/response looks like
request:
https://reference-finder.herokuapp.com/point?x=0.5&y=0.333333333333&count=1
response:
[
{
"components":[
{"type":"line","name":"the right edge","d":1,"u":{"x":1,"y":0}},
{"type":"line","name":"the left edge","d":0,"u":{"x":-1,"y":0}},
{"type":"line","name":"the bottom edge","d":0,"u":{"x":0,"y":1}},
{"type":"point","name":"the top right corner","x":1,"y":1},
{"type":"line","name":"A","d":0.5,"u":{"x":1,"y":0}},
{"type":"line","name":"B","d":0.25,"u":{"x":1,"y":0}},
{"type":"point","name":"C","x":0.25,"y":0},
{"type":"line","name":"D","d":0.2,"u":{"x":0.8,"y":-0.6}},
{"type":"point","name":"E","x":0.5,"y":0.3333333333333}
],
"error":0,
"target":{"x":0.5,"y":0.333333333333},
"solution":{"x":0.5,"y":0.3333333333333},
"sequence":[
{"type":"line","make":4,"name":"A","axiom":3,"parameters":{"lines":[0,1]}},
{"type":"line","make":5,"name":"B","axiom":3,"parameters":{"lines":[1,4]}},
{"type":"point","make":6,"name":"C","parameters":{"lines":[2,5]}},
{"type":"line","make":7,"name":"D","axiom":1,"parameters":{"points":[3,6]}},
{"type":"point","make":8,"name":"E","parameters":{"lines":[4,7]}}
],
"instructions":[
"make crease A by bringing the right edge to the left edge",
"make crease B by bringing the left edge to A",
"point C is the intersection of the bottom edge and B",
"make crease D by folding through the top right corner and C",
"the solution is at the intersection of A and D"
]
}
]
- components is every point or line involved in the solution
- sequence and instructions are the machine and human-readable instructions. These reference components by their index # in the component array.
Localization
The language component of the app is quite small, I was excited to translate this into as many languages as possible. I’ve also learned that this is not a trivial request to a translator as the phrases are built programmatically,
“the top right corner” and “point B” need to be interchangeable inside their phrases.
As of this posting, the app has been successfully translated into Español and Portuguêse (thanks Jorge and Sat). If anyone is interested in contributing a translation, check out the translation document, and be in touch- robbykraft at gmail. Thanks!
Big thanks to Robert Lang for his dedication to free and open-source software.