A general rule of thumb for origami design is that long, thin appendages should be allocated on the corners or the edges of the sheet for better efficiency. For spider subjects, most designers would choose to allocate all legs on the edges in an octagon formation, since using the corners would lead to an asymmetric layout.

Such a formation, however, tends to leave a relatively large empty space (comparing to the leg length) in the center. For spiders with larger bodies, such as tarantulas, we can still fully utilize the empty space for the body, but for slim spiders such as orb weavers, the space in the center is usually too large to be fully utilized.

To solve this problem, I looked into books on spider species, trying to find one with more features on the body so that I can fully justify the space in the center. And this particular spider soon caught my attention. It has a total of six spikes of its abdomen, a perfect choice for space utilization. The name "Micrathena" means "micro Athena", and "sagittata" means "arrow shaped".

In this design, I deliberately allocated the tips of each leg slightly off the edges of the sheet, making them strong enough to hold the body without installing steel wires. I also faithfully reflect the actual leg length differences in the design.

In retrospect, this design can still be improved quite a lot. The method I used to form the abdomen is overkill, and the last pair of spikes should be made longer (in some individuals, those spikes are really long). I also didn't make the color changing on the abdomen. I'm sure I would revise this design someday.

這篇文章 Micrathena sagittata, 2017 最早出現於 Tsai Origami。

This model was in some sense a tribute to John Montroll, who is the first person in origami history to accomplish the same subject from a single uncut square, with the correct number of major appendages, which was published in Animal Origami for the Enthusiast (1985). I try to use the smallest possible grid size to achieve all major features comparable to Montroll's design while making it 3D and optimally efficient. I managed to do all that in a grid size of just 25 (with some half-unit structures). I wouldn't say it's not possible to use an even smaller grid, but very likely the result would be off in proportion.

Anthropods are especially suitable subjects for uniaxial box pleating, hence there's no need to bring ERM into this design. Still, I present the map in the figure above with lakes to show where the body is allocated. One thing about uniaxial box pleating is that in many cases there would be no land at all.

The crease pattern of this design uses a variation of GOPS near the head, which was originally discovered by test folding. The studying of that particular pattern later leads to the discovery of the general transformation rules of GOPS.

這篇文章 American Lobster (Homarus americanus), 2016 最早出現於 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。

This was designed way before I created Box Pleating Studio, so it was done entirely by hand. (being such a non-uniaxial design, BP Studio couldn't render it yet anyway) Still, this is my most complicated design so far, and also the hardest to collapse. Its collapsing is so challenging that I guarantee that even the most experienced folder could struggle a bit. I don't mean that it takes a lot of time to do it -- it doesn't -- but that the manipulation is very difficult and atypical.

I was very ambitious when I was designing this model; not only I want it to be completely closed-back, but also I want to make it "clean" in the sense that there's absolutely no unnecessary edges on its body surface (as can be seen from the folded base in the next picture), while also create the "thigh piece" and the "shoulder piece". These requirements result in the super-complicated twist near the shoulders.

I also want to make a fully-featured head (including the whiskers), as well as toes/claws. And of course, the model must be considerably efficient. I indeed achieved all that: the layout really is remarkably efficient, if I'm allow to say that myself. However, it comes with a price that it's so efficient that the collapsing becomes ridiculously non-linear and difficult. If I could relax the efficiency a bit, the model could be a lot easier to collapse, and even though I will get unused sheet boundary as a result, I might be able to utilize those to create the belly of the model. Well, those will have to wait I guess.

I must mention that it was Shuki Kato's amazing animal designs that originally drove me into designing this model.

The layout is 43 units to a side. The head uses some half-unit creases. This is all flat-foldable except for the ears (gray area), which are deliberately made 3D. Part of the body layer is sandwiched between the front-leg layers. The neck is allocated with extra length to allow shaping into different poses.

This layout was designed using a design method of mine called "edge-river method", which is a generalization of the tree method to non-uniaxial models. A brief introduction may be found here.

See the description of each photo for more details.

這篇文章 Domestic Shorthair Cat (Felis catus), 2018 最早出現於 Tsai Origami。