As I mentioned last week, I feel inspired to dust off my origami software, the Foldinator, and try and move its development along towards a release version. I brief recap: I first conceptualized Foldinator as an application to author origami diagrams, since there is no such purpose-built software out there. As I thought about it I realized it would in fact have to be something of an origami simulation, with the steps of the diagrams working an actual animated simulation of the paper.
I started with the application design, concentrating particularly on the user interface and authoring tools. I wrote a paper on the subject with I delivered at 3OSME a few years back. I was writing it in Flash, which in those days meant ActionScript 1, which is a bit of a kludgey language without proper objects or data types. Around this time I was out of work for a while after the dotcom crash and made a good start on a prototype since I was able to give it some serious focus for a few months. The prototype could record and playback steps, and execute several operations including Rotate, Turn Over, (Valley) Fold and Fold, and Valley Fold.
When I got to the point where I had to grok a sequence of valley folds, I knew I had gotten to the heart of the problem. I had to figure out how to model this algorithmically to proceed, how to break the paper into a bunch of inter-related parts with hinged and/or joined edges. This made harder by the limitations of ActionScript as a language, which was not really designed for serious application development. I considered rewriting the whole thing in Java, but that would have meant a completely new approach and implementation of the drawing engine. A related problem was how to represent the data that comprised a sequence of steps. At the time I was using generic objects with properties, again due to AS1 limitations.
Around this time I got a new job and the amount of time and energy I was able to put into the project waned. After long days of writing software, it was hard to come home and work on a whole ‘nuther project at night, and besides, I wanted to put more of my origami time into actually designing and folding models.
Well things have changed since then and I figure it’s time to give it another shot. For a while I was trying to get some kind of R&D funding so I could work on this full time. But that does not look like it’s likely to happen, so I might as well get on with it.
One thing that that’s changed is ActionScript has grown up into a full-fledged Java-style object oriented language, and Flex into a professional grade authoring platform for web applications, built on Eclipse. Flex is a superset of Flash and includes the Flash vector drawing and animation engine. So the platform for Foldinator 2.0 is Flex.
Another thing that’s changed is I’ve figured out over the years how to be productive in small focused efforts that accumulate over time. (Having kids kind of forces you to get good at using your time wisely.) The key is to have a discreet and achievable goal every for every session that you sit down to work at something, whether it’s a few hours of even just an hour or less. Sometimes the goal can be just to think about it or come up with a plan for something, but I try and do my thinking offline, so when I sit down to work there’s a short-term goal. The first thing I did was create a new Flex project and set up the basic framework, and import my old Flash code to pick over and see what can be ported and what should be scrapped.
The other thing I did was to start to work out the data representation side. The first prototype focused on the authoring and interface side of things. This comes at it from the opposite end. Naturally, the logical choice is to use XML, so I thought coming up with an XML schema to represent an origami model would be an important step. Having googled “Origami XML” it does not appear that anyone has done any work on this. I told my idea to Brian Webb and he said “That sounds like a trip to Singapore right there,” referring to the upcoming 5OSME. I’m not sure I want to this, but I’m thinking of going to this year’s PCOC, because it’s in San Francisco and I used to live there and it’d probably be a lot of fun. Maybe there will be an opportunity to present a paper there, like the Monday sessions at the OUSA convention in New York.
In any event, the design goal of OrigamiXML is to represent a model by its folding sequence, in a way that’s application agnostic, in other words independent of Foldinator. I’d like to make OrigamiXML a standard that can be shared with the origami and software communities, so that Foldinator can share documents with other applications. I ran this idea by my brother Martin, who is thinking of developing an origami themed computer game in SilverLight.
I have started with a few examples of traditional and simple models expressed in Origami XML. They are: Picture Frame, a pureland model invented by my daughter Elizabeth a few years back (for those of you who are not folders, pureland means the model has only mountain and valley folds), the traditional Swan, the Waterbomb Base, and the Preliminary Fold. These bring up the issue of reverse folds, which it looks like I’ll have to get to sooner rather than later.
In the offing I have a few more models partially specified: The bird base and traditional crane, which will necessitate working out how to specify and execute a petal fold, the frog base, which will do the same for a squash fold, and a funny little thing I made up and call the bird-dog base, which is half a bird base on one side and half of Montroll’s dog base on the other.
If you look at the XML, there is some meta data at the top, including things like the title of the model, the author, and copyright info. Then there’s information about the paper: it’s proportions, whether it ought to be two-color and so on. Although I am mainly focused on single-sheet models, it supports specifications for multiple sheets. How to put multiple sheets together into a model is a bride to cross when we get there.
The heart of the document is the sequence of steps. Each step includes an action, which indicates the kind of step usually “fold”. It also has an annotation, which is a human readable description of the step, like those that typically appear in published diagrams.
Then there is room for any number of creases. At first I thought I would have just one crease per step, but then I realized it is necessary to have multiple crease to support reverse folds, squash folds, petal folds, and sinks. This means too that the OrigamiXML can support arbitrarily complex compound folds that collapse all at once, that are common in box-pleated models and other advanced modern styles.
A crease is specified by several parameters. First is the location, which can be either an end point and an angle or two end points. I’m not sure yet whether these coordinates are relative to the unfolded sheet as in a crease pattern, or to the current view of the folded model as in conventional diagramming. I’d prefer that latter, but have not yet worked out if this is possible, or if it will introduces too many cases of unsolvable ambiguities.
Other parameters include Swing, which specifies which way the folded paper moves (Left, Right), as well as Parity (“Mountain” or “Valley”), Type (Inside Reverse, Outside Reverse, etc., although I’m not sure if this belongs with the step of the crease), and an optional value for the number of layers to fold thru, which defaults to “all”.
Another feature is that steps can be nested, so a step can contain multiple sub-steps. The intent of this is to handle common diagramming situations such as “Repeat steps 19 -24 on the left side” or “Petal fold, repeat behind.” In the second case, this simple instruction actually breaks down into four steps. First the petal fold (which itself involves three creases). The next step is to turn the model over. Third is another petal fold, and last is to turn it over again. Having to make this into four steps in a diagram would be tedious to the diagrammer and bothersome to the folder, so I’m hoping to be able to automate this out.
That’s as far as I’ve gotten so far. I’d like to figure out a way to vet this to the origami community and get some feedback. Probably a simple post to the O-list ought to do it. Meanwhile I’ll start development on Foldinator 2.0 and by having it read in these XML files and parse them, and build the logic in the engine ones action at a time until it can execute these models. I fully expect there will be some back’n’forth between the XML and the engine to get the kinks ironed out. We’ll see how it goes. Wish me luck.