The story of Box Pleating Studio

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: