Recently I finally completed my first computer-drawn diagram featuring one of my most queried models, Seigaiha without cuts. It was quite an interesting task and I really learned a lot from it. In this article, I would like to share some of my thoughts on drawing diagrams.

The diagram is for sell on my Ko-fi shop, but you can preview the results here.

Inkscape

I drew this diagram using Inkscape, which, despite it being free and open-source software, is less chosen for professional diagramming as much as I know. Perhaps that is due to the fact that many designers have found it difficult to use for various reasons. In contrast, commercial vector drawing software such as Adobe Illustrator or Affinity Designer are more popular choices. But Adobe apps are well-known for their relatively higher prices, while Affinity Designer, though much cheaper and are promoted by a group of origami designers, simply doesn't feel intuitive enough to me (it definitely could be just me, since I didn't spend much time digging into it either). I was hoping that a completely free solution could exist, but when it comes to free and fully-featured vector drawing apps, Inkscape is pretty much the only one on the market, and previously I also would agree that it just doesn't cut it.

However, I would say that things are about to change. Recently the development of Inkscape has become really active, and many improvements have been done in the upcoming version 1.2 (still in beta as of this writing), including performance (Inkscape used to be REALLY slow; not anymore!), multiple page support (and can be saved as multi-page PDF directly), and various bug fixes. Although the beta version still contains bugs (which I am constantly reporting myself) and it still lacks a few features that I think will make it even more suitable for origami diagramming, I could pretty much testify that version 1.2 beta is good enough for creating professional diagrams.

You can download Inkscape 1.2 beta here. It works for all desktop platforms from Windows, Mac OS to Linux.

Basic configuration

In order to make Inkscape suitable for drawing origami diagrams, the most important setting is the rotation snapping as shown in the following picture. By setting the value to 22.5 degrees, the lines we draw will automatically snap to an angle that is a multiple of 22.5 degrees when we hold Ctrl key. You could also change it to 30 or 15 degrees when your model is 30-degree based.

However, Inkscape unfortunately doesn't provide 11.25 degrees as one of the options. I personally found the easiest way to create a line in 11.25 degrees is by first drawing a vertical line, rotating it by exactly 11.25 degrees (using the rotation transform in the Transform dialog), and then resize it to the length I need (by holding Ctrl as I resize it). For this method to work, it is also very important to keep the "Scale stroke width" option unchecked, so that resizing a line will not affect its width.

You would also need to set the bounding box to geometric mode for this to work. Otherwise, the direction of the line will actually change slightly as one resize it.

The perfect mountain-fold line pattern

It is conventional to draw the mountain-fold line in a chain pattern (dash-dot-dash, or sometimes dash-dot-dot-dash), as shown in the next picture. The first one is the line pattern one will find in most of today's literature, where the "dot" is really a tiny square of the same size as the width of the "dash" part. To me, that's simply not quite satisfying. I want the dot to be a circle instead, and it should be slightly larger than the width of the dashes, as shown in the second line pattern.

The good news is that Inkscape does provide a function called "Pattern along path" that enables us to create such a line pattern. To use it, we need to first create a "sample pattern" as shown in the next picture. Notice that it is a single path object (not a group of objects!) consisting of multiple subpaths (you could use path-union to create such an object), and it must be a filled path without stroke width.

Once you create the sample, copy it into the clipboard. Next, draw a line as usual, and then go to Path → Path Effects to open the Path Effects dialog, click the plus-sign button to add an effect, and select "Pattern along path".

Now click on "Link to path in clipboard" (which is the upper-right button in the next picture) and select "Repeated, stretched" in "Pattern copies". This will create exactly the type of line we want (make sure that the line itself is filled with black, and has no stroke color). It is also helpful to check the "Hide width knot" option so that only the end-point knots are shown when we edit the path. Of course, there's no need to repeat this process every time we want to draw a mountain line; once we created one, just duplicate it as we need.

One bonus upside about drawing patterned lines this way is that the pattern is "stretched" automatically, which means that no matter how long the line is, it will always contain exactly an integral number of repetitions of the sample pattern (as shown in the next picture). In our particular case, that means the line will always end in the "dash" part and never in the "dot" part. I've found this property to be extremely satisfying, as I would often need to adjust the "pattern offset" of a line by using the native stroke pattern mechanism.

Drawing arrows and symbols

The template file also contains the symbols I used in my diagram, and you can access them from the Symbols dialog.

One important note: as of this writing, due to a bug in Inkscape (which I have reported here), if you copy and paste a line that has a marker, it will create a duplicate entry in the marker list, which is pretty annoying. In order to avoid that, the workaround is to use "duplicate" (hotkey Ctrl + D) and then move it to the new location instead of copy and paste.

Creases stop before reaching the edges

It is conventional that creases, usually drawn in thin lines, stop before they reach edges (folded or raw). I think the way most people do that is by manually shrinking each line slightly; I think so because I often observe that they missed adjusting a few lines here and there. Doing this type of manual adjustment has at least three downsides:

1. It is quite inefficient, obviously.
2. It is hard to make the gap width consistent.
3. By doing so, the crease lines no longer intersect the edges. Those intersections could otherwise be quite useful for snapping.

A much better way to do this is by using clip paths to make the crease lines invisible near the edges. It only takes a few operations to handle all creases in an edge polygon at once, with consistent gap width, and the intersections are all kept for further use. In Inkscape, this can be done by the following steps:

