OUSA ’11 Recap

With the 4th of July weekend right on the heels of the origami convention, it’s been a busy few weeks. So here’s a bit of catching up. I had a good time at the convention, and caught up a bunch of friends. I also to a very positive response to the release of my new eBook. I taught my Walrus, which turned out to be a big hit, as well as my Narwhal. I also taught my Stellated Octahedron with Color Change, which turned out to be very challenging to fold. I came up with several new models including my two interlocking cubes (I’ve been working out how to do it with a color change from a single sheet), and some new tessellations including a Quadrose tiling and a Penrose tiling. I bought some nice paper from a vendor from Ohio, Origamido-style but thicker. The plan is to fold a few of my complex models out them, including the Zeppelin, Dragon and War Elephant. I also got an idea to extend my origami-from-space series to include a Space Shuttle. Photos of all this coming whenever I get around to it.

Every few years it seems someone new arrives on the scene folding amazing stuff. In the last few years it was T.J. Norville and then Dinh Giang. This year it was teh charming Beth Johnson, who has lots of curvy, dimensions models such as a pinecone and sheep that make use of tessellations as a design element. You can see some of her work at http://bethorigami.wordpress.com

My publisher Brian gave a Monday talk about eBook publishing for origami. One topic he covered is the diff between eBooks and apps. After we got to talking, and I realized my Foldinator is almost ready to be an origami app engine (notwithstanding the issue of running a Flash application on iOS). I haven’t worked on it in a while, and when I left off I was getting deep into the heart of the computational problem of mathematically representing and manipulating a folded piece of paper. The whole thing can be greatly simplified by just using pre-rendered graphics for each step. This may be a bit of a cheat, but it’s a good hack, since I’ve had to create images for all the models in me eBook anyway. So soon I’ll be putting together a prototype. Meanwhile, Brain has been dusting off my OrigamiXML spec with an eye toward expanding it for use in ebooks and apps.

Also, now that my ebook is done I’m working on putting together a print book. I’ve been going thru and making page layouts. This well be a superset of the ebook, with 20 – 24 models compared tot eh ebook’s 12. Hopefully when that’s done I can move straight on to a second ebook.

For the long weekend of the 4th we had out of town guests, a 70th birthday celebration for my father-in-law, a big ol’ barbecue the next day, plus trying to fit music and origami stuff and work around the house and yard. More on that soon. Back to the office today, which almost feels like a break. Lots more excitement coming in the next few weeks, with travel and adventure, so stay tuned.

Foldinator 2 Build 3

Development of Foldinator2 continues. You can see the third prototype here:

http://zingman.com/foldinator2/foldinator2.html

Earlier prototypes is archived here:

http://zingman.com/foldinator2/old_versions/foldinator2_build02/
foldinator2.html

http://zingman.com/foldinator2/old_versions/foldinator2_build01/
foldinator2.html

The main feature for this time around is that I am now generating the paper procedurally using the drawing API. This is core to the whole application, and everything going forward will be built on more sophisticated instructions to the drawing algorithm. The paper is initialized only after the user loads a model. The paper gets its initial state (white or colored side up) from the OrigamiXML for the model. I’ve defined a set of constants for the various lines weights and colors that the rendering will need. For the next build I am going to set the paper’s initial rotation as well.

I’ve also begun putting in controls to toggle the enabled states of the various buttons and to allow the user to switch between View and Edit modes. This will be more fully fleshed out in the next build.

Since it is still fairly early in the development cycle, even simple features require a fair amount of new behind-the-scenes structure to be built. For this build I extended the event framework to handle callback events. I use this in the app initialization sequence when loading the list of OrigamiXML files, and when a file is loaded to trigger the Paper initialization. I also created a class to hold application constants outside of the drawing API styles. These include definitions for steps, actions, folds and their properties and parameters. This will come into play as the folding code develops.

Fall Down, Part II

Seems that this is the time of year for work in progress. Here’s an update on a bunch of project. You can skip it if you find it boring.

My job has entered a new planning cycle. I’m trying to figure out how to deal with a manager who’s making it difficult for me to accomplish what I need to do. I want to moving forward with a major new feature set of my product, and he’s not getting it together to provide me with usable requirements. I working on him to see that it’s in his best interest to let me take over some things, but he is reluctant to give up control even though he’s spread too thin.

In music, I’ve been finishing off my album Face The Heat. I updated the page, including links to the newest mixes. I’m in the final phase, really focused on the details of the mixes now. Probably one or two pass at each song remains, but I find after I do a mix I have to take a few days and listen to it.

But in the sense that I want to finish my record to make time for origami, so far it’s kinda backfired. I have a trip coming up to California next month for the Pacific Coast Origami Conference, and I’d like to have something new for that. I took the summer off from working on my book, but now I have to get back into it. Last winter I was in a groove of diagramming over a model a month, but that’s a pretty heavy pace. So far this fall I made some corrections to my Lizard and began diagramming my Medieval Dragon, which will be probably over 70 steps! I also have a bunch of models in development, including some insects: a new butterfly, a dragonfly, and maybe another crack at the ladybug. And then there’s the batch from June that need further refining: the Blimp, the Sphere and the Orb UFO. So I’ve been doing some origami, just not as much as I’d like. Ah well I still have a month.

