July 2009

A have recently begun designing an XML format to represent an origami model as part of the development of Foldinator 2.0.

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 see OrigamiXML adopted as a standard that can be shared with the origami and software communities, so that Foldinator can share documents with other applications, fro example an origami themed computer game developed in SilverLight.

I started with a few examples of traditional and simple models expressed in Origami XML. They are: Picture Frame, a pureland model invented by Elizabeth Szinger (pureland means the model has only mountain and valley folds), and the traditional Swan, Waterbomb Base, and Preliminary Fold. These immediately bring up the issue of how to program reverse folds, which it I'll have to tackle 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 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.

The XML starts with some meta data, including things like the title of the model, the author, and copyright info. Then there's information about the paper: its 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'll start development on Foldinator 2.0 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.