Using 12GB memory to fold the full Ryujin in 44 minutes certainly was an achievement, but I had this strong feeling that I could still do better. On one hand, both time and space consumption can still be improved. On the other hand, the CP file I used for folding has this weird mountain fold across the upper half of the body for flat foldability, and the legs are positioned in a way that the scales on them cannot be seen. I can certainly modify the file to fix those, but once I changed either of them, the new CP file completely defeated my optimizations and the runtime is again forever. As a result, I was on the second stage of my Ryujin quest for another 2 weeks, and finally, I made the program capable of folding the version depicted above in 16 minutes, using only 6GB of memory. I shall again document the journey here.

Memory optimization

One thing that troubled me was that the memory consumption was a lot more than what I estimated. So I started to look for what software engineers call "memory leaks", which means the program fails to release the memory allocated for data that are no longer in use. I discovered that, in the stages where the Orihime algorithm prepares the data for the solution searching stage, there was this matrix recording the adjacency relationship of all faces, which uses a huge amount of memory spaces (in the case for Ryujin it's about 5GB) but it is not needed anymore after the preparation stages. So just by releasing those memory spaces, I immediately got the memory requirement for Ryujin down to 7GB. ¹

However, 7GB still didn't sound good enough, and I was more hoping for 6; not for any particular reason, it's just that an even number sounds better (plus the memory consumption is pretty close to 6). That motivated me to come up with another idea called PseudoListMatrix (probably not a new invention). In one part of the algorithm, there's a pretty large matrix M where each position M[i][j] is a list of numbers, which consumes a lot of memory if we store it as a 3D array or as a 2D array of lists. The idea of PseudoListMatrix is to store, for each i, the list of numbers that appear in M[i][x] for some x, and similarly for each j, the list of numbers that appear in M[x][j] for some x. Then when the list of M[i][j] is required, we give the intersection list of the M[i][x] and M[x][j]. In general, this will result in a larger list than the actual M[i][j] list, but in that particular use case, the result is exactly M[i][j] due to the nature of the lists. With this data structure, I finally get the memory consumption down to 6GB, and almost without sacrificing the speed at all.

The power of quad tree

Up to this point, all my speed optimization efforts were focused on the searching stage only. By the time I successfully folded Ryujin for the first time, the searching stage had become so fast that most of the 44 minutes are spent on the preparation stages. As I look into those preparation steps, I realized that many steps could all be speeded up dramatically by a classical data structure known as the quad tree.

Basically, computer programs can't really "see" the objects on the 2D plane. All it knows is a list of objects represented by numbers. If we need to ask the question, "is there any two of them colliding", the naive way of answering this question is to examine all possible pairs of objects and calculate if there's a collision for each pair. So for n objects, this will take n(n-1)/2 comparisons, which will be a huge number if n becomes larger.

The idea of the quad tree is to divide the 2D plane into four quadrants and store the objects into the proper quadrant. If a quadrant contains too many objects, we divide it again into four quadrants within itself and repeat the process. Then when we ask the same question again, for each object, we only need to compare it against those objects that are contained in the same quadrant. This greatly reduces the number of comparisons to about n\log n (which is much smaller especially for larger n) and allows answering the question much faster.

Quad trees are so versatile that there're many places in the preparations stage where they can be applied, and each application saved about 5 minutes in total runtime. Combined with other optimization techniques (especially the indexing mentioned in Part 1), I eventually got the total runtime of the same Ryujin CP from 44 minutes down to just about 5 minutes.

Folding the unfoldable

However, even as the old Ryujin CP now folded so fast, a few CPs (such as the version above) still wouldn't fold; the runtime is still like forever. Two major obstacles happen in the searching process for those CPs: Too many potential permutations, and swapping looping.

First, in Part 1, I compared the searching process of the Orihime algorithm to solving Sudoku. For Sudoku, each square has only 9 possible numbers to fill, but here for each subface, the number of possible permutations is measured in factorials, which are enormous numbers beyond imagination. Although I already applied the idea of fixing the order of the longest chain in the given constraints, in some cases that still leave billions of billions of possible permutations that need to be checked, and that's only for one subface, while in Ryujin there are thousands of them!

Secondly, I mentioned the swapping algorithm in Part 1 as well. Although it's one of the most powerful speed boosts so far, it does have a small chance of falling into "looping", in which two or more subfaces repeatedly get swapped to the front of the others, and even reset the progress of them. In that case, the searching will never end in theory, which is even worse than the first problem I just mentioned, since that will only cause the search to run for a very very long time, but will still finish eventually in theory.

For two weeks I've been struggling with these two obstacles, trying various ideas without success. Finally, I realized that the solution to both of these problems lies in introducing new data into the search process. The permutation generator I designed has the ability to filter out invalid permutations based on the given constraints, so if there are still too many possible permutations left, it can only mean that I haven't offered it enough constraints. Similarly, if the swapping falls into a loop, one way to immediately break the loop is to swap a subface that we haven't seen before in front of the loop, as it creates a new sequence of subfaces that we haven't considered yet.

However, merely introducing new subfaces into the sequence doesn't necessarily create enough new constraints to narrow down the permutation generator. In order to quickly create more constraints, I used the Italiano algorithm mentioned in Part 1 to infer more stacking relations after each permutation decision of subfaces. This turned out to be a giant boost to the searching performance, comparable to the swapping algorithm. With these ideas implemented, I succeeded in folding the version above, as well as all the sample CPs that were previously unfoldable.

Ryujin final version

To me, the second version above is satisfying enough. But at the same moment, Avinash Karnik and Bodo Haag made another version of the Ryujin CP which folds the entire body in half, folds down the legs, and adds the head twist structure that is used in the real-world folding process. The resulting CP is even more complicated in layer stacking than all previous versions, and this CP again defeated my optimized algorithm. Fortunately, it wasn't anything major, but just a bug that was previously unnoticed as it only occurs to highly complex CPs. After fixing the bug, their CP folds just fine in 35 minutes. A lot longer than other versions of Ryujin CP, but at least it is foldable.

Of course, I won't easily stop there. Even this is no doubt a more complicated CP, I was hoping to get its runtime to less than 20 minutes. By observing the searching process up-close, I noticed that this CP in particular has several subface that is in fact critical but hidden at the very end of the initial subface ordering. This will cause the algorithm to hit dead-ends at a very deep depth and have to return several times, wasting dozens of minutes. To cope with this, I implement a new strategy saying that "if it hits a dead-end at a deep depth, also bring a few nearby subfaces with it during the swapping". This is quite effective in solving that problem, and eventually, brings the runtime to just 16 minutes. The result is the first picture above.

These optimizations are now part of the v0.0.10 release of the Oriedita.

Update:

The latest record for the first figure is 65 seconds using 3GB memory.

這篇文章 Fold a full Ryujin 3.5 with Orihime algorithm – Part 2 最早出現於 Tsai Origami。

Recently I've been spending quite some effort improving the algorithm of Orihime, a program developed by Toshiyuki Meguro. I was hoping to make it capable of folding the complete CP of Ryujin 3.5 (with shaped scales ¹) by Satoshi Kamiya, arguably one of the most complicated models ever created. It has been a quest of persuing both speed and space with endless challenges. After two weeks of work, I finally manage to fold the CP in its entirety on my laptop PC in 44 minutes using 12G of memory. In this article, I will share the story behind this quest.

For those of you who would like to try this optimized version of Orihime, check out the latest release of Oriedita. (Folding Ryujin will require v0.0.7 or above, and don't forget to launch it with large memory settings.)

How it began

The quest began when I was about to finalize the CP of Angelfish, my latest original design. The model being only 32-grid BP, I was shocked by the fact that Orihime took 75 minutes to complete the folding of it. I deeply wondered if there's anything about Orihime's algorithm that can be optimized to speed things up. The problem is, the source code of the original Orihime used mostly Japanese names for variables and functions, etc., making the source code pretty difficult to read and understand.

Luckily, only about two months ago, Mr. Gerben Oolbekkink (a.k.a "qurben") has made a fork of Orihime called "Oriedita" and converted most of the source code to use English nomenclature instead. By looking at the source code he translated, it took me only a few minutes to spot the first place that can be made a lot more efficiently:

public int FaceId2PermutationDigit(int im) {
    for (int i = 1; i <= faceIdCount; i++) {
        if (faceIdList[getPermutation(i)] == im) {
            return i;
        }
    }
    return 0;
}

This was a function that is called repeatedly in the process of searching for a valid layer stacking order. Each time it is called, it performs what computer scientists call a linear search to locate the digit location of a given Id. This is way too slow. A much more efficient way is to store the correspondence of Id and location in an array, and then just look up that array directly.

int[] FaceId2PermutationDigitMap; // Initialized to be large enough

public void reset_map() {
    for (int i = 1; i <= faceIdCount; i++) {
        FaceId2PermutationDigitMap[faceIdList[getPermutation(i)]] = i;
    }
}

public int FaceId2PermutationDigit(int im) {
    return FaceId2PermutationDigitMap[im];
}

By making this change, the runtime of my Angelfish immediately dropped from 75 minutes to just 500 seconds. That's 9 times faster by just changing one function.

More optimizations

After I announced my result, several people soon sent me more large CP samples that previously took a very long time (or practically impossible) for Orihime to fold. Indeed, even with the optimizations I made, some of them still won't finish overnight. In a few days that follow, I found a few places in the code that can be optimized, but they all only led to slightly faster runtime, and none of them would give a significant improvement.

A few days later, I discovered the most significant boost in the entire quest: the swapping algorithm. Basically, what Orihime does is kind of like solving Sudoku, where the "subfaces" in the model are like the squares in Sudoku, and the permutations within the subfaces are like the available numbers to fill in the squares. Orihime performs an exhaustive search on the subfaces in a certain order and tries to find a permutation for each of them that is consistent. Once the algorithm finds a subface without a consistent permutation with the previous subfaces, it backtracks to the previous subface and chooses a different permutation, and continues.

But just like Sudoku, sometimes it is a lot faster to solve the puzzle by first fill in some of the "critical" squares, as they will quickly help to narrow down the possible numbers for the other squares. The problem is, it is not very obvious which subface is more critical from the beginning. We can, however, conclude that a subface is more critical than those few before it by observing that the search repeatedly hits a dead-end at that very subface. In that case, we dynamically swap the search order and work on that subface first.

This technique is so powerful that it suddenly brought the runtime of my Angelfish to just 3 or 4 seconds, and it also makes all other samples people sent to me folded in a feasible amount of time, with only one exception, Ryujin 3.5 by Satoshi Kamiya.

Taming the divine dragon

It was hard for me to say "OK we're done here; forget about that one model that won't fold," since I was quite far from running out of optimization ideas yet. I used to say "I'll never fold Ryujin in my lifetime" (the reason is, if I'm spending that much effort folding one model, it better be my original design), but at that moment I ironically found myself seriously considering folding one, only in the computer instead.

The biggest challenge with fully shaped Ryujin is not about speed, but about space. It has way too many creases and faces, and it takes a crazy amount of memory to fold by the original data structure (estimated to require at least 30GB of memory). By using bitmap arrays instead of 32-bit integer arrays, I managed to control the total memory usage down to less than 12GB (maybe even less), which is feasible on my laptop.

Of course, that doesn't mean that speed is not an issue at all. Even with the swapping algorithm, it still took about a whole day to fold only half of the Ryujin CP. To this end, I improve the permutation generator by fixing the order of the longest known chain in the constraints provided, and this led to a factorial speed up for iterating over possible permutations, making the half Ryujin fold in less than half an hour.

I also replaced the Warshall algorithm used by Meguro for finding transitive closure with a much faster Italiano algorithm ², but again that algorithm requires quite some memory to run. The last piece of the puzzle I put in to make it work, is by optimizing the memory used by the Italiano algorithm. The idea is pretty simple but took me a while to figure out: all I had to do is to flush out the changes more frequently, and not to let them piled up in the memory.

So finally, I succeed in taming the divine dragon. For more details about the individual optimizations I made, check out each pull requests I made on qurben's repository.

Update:

Check out also Part 2 of my Ryujin journey!

這篇文章 Fold a full Ryujin 3.5 with Orihime algorithm 最早出現於 Tsai Origami。