1. Select an edge polygon and duplicate it (default hotkey Ctrl + D).
2. Use the inset command (default hotkey Ctrl + )) to shrink it. I usually perform it twice for most edge polygons, and once for smaller polygons.
3. Select one of the crease lines and the shrunk polygon (making sure that the polygon is above the line), and perform Object → Clip → Set. (This command has no default hotkey. I set personnaly it to Shift + C.) Doing so will create a clipped group.
4. Select the rest of the crease lines and move them into the clipped group in the Objects and Layers dialog.

Alternatively:

3. Select all crease lines in the polygon and group them (default hotkey Ctrl + G).
4. Select the group and the shrunk polygon, and set the clip the same way. This creates a new group around the said group. You can then ungroup the said group to simplify the hierarchy (however, I've found that keeping the extra grouping is helpful for future editing as well).

Make use of clone objects

It is commonly the case that later on we find some mistakes that took place in a much earlier step, and the error was copied and pasted throughout all the following steps. Clone objects could make our lives easier. It keeps the clone identical to the original object (can be a group) even if we modify the original object later on, so if we find any error, we only need to make the correction once. Clone objects can be created by the hotkey Alt + D.

Layer management

I use at least three layers in my document, which I call base, action, and reference. The base layer is where most of the drawings (paper layers, edges, existing creases, and text) take place. The action layer includes things that represent the operations in the current step (mountain/valley folds, arrows, and symbols). I put these into a separate layer so that I can easily skip those objects when I copy and paste the previous view to the next (all I have to do is temporarily lock the action layer, and drag-select everything in the previous step). Finally, the reference layer is where I put photos of my test piece for tracing complicated 3D steps. I will set the photos to about 30% opacity, lock the layer and trace it. After I'm done, I can just make the entire layer invisible and continue.

Styling

I use A4 size pages for this particular diagram, which is probably not ideal for physical publications, but it certainly works for digital ones.

I use three different line width:

• 0.1mm for existing creases.
• 0.2mm for edges.
• 0.3mm for things in the action layer.

This is roughly based on the suggestions given by Nicolas Terry, and having them in a progression makes it easy to change the storke width by just clicking the plus/minus buttons in the Fill and Stroke dialog.

I use 3mm Arial Font for normal text, filled with black and without stroke. Then bold font for the step index.

The color side of the paper is set to 30% gray, and the shades are black with 30% opacity.

這篇文章 Diagramming with Inkscape 最早出現於 Tsai Origami。

Some of you might have noticed that I recently wrote a series of articles about my old works dated years ago. I did that in preparation for an origami exhibition that I'm participating in for the first time, which takes place in Miaobei Art Center from March 2nd to April 17th. The exhibition is orchestrated by the Taiwan Origami Association and exhibits hundreds of models by more than 20 artists around Taiwan.

The plan for this exhibition was announced by chairman Chang of TOA at the end of last year when the art center contacted him. With 2 months available for preparation, one would expect me to fold more models for the exhibition. The problem was, my first daughter was also born around that time, so I was simply too busy to fold more. Plus I am super stubborn that I insist on displaying only my original designs, but then another problem is I didn't keep all my folds throughout the years. Besides my most recent folds, the best I can do is to select some of my older models that I still keep in good shape to enter the exhibition. In the end, I selected a total of 8 designs, just enough for one display platform. Not much, but good enough for me.

When it comes to origami, I'm arguably more interested in the theory of designing than in the final execution, and I think it would be a great idea to present the thoughts behind each of these designs, so I came up with the idea of showing the corresponding ERM maps next to models, together with QR codes linking to articles about them on this website. I choose ERM maps over the traditional mountain/valley CPs, because I think those are better for conveying the structure of the models, especially for non-uniaxial models.

On March 1st, I went to the art center setting up my own exhibits as well as helping other members of the association get everything ready. I must say, getting an exhibition ready is a lot more work than one would expect, but the members are all awesome people and working with them was quite an enjoyable experience. I also learned a lot by chatting with them about folding tips and thoughts on holding an exhibition. By the way, it was also my birthday actually, and there's no better way to celebrate it than this.

If you have seen the exhibition by TOA last year, we have more exhibits this time which I'm sure you won't want to miss. Be sure to visit Miaoli county and go check it out!

這篇文章 First experience of origami exhibition 最早出現於 Tsai Origami。

Overview

To put it simply, ERM is a generalization of the tree method to any origami design, let it be uniaxial or not. Roughly speaking, the tree method can be thought of as a design process consisting of the following steps:

1. Represent the target subject as a tree figure.
2. Solve the circle/river packing problem to decide the correspondence between regions on the sheet and components on the tree.
3. Construct a flat-foldable crease pattern for the packing, so that the sheet collapses to a base resembling the tree. A general algorithm exists for constructing crease patterns for arbitrary valid packings, but the idea of circle/river packing can also be applied to frameworks such as box pleating, hex pleating, and the 22.5° system.

While this is a very powerful designing method, one of its underlying assumptions is that the desired subject considerably resembles a tree, or a stick figure, consisting mostly of thin appendages. While an animal such as the one on the left in Figure 1 would be a suitable subject, one with a bulky body such as the one on the right will be less suitable (but not impossible, as we do have the notion of elevation and level shifting in the field of uniaxial design, extending the capability of the tree method to broader subjects).

A 3D structure on the other hand, such as the car in Figure 2, is almost impossible to fit in the framework of the tree method. (Notice how we can represent the wheels by 1D flaps since we know we can obtain rounded disks by squashing the flap.)

Therefore, it would be natural to generalize the notion of tree figures to what I call abstractions. An abstraction, roughly speaking (I shall omit the rigorous, mathematical definition here), is a connected collection of 1D edges, 2D polygons, and 3D polyhedrons. (A tree is therefore a special case that consists of only 1D components.) An abstraction can be viewed as the specification given by the designer for the desired shape of the folded base. An example of an abstraction that has all components from 1D to 3D would be a house with a flag on top of it, as shown in Figure 3; the house is 3D, the flag is 2D, and the flagpole is 1D.

(Before we continue, you may want to think about how one might design an efficient crease pattern on a square sheet for this particular abstraction; it's a good exercise.)

Then, we can say that ERM consists of the following analogous steps to those of the tree method:

1. Represent the target subject as an abstraction.
2. Solve the lake/river packing problem to decide the correspondence between regions on the sheet and components in the abstraction. The solution is called a map.
3. Construct a crease pattern (not necessarily flat-foldable, if the abstraction is inherently 3D) so that the sheet collapses to a base resembling the abstraction. A general algorithm exists for constructing crease patterns for an arbitrary valid map, but the idea of the map can also be applied to frameworks such as box pleating, hex pleating, or the 22.5° system.

As the title suggests, we'll be seeing quite a bit of geographical terms in ERM, "lake" being one of them, which I'll explain shortly.

In this article, I will focus mostly on the second part of the process, since the first part is rather straightforward and the third part is too technical for this introduction, but I'll also say a few words about them.

The core idea

To understand the core idea of ERM (and how it gets its name), we need to look back into circle/river packing, on which the tree method is based. The core idea of circle/river packing can be described as follows: each flap must occupy a circular region of which the radius equals the length of that flap, and each non-leaf edge in the tree must occupy a river of which the width equals the length of that edge.

However, circles can also be viewed as rivers that loop back into themselves and enclose just a single point. Thus, we can simplify the formulation above to just the following: each edge in the tree, let it be a leaf or not, must occupy a river of which the width equals the length of that edge.

Also observe that the purpose of a river is to separate the points on its two sides, to ensure there's enough distance between any pair of them. That is, given an edge in the tree, for any pair of vertices on the opposite side of this edge on the tree, their corresponding points on the sheet must also be separated by at least the same distance as the length of that edge. This is due to the fundamental law of origami stating that the distance between points shall not increase after folding.

This fundamental law applies to any model in fact, not just uniaxial models. Consider an edge \overline{AB} in a general abstraction (either a 1D component by itself, an edge of a 2D component, or an edge of a 3D component). We define a copy of a vertex in an abstraction to be a point on the sheet that will eventually be folded to the corresponding vertex in the base. By this definition and the fundamental law, all copies of A must be separated from the copies of B by a distance of at least \ell:=\lvert\overline{AB}\rvert, meaning there should be a river on the sheet of width \ell between these two sets of copies. For a copy of A and a copy of B with distance exactly \ell, it is clear that the line segment between them must eventually be folded to \overline{AB} in the final model. Similarly, we call that line segment a copy of \overline{AB}. The river corresponding to the edge \overline{AB} will then flow through several copies of \overline{AB}. But how does it terminate?

In circle/river packing, a river can only terminate in two ways: either by looping back into itself or flowing to the raw edge of the sheet. In the first case, the river will eventually be folded into a tube-like form on the left side of Figure 4 (one end may contract into a single point). In the second case, the folded river will have an opening, like the right side of Figure 4. These are pretty much the same for the 1D edges in ERM abstractions.

But for edges from 2D or 3D components, things are slightly different. If an edge is involved in only one face (either a 2D polygon by itself, or a face of a 3D polyhedron) in the abstraction (for example, the edge at the abdomen of an open-belly animal, or boundary of a mask), the river needs to connect to the copy of that edge on one end and flow to the raw edge on the other end. Eventually, it will be folded like the left side of Figure 5.

If it is an edge shared by two faces, it will have to connect the copies of the two faces and become something like the right side of Figure 5. It then makes sense to call those copies of faces lakes, since that's what rivers connect to in the real world. I also define the sea to be the raw edges of the sheet plus any unused corner areas of the sheet (which are typically folded under in the first step of collapsing). Now we can formulate the core idea of ERM as follows:

Given an abstraction in which all faces are convex, each face will correspond to a lake of equal size and shape, while each edge must occupy a river (could be of zero length, if it immediately joins two lakes) of which the width equals the length of that edge. The river must either loop back into itself, connect to a copy of the same edge on a lake, or flow to the sea.

(I will cover concave faces in the abstraction such as the side of the car in Figure 2 later.)

I would use the term "edge-river" if I need to distinguish between the rivers in ERM and the uniaxial rivers in the tree method. It might be tempting to assume that edge-rivers behave the same as the uniaxial rivers, such as being non-overlapping. Actually, things are a bit more complicated for edge-rivers, but before we get to that, let's first take a look at a basic example to get a feeling of the core idea of ERM.

First example

Return to the house depicted in Figure 3. If there is no flag, and if it is not required that we make the bottom face of the house, then it would be quite easy to come up with the crease pattern as shown in Figure 6. This pattern is folded directly in 3D and is not flat-foldable, but its structure is considerably straightforward and requires little explanation.

Even for a crease pattern as simple as this, we can already observe ERM in action. In Figure 7, the lakes are in blue and rivers are in aqua. The remaining yellow regions are known as lands, which is defined as any area not covered by water. Back lines are the boundaries of the lakes, rivers, and lands, and red lines are the ridge creases. Naturally, we call such a diagram depicting the distribution of land and water a map. Observe how every edge in the abstraction corresponds to some river (possibly of zero length) in the map, how the rivers change direction as they hit the ridge creases, and how they connect different copies of the same edge.

Conceptual map

Now let's try to bring the idea of ERM one step further, and add the flag to the house as depicted in Figure 3. As we make complicated designs, it is often very helpful to draw conceptual maps first, which are maps that are not drawn precisely and are only for demonstrating roughly how the rivers flow. For the sake of demonstration, let me label the vertices as shown in Figure 8.

A conceptual map can be drawn simply by using pencil and paper, and we don't need any tools or software to do that. Therefore, I will deliberately use my hand sketches for demonstration. Figure 9 is the same as Figure 7 but is drawn conceptually. Personally, I use double-sided arrows to represent rivers in my sketches.

Now, let us imagine how can we add a flag into the design, in particular at the vertex E. Obviously, right now there's no room next to vertex E that will allow us to add anything. Therefore, let us create some room by moving the lakes apart. But as we do so, remember that the copies of edges should still be connected to rivers.

In Figure 10, we rotate the lakes corresponding to the roof and move one of the walls away from the rest of the lakes. This creates some empty space in the middle that might allow us to add something in there. But it's easy to tell that this conceptual map is VERY inefficient. Not only now the overall layout looks more like a rectangle rather than our favorite square, but also observe the long rivers connecting that wall to the rest of the model. The key to overcoming this problem is to observe that two copies of the same edge DOESN'T always have to be connected by a single river. Instead, they could each connects to different rivers that both flow to the sea. In Figure 11, we break up the \overline{EG} river and the \overline{GK} river, and now things are much better. The overall layout looks more like a square, and we also have more room for the flag.

Now, we know that the flag pole, that is, the \overline{CE} edge, must also correspond to a river. This river needs the separate the lakes for the house from the surfaces of the flag, so one reasonable guess would be like Figure 12. Notice how the \overline{CE} river flows across the entire sheet. Also notice how we allocated both the front side and the back side of the flag so that additional paper can be tucked between them.

This isn't so bad, but notice that the way \overline{AC} river flows seems to prohibit \overline{CE} river from getting closer to the two \overline{CD} rivers. We could of course meander the \overline{CE} river to pack things tighter, but doing so could make the CP more difficult to construct with simple methods. Instead, let us rotate some of the lakes a bit so that things can be more easily packed, as shown in Figure 13.

Not only now the rivers are tighter together, but the overall layout also seems to fit nicely into a diagonally placed square. There are many possible ways we can construct a CP following this conceptual map, and one possibility is shown in Figure 14, in which I slightly adjust the proportion so that everything fits nicely in the 22.5° system. I also doubled one of the lakes for the wall to make the CP symmetric. In this picture, CP is overlayed on the ERM map in gray lines. (The brown lines are for finding references, should anyone would like to fold this model.) And Figure 15 is the finished model.

The main idea here is not about the details of converting the conceptual map to the CP, but about demonstrating how conceptual maps can help us envision possible layouts without bothering the specifics, and how changes in the flow affect the efficiency of our packing.

Lands

Each river has two riverbanks (that is, the boundary curves on the sides), each of which corresponds to one of the end-vertex of the edge corresponding to the river. In Figure 14 there are several pieces of land. Each piece of land is enclosed by several riverbanks, and observe that for a particular piece of land, its surrounding riverbanks all correspond to the same vertex in the abstraction. For example, the two largest lands in Figure 14 are both enclosed by E-riverbanks. In this case, we will call them E-lands. Conceptually, a piece of land represents the contraction of a single vertex, which means, roughly speaking, that part of the paper will eventually be collapsed to a small structure near the corresponding vertex. This is especially easy to observe for the E-lands just mentioned by identifying all copies of E around the land, as shown in Figure 16.

Lands come in different sizes and names. Tiny lands are called islands (one common example is the one-unit-plug used in box pleating). Large lands are called continents, which may seem like a waste of efficiency but are sometimes inevitable. One example of the continent can be seen in the 12-sided preliminary fold (it's like Montroll's 5-sided square, only with 12 sides; it can be used to fold an orizuru with 9 heads, for example) in Figure 17, where the continent in the middle corresponds to the top vertex of the base. Despite the existence of the continent, this layout is in fact optimal. It just happens to be the case that we don't need any extra features there for this particular abstraction. For models like this, the main challenge is to collapse the continent in such a way that the resulting structure is as thin as possible while also being small enough to not get in the way of other structures.

But perhaps the most important type of land in ERM is the peninsula, which is closely related to the notion of concavities in the abstraction. In the 2D case, we say that two edges in an abstraction form a concavity if the angle between them (on the side of the model) is greater than 180°. (In the 3D case the definition is more complicated, which we shall omit here.) Figure 18 is an example of an abstraction in which edge \overline{AB} and edge \overline{AC} form a concavity at A.

In most cases, by having a concavity in the abstraction, we implicitly specify that the negative space should be completely cleared out, and no extra layer should be exposed. In that case, the rivers corresponding to the two edges forming a concavity must not share riverbanks (it is allowed that the two rivers touch at a corner, but not on a segment of non-zero length), otherwise, it will be impossible to completely clear out the negative space (assuming that we want to fold the model flat), and some extra layers will always be exposed no matter how much we try. In particular, if those two rivers flow in parallel, then we must leave a gap between them in order to avoid those layers that I call connectors, which is defined as any visible layer in the folded base that is not part of the original abstraction. This gap naturally becomes a long, narrow land between the two rivers, which is what I call a peninsula.

The interesting question is, how wide should the peninsula be to make it work? Perhaps surprisingly, as long as there is a peninsula of non-zero width, no matter how narrow, there exists a CP that can fold it flat without connectors! However, the catch is, the narrower the peninsula, the more creases it will need to get rid of the connectors, and the local thickness can approach infinity as the width of the peninsula approaches zero! So although a narrower peninsula implies better efficiency, which technically means fewer layers on average over the sheet area, in this case pushing the efficiency actually means thicker layers locally!

So typically, we will use a peninsula not too wide that it wastes efficiency too much, but also not too narrow that it becomes too difficult to fold. For box pleating, it makes perfect sense to use a peninsula of 1-unit width ¹. To demonstrate, consider folding the abstraction in Figure 18 on an 8 × 8 grid using box pleating. Since \lvert\overline{AB}\rvert=3 and \lvert\overline{AC}\rvert=3, it may appear that it suffices to have those two edges connect to rivers of width 3 and have copies of B and C stay distance 6 apart, but in fact, that's not enough since A is a concavity. So we add a one-unit peninsula between them, and an 8 × 8 sheet just happen to have enough room to fit them all by using Pythagorean stretch between B and C. The result is shown in Figure 19. Notice that peninsulas are usually filled with zigzag crease patterns in the CP (but it may also not be the case due to crease transformations).

In my Sauwastika (shown in Figure 20), observe how the 8 marked concavities in the abstraction correspond to the 8 peninsulas in the map. Also notice that in four places the pair of rivers forming the concavity touches at one corner, which is allowed as mentioned.

Overlapping rivers and waterfalls

Perhaps what's more surprising than peninsulas is that in some other cases, edge-rivers can actually overlap. This is impossible if all components in the abstraction are 1D (that is, the abstraction is a tree), but as long as it has 2D or 3D components, chances are that we could utilize the interior of these components to overlap the rivers for better efficiency.

One simple example is demonstrated in Figure 21. Here we are trying to create the abstraction on the left on an 8 × 8 grid. Using our previous knowledge about the concavities, we can quickly convince ourselves that the only possible way to allocate the lakes (assuming that everything is under the framework of box pleating) is by putting them at the locations shown in the middle map. However, by doing so, the \overline{AB} river and the \overline{AC} river seem to overlap in the shaded area. Surprisingly, such overlapping is in fact legal, because the shortest distance between B and C (as we travel inside the model) is not 4, but \sqrt{8}, so as long as copies of B and C stay apart in such distance, overlapping of the river is perfectly fine. The final CP is shown on the right.

In other words, if two edges form an angle less than 180°, then they will be allowed to overlap to a certain extend depending on the angle. This is a very useful fact to keep in mind, as it can often help us to squeeze rivers into tight spaces. However, this can also make the map difficult to read as any part of the paper can have more than one role. In some cases, the overlapping can be simply represented by a shaded area as we did in Figure 21 without causing too much confusion. But in some other cases, overlapping can be quite large and complicated, and it is even possible to have a river overlapping with a peninsula (depending on how one interprets the role of that part of the paper).

In order to make sense out of complicated overlapping, I came up with the notion of waterfalls. A waterfall is a line on the map, which has the magical property of teleporting a river from one place to another. To demonstrate, consider the abstraction on the left of Figure 22, and a CP that folds to flat to that abstraction in the middle (for the abstraction in question, this CP seems less than optimal in terms of efficiency, but that is because this example is part of a larger design, and there are other considerations on the outside). What should be the underlying ERM map of this CP?

Most of the edges in the abstraction can easily be mapped to rivers as shown in the partially completed map on the right, except for edges \overline{AB} and \overline{AC}. One might expect that they correspond to two rivers traveling in the area with a question mark on the right somehow to connect the copies of those edges. But if we carefully examine the actual structure resulting from the CP, we will realize that the copies of these two edges actually each emits a single river that escapes to the sea while overlapping other rivers in a complicated way as shown in the left of Figure 23.

Such representation is clearly terrible as it requires lots of arrows to indicate exactly how the rivers flow. In contrast, the waterfall representation on the right is much cleaner and easier to understand. In this picture, waterfalls are the purple lines. We imagine that when a river enters one part of it, the river gets teleported to the other part of the waterfall. So now both edges \overline{AB} and \overline{AC} correspond to a single river each. (I draw arrows in this picture for clarity, but in most cases, the purple line alone is enough to indicate how the river gets teleported.) What happens in the actual fold is that the two parts of the purple lines will be folded together so that two river segments will be joined face-to-face instead of being reflected by a ridge crease.

Backside lakes and swamps

Now let us go back to one question raised earlier: what should we do if there're concave faces in the abstraction? There're several possible solutions. The first and perhaps the most elegant solution is to use curve folds and allow curved surfaces to create the appearance of concave faces (the definition of the abstraction can be generalized to cover curve folding as well) without adding any additional edges, or "seams" to the face. The second solution is to divide the concave face into convex subfaces and work from there. Doing so will add seams to the original face, which may or may not be aesthetically acceptable. The third solution applies only when the concavity of the face results in the face being partially covered by another face, as shown on the left of Figure 24.

In the abstraction on the left of Figure 24, one of the faces seems concave, but if we imagine that it actually has a hidden part underneath the other face (as shown by the dashed line; I don't usually draw those on abstractions, I do it here only for clarity), we can then treat it as a convex face and do our usual ERM thing. In order to make sense out of such a structure, we need to add another triangular face in between them, which can only be seen if we "open up" the abstraction into the net (as in "net" in the context of geometry). The lake that corresponds to this hidden face is known as the backside lake.

After adding the backside lake, we can then continue in the same way as before to create a CP such as the one on the left of Figure 25. In the middle we can see a map that is more a precise interpretation of the CP, where the usage of waterfalls faithfully reflects the structure of the actual CP, but such a flow can be a little too complicated to foresee in the beginning. In this case, I prefer to use a map with simplified rivers as shown on the right, which captures the essence of the layout without being overly precise. It is also the kind of map I will draw for the abstraction in the conceptual phase of the designing process.

Whenever we try to draw the ERM map for a CP, there's always the question of how precise we want the map to be. We want to map to reflect the actual structure as much as possible, but we also don't want to be too precise that the map obscures the essence of the layout. I tend to go somewhere in the middle where I feel the right balance is hit between the two goals.

Now we have seen how adding a backside face to the abstraction can help us handle abstractions in which some of the faces are stacked on top of the others. However, a backside face does not necessarily have to be allocated as a single, seamless lake in the map. Since the face is hidden in the finished model, we usually won't mind if it has seams on it. Therefore, we may allow the backside face to be formed by combining multiple smaller lakes.

Why would we want to do that? Although a single backside lake is easier to grasp in concept and is easier to plan the layout, it does have the disadvantage of putting a lot of restrictions on possible layout solutions. By breaking the lake into smaller pieces, we have greater freedom in possible layout, and in some cases, doing so is the only way to make things fit into the desired grid size.

For example, consider designing the abstraction on the left of Figure 26 on an 8 × 8 grid. With this grid size, the locations of the three lakes are uniquely determined, and there's no room to fit in a backside lake ². So instead, we split up the backside face into a swamp, which is indicated by the dark green region. That area will eventually be folded into the backside face, with one seam on it. The corresponding CP is shown on the right.

As a remark, one might notice that the overlapping rivers in Figure 21 can also be reinterpreted using a backside lake instead. It is true that in many cases, the same CP can be interpreted differently. The reason why I would personally choose the overlapping river interpretation is that to me, the backside lake is not readily suggested in the given abstraction, and I don't want to give the impression that one must be able to foresee the usage of the backside lake in order to come up with the map.

Applications

When one tries to apply ERM in designing, the first step is to draw an abstraction. In some cases (for example, when applying ERM to 22.5° system) the abstraction can also be conceptual, but for grid systems like box pleating or hex pleating, a precisely defined abstraction is preferred. In order to figure out the proper dimension of the abstraction, I often make papercraft models with scissors and glue to test if the abstraction can be shaped into a model of proper proportion to the subject. We also need to specify all hidden details of the abstraction, such as backside faces, numbers of digits or overlapping appendages, etc.

The second step is to plan the layout, starting by drawing conceptual maps. Once a conceptual map looks promising, then we can try to precisely allocate the elements on our sheet. The exact location of the lakes can be determined by considering the necessary distance between the vertices (i.e., consider how far it takes to travel from one vertex to another on the model, plus the necessary extra distance corresponding to the concavities). In box pleating, one must also consider the effect of the parity principle, which states that any two copies of the same vertex must have an even taxicab distance (otherwise, half-unit structures will have to be used, which may or may not be desirable).

The final step is to convert the map into a mountain/valley CP, the detail of which is too lengthy for this introduction. But at least for box pleating, many of the patterns are already well-known, such as rivers will become in-and-out pleats and peninsulas will usually have zigzag creases. When in doubt, one can always make a test fold on selected regions to figure out a working CP by trial-and-error. And in the most general case, there's always this general algorithm for converting an ERM map to CP as the last resort, which is very similar (with a few additions) to the Origamizer algorithm introduced by ‪Tomohiro Tachi.

I've been using ERM in my own designs since 2014, from mid-level complexity to super-complex models. One of the most ERM-intensive designs is my Domestic Shorthair Cat, of which map and abstraction are shown in Figure 27. It combines all ingredients we've introduced so far: peninsulas at concavities (many of them are 2-unit wide for the fact that 2-unit wide pleats are used nearby, or for strategical reasons), backside lakes and swamps, overlapping rivers and waterfalls, and 3D structure at the ears. One may compare it to the CP and folded base in Figure 28.

Another recent ERM design of mine is the Angelfish, as shown in Figure 29. In this design, the abstraction has more edges that are not orthogonal to the grid. This requires more sophisticated planning of backside faces in order to fit into the framework of box pleating. Thanks to the power of ERM, I was able to get a very satisfying proportion in the final model.

It is worth pointing out that in both Figure 27 and Figure 29, there are many places where simplified representations are used. For example, near the upper left corner of Figure 29, technically it really should be two overlapping rivers, as shown on the left of Figure 30. To me that's a bit unnecessarily precise, so I represented them as a single river that covers two edges in the abstraction.

Final words

That's all for the introduction. I would like to thank all my friends who helped me refine the ideas and presentation of ERM, especially Drew Heskett and Brandon Wong. Drew has also been very successful in applying ERM in several of his own designs. I hope ERM will inspire more designers to create models previously difficult or impossible to fit into the uniaxial paradigm.

這篇文章 Geography of Origami – A Brief Introduction to the Edge-River Method 最早出現於 Tsai Origami。

Today, likely for the first time in the history of origami, I folded a Senbazuru (literally "a thousand crane") from a single uncut square. Well not in the real world of course, but in the virtual computer space, using again our Orihime algorithm. In this article, I will share with you the story behind it.

Traditionally, it is believed that whoever folded a thousand orizuru can get wishes granted. Even today there are many commercial origami packs designed precisely for that purpose. As we enter the era of super-complex origami, it is tempting to achieve the same thing, but with a single uncut paper. That in itself is not difficult in concept, but it was never actually carried out for obvious reasons.

Back in 2015, I was interested in all kinds of different variations of the traditional orizuru, including the idea of an uncut Senbazuru. I wasn't aware of the second edition of Lang's Origami Design Secrets back then, so I didn't know anything about Lang's proposed method of folding the Senbazuru. Instead, I independently developed a different pattern for the "crane on a plane" subject, which turned out to be tighter than Lang's proposed pattern. Each tile is a 10 × 10 grid, which is shown in the following figure.

I also made an actual 3 × 3 model based on this pattern, which is like the uncut version of the "Seigaiha" found in Hiden Senbazuru Orikata. The folding sequence is very long and tricky, and it took me four days just to fold this model back then. Because of that, I never seriously considered going any further, knowing for sure that even 100 zuru will drive me nuts, let alone 1000.

Recently, because I've greatly improved the folding capability of the Orihime algorithm implemented in Oriedita, a few people bring up the possibility of folding this thing in the computer, and I know immediately this is finally my chance to make it happen. However, the complete Senbazuru CP contains more than a million creases (in my final CP, there are 1,187,392 lines to be exact), which is a completely different level of a monster than the Ryujin CP. A quick estimate shows that with the data structure I used for the Ryujin, it will take more than 200GB of memory to fold it, which is very impractical. Even after I subsequently developed a more efficient data structure, it will still take about 100GB, and of course, that's way beyond the ram of my laptop.

Fortunately, it is possible to launch Oriedita with much greater memory settings than the physical ram, and as it goes beyond the physical ram, it automatically switches to harddrive storage. With the speed of SSD, even such monster CP can be folded in a reasonable amount of time.

But before that, I need to draw the CP file first. My ideal version of the Senbazuru is not by simply arranging the zuru in a 32 × 32 formation (since that would be 1024 of them, which is more than a thousand), or by omitting 6 of them at each corner (several people, including Lang, have proposed this formation, but I don't like the empty space in the finished model), but by making 8 of them double-sized in the 8 directions. That way in will be exactly one thousand of them without any empty space.

However, by such design, I cannot just simply copy-and-paste the same pattern over and over to create the file, but since the whole CP is so large, manually editing the CP is equally infeasible in Oriedita since the processing time will be like forever for each operation I make. Therefore, I wrote another JavaScript program just for assembling the CP file from smaller components. The final CP is 83MB in size and can be downloaded here.

Finally, after a few more optimizations to the algorithm, after 4 hours and 10 mintues of runtime and 128GB memory settings, I successfully folded the Senbazuru. As for the wish I made, that's a secret obviously.

這篇文章 Senbazuru from a single uncut square 最早出現於 Tsai Origami。

In this article, I will share with you some of the stories behind Box Pleating Studio. I will be talking mostly from the perspective of origami; as for the perspective of programming, one may check out another blog of mine, in which I have a series of articles discussing such topics (only in Chinese though).

The discovery of GOPS

The story begins near the end of 2016 when I was first introduced, by Robert J. Lang himself, the second edition of his Origami Design Secrets. Before that, I had only read the first edition and had no idea that the second edition was out. Of course, I immediately ordered the book and was thrilled about the new chapters and materials, exactly as Lang suspected. We had been corresponding for a while by then, and he knew my math background quite well. He had the feeling that I might come up with some new ideas after reading the new materials, and he was right.

Coincidentally, when I received the book, I was working on the design of my Blue Crab, which used a mixed system of 30° circle packing and box pleating. The design was fine, but the mixed system inevitably induced some rather random creases for transitioning, and I didn't like the fact that I had to locate the random reference points by approximation. And I soon noticed that the idea of polygon packing mentioned in Chapter 14 of ODS could be a solution to my problem. So I tried to redesign my Blue Crab using this system, and it worked, well, kind of. Due to the fact that this model was designed aiming at commercial origami papers, its BP version used a grid of only 22 units, and thus there were some rather unpleasant level shifters required to make it work. So, in the end, I still prefer the original hybrid design. Nevertheless, when I was playing with the offset Pythagorean stretches, I started to notice some profound potential within as I asked the question, "what will happen if I use an offset greater than one?"

At first, that didn't seem to make sense, unless I do mean to make a level shifting that is greater than one. But, if we sink the additional offset back, then suddenly we open a whole new spectrum of possibilities. One problem with the original Pythagorean stretch is that perfect Pythagorean stretches are rare, and "imperfect" ones often come with gusset slivers; but with this generalized offset Pythagorean stretch, or GOPS, we have a much larger solution space and therefore is a lot more likely to hit a solution ¹, and even if there's no solution, its integral nature allows us to easily combine multiple GOPS gadgets into a compound solution. I also generalized the construction to cover layouts with three or more flaps.

Getting super excited by what I had found, I wrote a manuscript about 20 pages to Lang describing all the patterns I found. Interestingly, he was also working on his version of Pythagorean stretch generalization, which he called GPS (in which the "G" originally stands for graphical, but he then changed that to "generalized" in favor of my nomenclature), and it turned out that GPS is exactly the complement of GOPS. Lang also made a very important discovery that the area of the overlapping rectangle plays a significant role in both GOPS and GPS, which eventually led to our construction algorithm based on integer factorization ², which happens to have a deep connection with my background in number theory (who would have thought of that?). I then wrote another manuscript about 20 pages again to him, completing the algorithms for the general construction for multi-flap settings, and after several rounds of correspondence, in mid-2017 we decided to write a joint paper on the subject.

We concluded that the upcoming 7OSME would be the place to submit it. There was one problem though; OSME has some severe page limit restriction, 16 pages to be exact, and it was impossible to squeeze all our discoveries into that range (which would probably take somewhere around 60 pages, considering the extra length required for the complementary figures and the formal proofs to all our claims). We just had to choose the most essential part, orchestrate just one example that demonstrates as much as possible in the application section, and omit lots of details in its construction. Finally, we came up with exactly 16 pages (including references) with absolutely no spaces left. It is titled Generalized Offset Pythagorean Stretches in Box-Pleated Uniaxial Bases and it was published in Origami⁷, volume 2, pp. 591-606.

The development of Box Pleating Studio

So far so good, but I did realize that this is not enough. Not everyone could fully understand the construction (especially that we've omitted almost all the details in the multi-flap settings), and even if one does understand, it could still be a lot of work calculating those patterns, especially for multiple flaps. Therefore, since early 2018 I began to work on an app that will help automatically calculating these patterns.

However, I wanted this app to be a lot more than just a GOPS-calculator. I've done quite a few box pleating designs myself, of course, and one thing I've always found to be the most time-consuming is the need to draw different versions of candidate layouts over and over and over on grid papers. Even with just one slight modification to the underlying structure, I would most likely have to redraw everything, because such slight modification will likely affect the packing of the entire layout. I wanted to vastly speed up such a process by creating an app that allows you to simply drag the flaps around, and the app will automatically determine the necessary stretches and the shape of the rivers for you, while you can open multiple tabs to compare different candidate layouts. That means no more grid papers and no more hours or even days of trial-and-error, giving perhaps a tenfold speed-up to the designing process.

An app like this in origami is for the most part unprecedented, and I had no example to follow. Luckily, I'm not just any origamist who happens to know about programming; I'm a professional software engineer who builds apps for a living, which means besides knowing how to make an app, I also know quite a few things about how to make it good. I decided to build it as a web-based app, so that not only it will be completely cross-platform, but also that it can be used directly without installation ³, which will help a lot in sharing designs as well as promoting the app. I also designed a responsive (i.e. good for all screen resolution) user interface so that it can be used anywhere from desktops to mobile devices, while at the same time making it multilingual, with three languages built-in in the first version (now it has six).

The biggest challenge in this app is to make it fast; it needs to be able to instantly recalculate possible patterns as the user drags the flaps or makes changes to the tree structure. Dependency management is also a difficult problem: the shape of the river depends on the pattern in between the flaps, which depends on the overlapping status of the flaps, which in turns depends on the flap locations, and so on. A typical box pleating design can easily have thousands of such dependencies among the variables, and it would be a terrible idea trying to manage them manually by coding. In order to overcome such difficulty, I spent about a year developing my own programming framework called Shrewd, which is essentially a high-level implementation of the observer pattern in programming. It will automatically manage all dependencies for me, and update all dependent variables in the correct order, and only when necessary.

After finally completed the Shrewd framework, the next major challenge is about representing the stretch patterns as digital data. To know how the algorithm works is one thing, but to describe the algorithm to the computer is entirely another thing. I struggled with the representation for months before I finally had a major breakthrough in September 2020 when I came up with two extra layers of abstraction, "configurations" and "devices". With these abstractions, I could finally represent arbitrarily complex patterns as computer data.

That was such an exciting moment that I couldn't help making an early Facebook post announcing the Box Pleating Studio is on its way. Just a few days later, Lucas Tay Kiat Loong from Singapore contacted me, mentioned that he had been deeply interested in GOPS and even went as far as purchasing 7OSME vol.2 just for that paper of ours. Of course, that automatically gave him the entry to become the first alpha-tester. In the next few months, we worked closely together, completed the remaining implementations, made various improvements from his feedbacks, and fixed countless bugs. Finally, the first public version of Box Pleating Studio was released on Christmas of that year, which was intended as I consider that as my gift to the whole origami society.

It was a fairly good success; within the first week, there were already 1,500 (exactly) different users from 77 different countries/regions around the world. Of course, that didn't stop me from keeping on improving BP Studio. Since then I've made over 170 commits on the GitHub repository and made over 900 different builds, making BP Studio better every single time.

There is still a long long way to go. At this point, BP Studio still hasn't fully implemented all pattern constructing algorithms that I wrote down in my manuscripts to Lang, but slowly and surely I'm working towards that direction. I also have plans to add more features such as support for diagonal symmetry and tilted grid (made famous by the works of Shuki Kato), fully flat-foldable CP exporting, more editing functions, and perhaps, to eventually expand to non-uniaxial designs as well.

Original designs using BP Studio

As of this writing, BP Studio has more than 3,500 independent users. These are the original designs using (or partly using) BP Studio that came to my attention or were submitted to me by various designers since the release of BP Studio, in random ordering:

2021-2023

2024

2025

這篇文章 The story of Box Pleating Studio 最早出現於 Tsai Origami。