I’ve also made progress on the Foldinator, my origami software. It is now generating the paper procedurally using the drawing API. Also I‘ve defined the various lines weights and colors the application needs. I have a bit further to go before I release the next demo, however. I want to draw the initial state of the paper based on what it says in the xml file for the model. This requires a bit of plumbing so that the paper is aware when the model is loaded. After that I will probably go on to the non-folding operations, namely flipping and rotating the paper.

I’ve realized that I am long overdue in updating my origami site with pictures of my 2009 models. The web site redesign is probably far enough along that I should shift gears and take care of this before carrying on with that. The photography and photoshop is a whole little project in itself. While I’m at it, I should update my general photo gallery with pictures from the summer before it gets too far behind.

Foldinator 2 Build 2

Development of Foldinator2 continues. You can see the second prototype here:

http://zingman.com/foldinator2/foldinator2.html

Meanwhile the first prototype is archived here:

http://zingman.com/foldinator2/old_versions/foldinator2_build01/foldinator2.html

It still doesn’t fold paper, but it’s starting to do some interesting things. You can click on the “Load” button and see a list of models, encoded as OrigamiXML files. Select one and open it. You can see the UI update display the model name and author, and the text annotation for the first step. You can use the shuttle controls in the lower right to move forward and backward thru the steps, and jump to the beginning or end of the model.

A bunch of stuff is going on behind the scenes in support of this. I’ve implemented a file loader for the xml file that contains the list of models and their file names, as well as for the models themselves. I’ve create a hierarchy of classes to represent the data. The first of these is OrigamiModel, which contains metadata about the model, such as the title and author, and holds references to two other objects, OrigamiPaper and an ArrayCollection of steps. OrigamiPaper has properties for the papers proportions, color and starting orientation. The steps are of type OrigamiStep. This class contains properties for the steps action, annotation, and an ArrayCollection of creases. OrigamiCrease encapsulates the data to represent a crease, including properties such as the end coordinates, angle, parity swing, layers, etc. These last two classes will likely develop more properties and functionality as I build the folding engine.

I need to do a bit of bulletproofing around the initialization, and then it’s on to the main event, namely drawing and animating the folding paper. To begin with I’ll just be drawing a square procedurally and in accordance with the initial state specified in origamiPaper. Then I’ll be analyzing the geometry of the crease in the first step and breaking the square into appropriate polygons with a common edge, and rendering that. At first I’m going to concentrate on non-folding operations, namely Flip and Rotate the paper. Then it’s on to simple folds: Valley Fold, Mountain Fold, and Fold/Unfold. It’ll be a fair amount of work to get this far. Hopefully I’ll be able to apply this recursively for the second and subsequent steps, but more than likely there’ll be some gotcha.

Foldinator 2 – First Build

Development of Foldinator2 is off to a good start. You can see the first prototype here:

http://zingman.com/foldinator2/foldinator2.html

Admittedly it doesn’t do much yet. So far it’s mostly framework and boilerplate MVC code. Not so glamorous, but important, like pouring the concrete for the foundation of the house. The data model class is defined and has a few important properties, including a reference to an object paper, which is currently just a square drawn to the screen, but will be the heart and soul of the application. The app presents a starting UI, and all the buttons are mapped thru events to commands. There may be more views and interface elements later, but this is enough to get going; anything new will fit into the established structure. Also I put a text output console, to make debugging easier going forward.

I have one more milestone to go before I get into actual folding in simulation. First implement the guts of Load button, read in an XML file and parse it, and assign the info and the steps to the (data) model. Next is to step thru the model using the shuttle controls. At first this will be text–only. The app will display the step number and the annotation for the current step. Once this is done, then it will be time to apply the fold specifications to the paper for each step.

Meanwhile, my brother Martin has begun work on an origami application of his own, and post a demo here:

http://www.victoryhearts.com/origamagiro/

His working title for it is “origamagiro”, a nice palindrome, but then he looked up the meaning of “giro” in Japanese here:

http://jisho.org/words?jap=giro&eng=&dict=edict

Well “giro” could mean battle, argument, controversy, guillotine…. or brothel. Martin sez: “Interesting contextual possibilities! Maybe we need to find a person actually fluent in Japanese to ask!”

Martin’s approach is in many ways complimentary to mine. He’s developing in Silverlight, so the possibility of us sharing code is slim to none, but that’s ok cuz we can share ideas at a conceptual level, which may ultimately be far more fruitful. Second, while I’m working my way in and building the groundwork, he’s diving right in and confronting the hard conceptual problems of graphics, modeling an animation head on. So while my first demo has a bunch of nice looking buttons, his has a virtual piece of paper that the user can manipulate.

Watch this space for future developments.

Origami XML

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.