




Date: Wed, 30 Mar 94 10:39:13 AST
From: larrys@zk3.dec.com
Subject: Re: 80% (origo)

>       just until there's a name, I'm going to keep the
>'80%' title on any posts converning the origami script language.

Suites me.  But I kinda like "origamigo".

>Where I use stuff that looks like code, I'm going to write it
>similarly to PostScript. This isn't because I think PostScript
>would be a good language to write the program in: it has some
>particularly bad features for this purpose anyway. However,
>postfix, stack-based, threaded interpretive languages (TIL) are
>much easier to write (I mean from scratch, not using YACC).

No kidding.  I prefer them myself. ( FORTH Love IF honk THEN )
But, sadly, this may not be a good idea.  If we hope that this
language will actually be used for taking origami notes, then
we can't use RPN, it just drives users nuts, they hate it.  The
best paradigm is probably [you should excuse the expression]
BASIC.  My example code is sort of BASIC with a strong C flavor.  For
me, readability is the key.  If you disagree with that notion, the
following does not apply.

However, if we view this as the "internal" representation for
just the computer, we can work out a simple mapping for a BASIC-
like note language to the internal RPN form.  We'd need to make
sure we don't leave the "external" langauge out of consideration,
though.  Push it off until later and it'll never get done.

>       b) every complex fold is a collection of simultaneous or
                                                 ^^^^^^^^^^^^
This is a good point.  If statements refer to folds and some folds
are specified to collapse simultaneously, then we can somewhat
simplify certain things.  Suppose:

  together { vf a->b; mf c->d }

We could allow a postfix naming convention:

  together { vf a->b; mf c->d }: half-rabbit-ear

which would be sort of an "in-line" definition - a subroutine definition
whose placement implies a call at that point, and which is also defined
later so:

  half-rabbit-ear a=e b=f c=g d=h

would become a shorthand for:

  together { vf e->f; mf g->h }

and would be read as "do that half-rabbit-ear again using _these_ points".

Forgive me for illustrating this point using my strawman notation, but
I think this is an important factor in getting non-computer types to
accept the whole idea.

By the way - non-computer-types who don't know what we are talking about
are specifically invited to ask whatever questions they want and venture
whatever opinions they wish.  This is to help _you_ too!  If I'm under-
estimating the acceptance of Baz's notation, say something, 'cause he's
right when he says it's easier!  I don't like advocating extra work.

>             sequential simple folds. We then invent the command
>             'fold' which acts on a comma separated list of
>             fold descriptions (descriptions of simple folds)
>             eg. f1,f2,f3 fold f4 fold
>             Where all folds up to the next 'fold' command are
>             done simultaneously. f1,f2,f3 might, for instance
>             be the parts of a squash fold, and f4 might be
>             a valley fold.

You're suggesting the ability to give any fold a name?  So:

a->b: f1
c->d: f2
together { f1; f2; mid->seam }: f3

would define two simple folds, and a third in terms of the two previous
folds, plus another simple step.  Yes, I like this.  To expand on the
above idea, these would expand "in-line", as if being executed at the
time they are defined, but would leave the fold defined for future
reference.  I thought about having the convention that fold commands on
separate lines mean sequential and on the same mean simulataneous, but
I think that using lexical conventions to denote that will make notes
hard to read and very error-prone.

We need to be able to use the above fold with parameter substitution,
or a computer would try to do the exact same fold again.  For people,
it might be:

f3 a=c-d-midpt b=e-f-midpt

which would change a to c-d-midpt and b to e-f-midpt (these would be
point names, not calculations) and leave c, d, mid and seam the same
as before.  By assuming any identifier could be a parameter, we avoid
forcing people to declare them.

>       d) ok, so we need some way of describing points and lines
>             (required by the last section). We'd also like if
>             possible to hide implementation details from the
>             user. One good way of doing this is to name points
>             (or lines, or groups of points). Note 'name' not number.
>             Half way through a 100 fold diagram you are likely
>             to have forgotten what point 13 was, but a name like
>             'head' 'beak' or 'nose' is easier to name.
>             We take it as granted that the original points (of,
>             usually, a square) are labelled (say,A,B,C,D) and then
>             label all other points by reference. e.g.

No question about the naming.  As for the initial points, I called them
ul, ll, ur, lr for upper left, lower left, upper right, and so on.  It would
be _nice_ if anyone who creates a fold in this language declare what the
points will be:

model sitting_cat head, r_hind, tail, l_hind

finished sitting_cat

>             (A) (B)   [2 points: is the line A->B ]
>             (A) (B) 0.5 section [ is the midpoint of AB ]

what I would call a->b/2

>             (A) (B) midpoint [its likely we'll want macros for useful stuff]

def a->b/2: midpoint

midpoint d f

"f3" is a "fold", midpoint just a macro (i.e. _not_ executed at time of
definition, just a notational convenience.  It occurs to me that someone just
folding and taking notes would record an entire fold, and then wish to be
able to just say "do _that_ again" later on, so I'm designing the syntax
suggestion above.  It requires less thinking ahead, less design.  Design is
good for software, but this is _art_!  ;)  Actually, with only one sheet of
paper, I don't think we will ever have to deal with the complexities that
software does, so why apply the nostrums we use to control it?

>At this point, we have got the beginnings of a nearly workable syntax.
>However, it is a syntax for doing simple things; I found it hard to
>express the meaning I wanted to make a preliminary fold using this
>( by folding along a diagonal and two squash folds, rather than
>collapsing a prefolded version as is usual )
>and I don't know how it could be used meaningfully to (eg) squash
>fold more than one layer together. Note that I've stayed within the
>80% and found a problem, since squash folding is used to make all of
>the simple bases (collapsing is even harder to describe!)

It's okay to use high-level primitives for such folds, Baz.  But let me
take a crack at it:

// start with a square sheet of paper
paper 1:1

// name the figure and define the corners
model waterbomb ul ll ur lr
  ll->ul    // implies lr->ur
  ll->ul/2->ul->ur/2  // fold
  // ...don't have time to finish this until next week, so I'll
  // take another crack at it later.  I'm falling behind in this
  // discussion!

>       We'd also like to have some 'symmetry' notation in the syntax,
>since we'll often want to say 'repeat behind', etc. However, I feel
>that this falls outside a first attempt, since anything that could be
>described this way could just be described by repeating commands.

I tend to agree, though defining particular folds may make the need
much less, since we can then just repeat them with the new points.

>2. Internal representation.
>In the syntax described above, points _appeared_ at the surface.
>(actually pointers to points). More detail is required to express
>the layering of polygons of paper. Here we should be thinking of
>asking Robert Lang if we could cannibalise his code - after all, it

I think that's a wizard idea.  Does anyone know him?

>descibed in Origami for the Connoisseur), since our 80% will
>almost certainly be restricted to flat models.

Actually, I'd be surprised if it did, though I agree that working
with flat models _for_now_ is not a bad way to get started.

>3. Display. It's probable that it will be decided to proceed
>with displaying polygons from back to front, rather than full,
>raytraced 3d. However, it should be pointed out that problems
>arise with this even in pureland origami.

I think this will "fall out" of whatever rendering package we
use.  It's only an issue if we "roll our own", and the last
thing we need is Yet Another Rendering Package.

>Take a strip of paper and fold it over at 90 degrees to its axis.
>repeat another 2 times, always folding 'up' .The result looks like:
> _______
>/_____| \
>| |   | |
>| | __|_|
>|A| Z___/
>
>The problem is what we do with end 'Z'. If it goes _over_ A then
>everythings fine; A is under Z, and under 2 other strips which are
>under Z. if Z goes _under_ A then A is over Z but under a strip
>which is under a strip which is under Z , so if we just printed
>polygons one after the other we would have a problem. An algorithm
>which wouldn't loop infinitely would probably place Z (wrongly) on top.

Z goes on top of A unless it is "tucked".  "A" is at layer 1, the first
fold puts the rest of the paper in layer 2, the second puts the rest at
layer 3 and the final one puts in at layer 4, which is higher than 1.
If we had folded the other way, we'd be at layer -3 and Z would be under
A.  I don't like numbers for layers, 'cause I hate negative numbers.  Any
ideas?

Tucking would probably be something like "tuck Z->A" or "tuck Z->A[2]" is
we need to specify the layer.  Or even "tuck Z->A[1.2]" if we need to
define a new layer by the act of tucking.

>we probably need full raytracing even on the simplest models.

Probably, but if we can snarf a public domain or copyleft package
I don't think it will be much of an issue.

>Another point to consider is something which isn't a problem (but could
>be percieved as one). Models which become 3d temporarily can still
>be diagrammed using this type of program even in its simplest form
>by making the folds during the 3d stage 'invisibly', jumping ahead
>a few stages by folds that would be difficult to really do. The original
>picture for the last stage before the '3d' part can be output in the
>format for some drawing program and adjusted, making the process easier.

I'm not sure what you mean, but the next parapgraph may reveal a
conceptualization difference.

>Also: I did not cover the commands to flip paper, magnify, rotate models
>in the syntax section. That was because they are actually irrelevant to
>the program: flipping paper just reverses the meaning of mountain and
>valley, it doesn't change what the model looks like internally. There

In a sense, it does, it reverses the numbering of the layers.  Here's
a question for non-computer origami types: do you think about reversing
the model, or are you conceptually doing the reverse _fold_ in your mind
and only turning the model over in order to gain access?  Is the model
really symmetrical, or do you conceive of it as front/back?

>4. Save format. This might seem a little odd, since we have already
>covered input and output; but I assumed at the start of the input
>section that we would have  a labelled square, armed and ready so to
>speak, without saying where this came from. I see no problem with
>supporting odd shapes of paper from the _start_, if there is some way

I see none with _rectangles_, but arbitrary shapes may be a little much.
I suggest just using  "paper 1:1.2" or something like that.

>Finally, implementation: there should be at least 2: a WYSIWIG
>logo-like interpreter: instead of showing a few stages of any

Maybe we can adapt TCL.  Looking back at my strawman notation, it seems
sort of TCLish to me (if you can excuse the pun) and it would be certainly
easier to adapt.

>model , it should show changes to the model as you type

Rather like wish does with a GUI.  You type tk-enhanced TCL into the
command window and watch your GUI get built in another.

>them. (If the implementation was a TIL as described here it would
>also be a good idea if the stack was visible in a window. )
>That's the designer end. At the viewer end, there should be
>a program to convert output to the format of some viewer
>(PostScript? or 3d-POV-ray format? doesnt matter)... intended
>to support a minimum hardware (you have a printer, or
>a graphics card better than a Hercules, is the minimum for
>using GS; this would probably do.)

>       Anyway, sorry to ramble on so.
>             I'd just like to generate comment.

This is good stuff.  Pardon my Mickey-mousing the example, but I'm sort
of under the gun to get a bunch of stuff done this week and next, so this
is strictly a lunchtime deal.

Regards,
Larry Smith
larrys@alpha.zk3.dec.com





Date: Wed, 30 Mar 94 12:35:52 AST
From: makaala647@aol.com
Subject: Kawasaki's Rose

Ok, Rub salt in my wounds, I've only been trying to do the rose from
Origami_for_the_Connoisseur since Valentines day. I can get to the step where
the four diagonals fold in and the little square in the  center of the paper
folds under and dissapears, but when I start to curve the Petals it promptly
turns into a black hole and sucks intself into a crumpled ball of dense
matter. And undoubtedly the number of these I've made is having an effect on
the orbits of other planets.
Could someone send me one so I could dissect it and see what I'm doing wrong?
Then maybe I could get to see how the lock on the bottom works.
Thanks
Matthew Sparks
13170 E. Annette St.
Moorpark, CA 93021





Date: Wed, 30 Mar 94 13:13:41 AST
From: LHODSDON@smith.smith.edu
Subject: Re: relative impurity

Rob:

Of course you don't _have_ to cut the ends off.  They can be quite
pretty if curled and/or split (and splitting is OK if you don't remove
anything!)!

Lisa





Date: Wed, 30 Mar 94 13:25:56 AST
From: Soylent Green <rhudson@yorkcol.edu>
Subject: Vortex

I would send you one, but when I fold it and attempt to disassemble it, it
promptly becomes translucent, alters its molecular density to zero, and turns
into a Soft-Shell Taco.  Then I eat it.

Rob, cansado, MUY cansado





Date: Wed, 30 Mar 94 13:36:46 AST
From: Joseph Wu <jwu@cs.ubc.ca>
Subject: Re: Kawasaki's Rose

On Wed, 30 Mar 1994 makaala647@aol.com wrote:

> Ok, Rub salt in my wounds, I've only been trying to do the rose from
> Origami_for_the_Connoisseur since Valentines day. I can get to the step where
> the four diagonals fold in and the little square in the  center of the paper
> folds under and dissapears, but when I start to curve the Petals it promptly
> turns into a black hole and sucks intself into a crumpled ball of dense
> matter. And undoubtedly the number of these I've made is having an effect on
> the orbits of other planets.
> Could someone send me one so I could dissect it and see what I'm doing wrong?
> Then maybe I could get to see how the lock on the bottom works.
> Thanks
> Matthew Sparks
> 13170 E. Annette St.
> Moorpark, CA 93021

Apologies for the salt! 8) I'll be willing to send a rose and a leaf base
to the first 10 people who ask for them. It might take a few days to get
it all ready, however. So, email me your address! I'll even throw in the
diagrams of my leaf base. In return, I'd like to receive some model that
you have folded: an original creation if you have it, or anything else
you'd be willing to show off! 8) I'll assume that Matthew Sparks and Rob
Hudson are the first two on the list, so that leaves 8 more roses to be
claimed.

A further note: The twist itself can be done much simpler if you do two
things.

1) Actually fold the diagonal lines from corner to corner of the paper
rather than from the corner of the paper to the corner of the tiny square
in the centre.

2) Once you are ready to twist, collapse the model into a waterbomb base
(a white one, assuming two-sided paper and that you want a coloured rose)
and spread it so that its points form an "X". Fold the closed edge of each
point over its adjacent crease line (the one that you precreased for the
twist) and then press the whole thing flat. The twist at the centre should
form "automagically".





Date: Wed, 30 Mar 94 14:22:46 AST
From: larrys@zk3.dec.com
Subject: Re: Vortex

>I would send you one, but when I fold it and attempt to disassemble it, it
>promptly becomes translucent, alters its molecular density to zero, and turns
>into a Soft-Shell Taco.  Then I eat it.

Say, I could _use_ a fold like that.  Can you post it in ODL???   :)

Regards,
Larry Smith
larrys@alpha.zk3.dec.com





Date: Wed, 30 Mar 94 15:53:23 AST
From: Joseph Wu <jwu@cs.ubc.ca>
Subject: Re: Stylized folds

On Tue, 29 Mar 1994, arien kismet del'tai wrote:

>       Preliminary rambling:  I think my tastes were
> shaped by the origami book from which I learned, Sakoda's
> _Modern Origami_ (which is now rather yellowed with age.
> However, I prefer his stylized works (three limbs and all
> :-) ) to most of Montroll's (although I must get his and
> Lang's _Origami Sea Life_), since to me the latter often
> seem crumpled rather than elegant in their efforts to be
> exact.  I've in mind the Brachiosaurus on the cover of
> _Prehistoric Origami_ as an example.

I would argue that you've just not seen any of these folded well, but
that's just my opinion! 8)

>       Folds I particularly like in MO are the pegasus
> (one of the ones I first learned to fold anywhere, anytime)
> from his eight-pointed star, the flying crane and Egyptian
> cat from the offset bird base, the fox and camel from the
> T-fold, and the monk from thw owl base.  (Hm, I can see
> upon looking over the book that I need to try some of
> these, like the standing crane, some more with foil paper.)
>       My question is, then, what books would you
> specifically recommend that have a similar style?

You'll definitely want to get _The_Flapping_Bird_, a collection of an
origami monthly that was published by Magic, Inc. I believe that the
Friends have it in their order list. It was edited by Samuel Randlett.

>       I know when I see the books themselves I can decide
> from the pictures, but in many cases I might have to
> mail-order.  I've primarily seen Fuse's (yay) and
> Montroll's books in the stores in the University District
> (but then, I haven't yet gone to one or two major Seattle
> stores that're out of the area), plus _Origami for the
> Connoisseur_ which overall I greatly enjoy.

If you really want to see a huge library of origami books, you should get
in touch with Phillip Yee in Seattle. In addition to his rather large
collection, he has also inherited the library of the late E.D. Sullivan.
You should be able to see almost anything there!





Date: Wed, 30 Mar 94 16:25:59 AST
From: Soylent Green <rhudson@yorkcol.edu>
Subject: split ends

I don't know.. splitting the ends is like tearing the paper.. even if it's not
really paper.  Curling. .well... maybe if you were to multiple-divide the
resulting strip into hundreds of tiny, tiny containers, it would be OK.. or,
maybe you could make a whole bunch and interweave them to make a tapestry?  The
extra bit could be like a flap for a huge modular project. (though it still
doesn't resolve the problem of the end-stars having those extra flaps)

-Rob, Modular Man





Date: Wed, 30 Mar 94 16:34:47 AST
From: Soylent Green <rhudson@yorkcol.edu>
Subject: Autobot?

Joseph:

While your in the process of explaining the old twist transformation, which I
have no problem with, could you perhaps try to describe the bottom lock, (not
the kind where you interweave the little flaps.. the GOOD one..

Rob





Date: Wed, 30 Mar 94 16:45:45 AST
From: Soylent Green <rhudson@yorkcol.edu>
Subject: Ori-tummy

Larry:

Sorry, but I never get around to unfolding the thing before it goes down the
hatch. (And what's left after that isn't really manipulable) :()

Rob, Orivulgar





Date: Wed, 30 Mar 94 16:55:16 AST
From: vedder@polyhedra.tiac.net (Vedder Wright)
Subject: Re: Newsgroup echo

>I agree with your comments.  It's just that I watched the recent RFD on
>rec.crafts.origami, and I feel that rec.crafts.paper would have got
>through.  To be sure, it might have proved unsatisfactory for
>discussing origami, but I don't think so.  My guess is that most people
>interested in paper are interested in origami, and vice versa, to an
>extent at least.

That certainly describes me. I am getting much more involved with origami,
thanks to this list and a few contacts I have made through it. However, I
was making geometric paper models for years before getting involved with
origami, and even ended up in a Master's program in polyhedra. This
exposure and exchange with a few list members has been very broadening and
fun.

I had not idea so many high-tech things were going on in this field.

Vedder

Vedder Wright
Internet Evangelist





Date: Wed, 30 Mar 94 17:22:51 AST
From: Joseph Wu <jwu@cs.ubc.ca>
Subject: Re: Autobot?

On Wed, 30 Mar 1994, Soylent Green wrote:

> While your in the process of explaining the old twist transformation, which I
> have no problem with, could you perhaps try to describe the bottom lock, (not
> the kind where you interweave the little flaps.. the GOOD one..

The lock on the bottom *IS* the kind where you interweave the little
flaps. However, you must push them in further while squeezing the sides of
the rose in so that half of each triangular flap is covered by the flap it
tucks under.





Date: Wed, 30 Mar 94 19:33:52 AST
From: SPARKER@U.WASHINGTON.EDU
Subject: Newsgroup

        I'm for a newsgroup, regardless of its name.  After being
        gone for 4 days and returning to 93 messages, only two of
        which were not from the list, I'm really for the group.
        I would no longer subscribe and could read the group when
        I wanted to.  I guess I'm at the point where I'd like email
        to be email.  I think the bit.listserv option would be the
        quickest to implement, but if you all are interested in
        pursuing the rec.arts option, I will support it as well.
        Just my two cents.

        Sue
        sparker@u.washington.edu





Date: Wed, 30 Mar 94 20:47:06 AST
From: hull@cs.uri.edu (Tom Hull)
Subject: RE: Conventioneers

Hellllo!

I'm planning to go to the convention. You betcha! I also plan on volunteering
to teach the following courses:

(1) on the mathematics of flat origamis
(2) teaching my new Bat fold!
(3) on creative origami design, possibly focusing on human figures.

And we'll see if I can think of anything else by then...

-------------------- Tom "doing it my way" Hull





Date: Thu, 31 Mar 94 00:40:06 AST
From: r.follmer@genie.geis.com
Subject: Miscellaneous stuff

Re FOCA office response.

I, too, agree that the office is probably in a turmoil.  The staff turnover
and new manager always cause problems with any organization regardless.
More so when a large number of volunteers are involved.

The 769-5635 phone number is the primary one with the secondary one being
769-5636.  The latter had some problems a short time back (I made five
calles to it and was not responded to).  That problem, according to Tony
Cheng has been repaired.

++++++

Thank you for the response to my questions of types of papers.  I do
appreciate it.  Now I have better knowledge of what is what.

++++++

Thanks also to the person ( I forgot the name) who suggested sending the
line to the listserver to send the correspondence in digest form.  It now
takes less than half the time to download the email.

++++++

I noticed that a lot of the email recently has been concerning two items
mainly.....the newsgroups on Usenet and secondly programming language.  I am
unable, due to a lack of knowledge, to fully understand what most of what it
is all about. ( I am not a programmer, and I also still do not understand
the intracacies (?) of internet and usenet.

With these items in my head, I would like to propose that two seperate
groups be formed somehow and the talking take place off this mailing.  Then
I would suggest that these two groups get together and return here with a
comprehensive proposal that the rest of us could look at and affirm as the
direction to go. This is not to say to anyone I dont like this and that, but
only to suggest that, to me, this is a lot of technical language that I do
not get anything out of, therefore does not interest me that much.  I do
honestly realize that a lot of effort is being put into it and is important.
Is there a way, or do others here feel that this could best be handled in
another manner, but yet still reap the rewards of all this downstream?
Please note that I am not angry, but suggesting and questioning, ok?  :)

Have a happy day.  :)

Bob





Date: Thu, 31 Mar 94 04:33:24 AST
From: dfisher@staff.cs.su.oz.au (David Fisher)
Subject: Computer Folding (80%) (origo)

Dear everybody,

My program is going to use a particular language which I am making up;
I don't have long to design it. I'll tell you what I come up with once
it is all worked out, but it won't be identical to the universal origami
language which has been talked about - this is unavoidable. Another
limitation is that the program I write will be for the computers at Sydney
University - using "X" and "libXg" - and not for PCs. If someone else wants
to use any of the ideas in a program for PCs, though, feel free ! Thank you
to Baz for your offer of help ... how would you feel about doing the PC
version ?

One thing I did not mention - the original idea was to have a program
which allowed either text or mouse input, or any combination. For
example, to say "valley fold from A to the midpoint of B and C",
the user could select the "valley" tool, click on A, enter "midpoint",
then click on B, then click on C, and the result would be the command :
"valley from A to midpoint(B,C)". Alternatively, the entire command
could have been typed without using the mouse at all. The "saved" format
would be identical to this input format.

There have been some very interesting ideas ! I will try and reply to
everyone one at a time. Most of it applies to what several people have
said, though. Here are my thoughts :

Brian: Re: representation of the faces in an origami model:

       I think the best way to represent an origami model is by using
       the 3D location of each point and a list of faces. Faces which
       are in the same plane are grouped together, and within each
       group there is a relationship between each pair of faces to
       indicate if one face is above the other face. For each edge
       of a face, there is a reference to the adjoining face, unless
       it is a raw edge. Note that each time a fold is done, existing
       faces are split into more faces.
       Thank you again for your offer of help !

       Re: a language resembling PostScript

       I must agree with Larry; I don't think "ease of programability"
       is more important than "ease of usability". The more intuitive
       (to a non-computer-programmer) the better.

       But mostly I think the ideas are great !

       A thought: all simple procedures given in an introductory book
       on origami should be able to be described in the language,
       without any modification. For example, the preliminary fold
       should be able to be described like this :
       diagonal valley fold (then unfold) followed by horizontal and
       a vertical mountain fold (then unfold) then collapse the result
       into a square shape. It would not appear like this in the
       language, but it should be possible to do the same steps.
       Otherwise, it seems a big imposition to the users to disallow
       "obvious" ways of doing folds.

       Question: how do you handle "simultaneous folds" in a program ??

Bruce: Having "unit folds" is the best thing to do - I agree ! It would
       be great if it was possible to define new ones, too. This means
       that the low-level operations would have to be enough to define
       whatever new operations are required.

Larry: Re: looking ahead to label points:

       I have been thinking more about the original problem I described
       (giving labels to as-yet-unlabelled points), and I think you are
       right - the user must "look ahead" and label points as they are
       created. A simple way to specify newly created points as they are
       created is as follows: each new fold will create several
       unlabelled points; for a valley fold, each of these will lie
       on a different edge. So, along with the fold, give the edges
       for each new label along with the label for that point. If a
       pleat fold is a primitive operation, some edges will have more
       than one newly-created unlabelled point; to specify which point
       a label on one of those edges is to be associated with a new
       label, just give a number as well as the edge eg. point 2 along
       edge(A,B).

       I have a solution to my original problem, though :
       assuming that you can select a point using a mouse, if the user
       selects an as-yet-unlabelled point, he/she can give it a label
       just then; and when the text output is produced, the labelling
       for that particular point will be outputed just after the point
       is created. Another problem is : what if, in order to label
       a point, other labels need to be created to specify it ? Either
       the user will be forced to specify all of these labels too,
       or the program would have to generate these labels.

       You said  - "The program [ie. the folding commands] _had_ to have
       been written down as notes _while_folding_the_model_ - probably
       _not_ done at the keyboard." This is true if the only possible
       input is text; but if mouse input is also allowed, it seems like
       a good idea to allow the user the freedom to explore designs.
       The advantage of this is that if someone suddenly decides that
       they have discovered a great new model, they would not need to
       backtrack and unfold the model so that they could write down the
       steps they took in getting there - the program has already
       recorded their every move, ready to re-play again any time. It
       would also make input of someone else's models (eg. origami
       masters with undiagrammed models) much easier to put into the
       language - it is much easier/faster to click on points on the
       screen than to try to work out which point is which all the time.

       Re: shape of the initial paper

       As well as allowing the user to specify the initial dimensions of
       the paper (width:height ratio), why not allow the user to create
       the initial shape by folding it ? The user could fold an
       equilateral triangle, and then say "restart with face(A,B,C)"
       (assuming that the folds made up until the current point have
       formed a triangle with edges AB, BC and AC). Any such face is
       guaranteed to be convex, and would cause no unusual problems with
       any implementation of a computer program. Initial shapes could
       easily be saved and re-used by other models. (For that matter,
       any stage of any other model could be used as the starting
       point for a new model).

Rona:  thank you for your encouraging words ! I would love to somehow
       take a look at Robert Lang's program ... sounds great !

Other: some other general points -
       In origami books, drawings of the various stages of a model are
       deliberately drawn to show what is going on in different layers.
       If a 3D model generated by a computer program is displayed "as-is",
       assuming zero-thickness paper, these aids-to-understanding would not
       appear. For example, looking at a preliminary base, the user
       would see a diamond shape with a line down the centre (or nothing,
       depending on how it was folded), and couldn't even tell how many
       layers there were. Rotating the model would reveal an identical-
       looking back side. To "unfold" the model slightly so that
       adjacent layers could be seen would usually introduce some
       curved surfaces into the model; easy to handle in real life,
       but not with a computer. Any thoughts ?

David Fisher





Date: Thu, 31 Mar 94 06:58:03 AST
From: Agnes Tomorrow <atom@u.washington.edu>
Subject: Re: Conventioneers

On Wed, 30 Mar 1994, Soylent Green wrote:

> Who's going to convention this year?

        Sigh...not me...this year, for the *first time*, the Brewster
Society National Convention will not be on the east coast, but in San
Francisco, so I have to take advantage of the fact and attend.  (FYI--
the Brewster Society is for collectors and artists of kaleidoscopes--
anyone interested in meeting me there?)  It is also June 10-12...
        When will the FOCA convention take a trip to the west coast for a
change?

Agnes Tomorrow
atom@u.washington.edu





Date: Thu, 31 Mar 94 09:20:31 AST
From: The Patient One <chupenr@minerva.cis.yale.edu>
Subject: Re: Conventioneers

Forgive me for having been on another planet, but I missed all the
information about the convention.  Is it in New York City, when is it, and
can I just register to go for one day only?  And how does one get the
registration materials?  I live in nearby New Haven (if it's in New York)
and can easily get there and back by train in a day, thus avoiding the
atrocious cost of accomodations in the city.

Penelope Chua   Biology Dept., Yale University   chupenr@minerva.cis.yale.edu





Date: Thu, 31 Mar 94 09:33:03 AST
From: larrys@zk3.dec.com
Subject: Re: Computer Folding (80%) (origo)

The point about _using_ an interactive program to fold is an interesting
one.  Will future origamists, like the writers of today, find their art
transformed into an entirely virtual one, with few models actually being
folded from real paper?  Would they _like_ that, or is the feel of the
paper as important as the shape into which it is folded?  Sort of rhetorical
questions, general musings are welcome.

Another idea about the computer: models can, in theory, be unfolded to
reveal their folding pattern, which is frequently highly modular and
repetitive in much the same manner as fractals, as shown in Folding the
Universe.  Here's a random, unbaked idea, which I wanted to toss up and
see if anyone thought we might make something of it: would it be useful
for the computer to be given this pattern as a starting point?  For
interactive non-directed folding, this is obviously impossible, but for
recording a fold in a compact manner, this might be useful.  It would
certainly label all useful points right at the start, but at the cost
of requiring a completed model to be unfolded before it can be recorded.
Maybe as an option?  Do origami authors do this routinely before trying
to diagram a fold?  Food for thought.

Larry Smith
larrys@alpha.zk3.dec.com





Date: Thu, 31 Mar 1994 10:25:38 -0400 (AST)
From: stamm@aol.COM
Subject: Re: 80% (origo), Conventioneers and Online Origami

Dear All,

Gee.  I didn't know that my request for help finding a universal file
format for graphics files for diagrams was going to evolve into a universal
origami language.  I would still like to solve the GIF problem as I just
finished "Online Origami Volume 2, Issue 2" last night and I hope to get it
in the 'lectronic pipe by this weekend.

Re: 80%
Are you discribing a origami MODELING language or a DESCRIPTIVE language?
The latter I would think would be much simpler.  A modeling language has to
model a piece of paper, whereas a descriptive language simply has to
describe each step and each could be broken into 3 parts: What does the
model look like before the step? (i.e. identify the significant points),
What to do in the step (action, i.e. Valley fold from top to bottom) and
finally what should it look like at the end of the step (i.e. you now have
a rectangle).  Then do the next step...

Re: Conventioneers
I plan to be at this year's convention and plan to bring my daughter
(Deborah).  I must admit after all these years I'm still a convention
VIRGIN!  This will be my first one (Be gentle please).  Actually I've only
met 3 other "serious" folders my whole life (Its lonely out here in Idaho
-- All the origami action seems east of the Mississippi -- sigh!).

Happy folding to all.
Tom "The Bewildered" Stamm





Date: Thu, 31 Mar 94 11:33:03 AST
From: Marc_Hache@MBnet.MB.CA (Marc Hache)
Subject: Jeremy Shafer's Nail Clippers and other models

Hi folks,

Just saw a copy of the 'Bay Area Rapid Folders' newsletter from their March
5th meeting. It has the following models diagrammed:

Geometric Origami Designs: Chris Palmer
Scorpion: Robert Lang
Nail Clippers: Jeremey Schafer (these are waaayyyyy cool. I think I might
               have to ingest mind altering substances before attempting.)
Hannah's Sun: Peter Engel. Very nice. Also a nice article to go along with
              it.
Palm Tree 2: Mark Turner

Back issues are available by mailing $1.50(U.S) per issue + $1(U.S) postage
and handling to:

Editor
Rapid Folders
Newsletter
632 Ellsworth St.
San Francisco
California, U.S.A.
94110

Make cheques payable to Mark Turner.

Higlights from past newsletters:
September: 'Buddha in front of a leaf"
October: 'Leafed Tree" by Mark Turner
November: 'Tarantula' (Unpublished) by Robert Lang
December: 'Men in the Moon' one by Peter Engel and another by Mark Turner
January: 'Octagon Star' by Chris Palmer
February: Heart Locket' by Gary Merrill Gross and 'Four Pointed Star' by Peter
     Engel/

Marc Hache





Date: Thu, 31 Mar 94 12:34:54 AST
From: GURKEWITZ@WCSUB.CTSTATEU.EDU
Subject: Re: Conventioneers

Re: cost of accomodations in the city

I think that Foca has arranged with Fit for use of their dormitories
during the convention, and the price is reasonable, at least that's
what they did last year

I'm going to the convention and will give a talk or two

Early childhood math and origami
Spike Ball
Origami Polyhedra exhibit of models from a book I'm working on
 with Bennett Arnstein

Rona Gurkewitz
gurkewitz@wcsub.ctstateu.edu





Date: Thu, 31 Mar 94 13:46:26 AST
From: Sheldon Ackerman <ackerman@dorsai.dorsai.org>
Subject: Re: Conventioneers

>
> Forgive me for having been on another planet, but I missed all the
> information about the convention.  Is it in New York City, when is it, and
> can I just register to go for one day only?  And how does one get the
> registration materials?  I live in nearby New Haven (if it's in New York)
> and can easily get there and back by train in a day, thus avoiding the
> atrocious cost of accomodations in the city.
>
This year's Friends' convention will be held at the Fashion Institute of
Technology in NY. The dates are from June 10-12. Their latest newsletter
says to call the Home-Office for more information. And again, the number is
(212) 769-5635 and their fax number is (212) 769-5668.

Sheldon Ackerman
ackerman@dorsai.dorsai.org





Date: Thu, 31 Mar 94 15:09:10 AST
From: Tak To <tto@aspentec.com>
Subject: re: description language (origo)

It appears to me that the kind of description language that is being proposed
right now might be unsuitable for a computer rendering program (which would
create a series of usable 3-D diagrams depicting various stages of the fold).
Specifically, a lot of useful information is missing and it might be hard
for the computer to fill in the gaps.  Take the viewing perspective for
example.  The model in various stages of the fold usually needs to be viewed
from different angles and it would be hard for a program to figure what is
the best view.  Another point is that different parts of the model have
to be unfolded slightly at various stages to make the 3-D structure more
obvious.  Again, these locations vary with the progress of the fold and it
is hard for the computer to figure out.

Thus, rather than a description language for the abstract geometric model of
a fold, we should perhaps design a description language for the series of
_diagrams_ themselves.

This is not to say that the language should describe just line drawings.
Rather, it should describe the 3-D object (which is the piece of paper) in
various stage of the fold (each with a specific viewing angle) as well as
the transitional information from one stage to the other.  Note that a
transition can be any of the following: one of more folds, change of the
viewing angle, adjustment of the one or more angles, etc.

It should also describe various meta-objects such as arrows, labels, etc.

To take one more step, we should perhaps let an interactive input program
generative the description.  (The input program should not be too different
from the the rendering program anyways.)  The description in that case
becomes a recording of how the diagrams are created.

(In this case issues such as automatic labeling of points become moot because
the author has to explicitly select the points himself every time.)

If a rendering program is a goal, we should really think more about the
diagrams rather than the model itself.

Just some thoughts from the side line.

Tak.

Tak To                                                    (617) 577-0310 x377
Box 45, MIT Branch PO, Cambridge, Ma 02139.                  tto@aspentec.com





Date: Thu, 31 Mar 94 15:19:36 AST
From: hull@cs.uri.edu (Tom Hull)
Subject: RE: The Convention

Howdy again!
     I believe regestering for the Convention works in the following way:
You have to be a member of the Friends. If you already are a member,
then regestration materials will be sent to you, probably in mid-April.
The Convention is held at New York Citiy's Fashion Institute of Technology
(FIT), and they reserve dorm rooms (which are right across the street)
for people. Last year the cost was $20 a night, which is GREAT for NYC.
Yes, they're dorm rooms, but since most everyone is there, it turns into
one big party. All night folding sessions are common. This was where I
learned Jeremy Schaffer's working Swiss Army Knife last year. (It had
a pivoting knife, can opener, awl, and screwdriver!)
     I HIGHLY recommend staying overnight on Saturday, at least.

-------------------- Tom "tickles" Hull





Date: Thu, 31 Mar 94 15:29:31 AST
From: base00!jhc@codas.attmail.com
Subject: OrigamiGo (origo)

As a computer type with good knowledge of C, C++, UNIX, MS-Windows, etc,
I'll be glad to help out in this programming effort.  I don't have
much to add at this time, as I have to sit and think about this project
first.  However, when it gets to putting it together, I think it would be
interesting to distribute the effort over the Internet, allowing several people
to design modules.  We could collaborate on the project without even meeting,
just do the whole thing in cyberspace.  I'm sure it's been done before.
If this sounds good, we should consider going to a less public forum, and
occassionally posting milestones to origami-l, so we don't burden everyone
else with technical discussions.

As far as a name, I think OrigamiGo is a perfect choice!  It is accurate in
Japanese, and catchy in English.  I've heard no dissenting votes, so I
vote for OrigamiGo, and suggest it be adopted as the working name unless
something else comes along.

I will add that we should make this language able to take advantage of new
technology.  Remember Virtual Reality is around the corner, and as someone
already mentioned on this list, there is now a mathematical model for
paper in virtual reality, which can be folded!  Being able to take advantage
of pointing devices such as mice would also be good.

-- Javier

 + jhc@codas.attmail.com            +  AT&T                               +
 + Javier Cubero                    +  Orlando, Florida                   +





Date: Thu, 31 Mar 94 15:39:00 AST
From: Brian Ewins <gapv64@udcf.gla.ac.uk>
Subject: Re: Computer Folding (80%) (origo)

Hi,
        when I saw 60 messages in my mailbox this morning I nearly
choked. Lot of interest in origami these days, it seems.

When I posted using a PS-like language, I din't mean to suggest
that we end up using one like that; I was using it mainly because
that's how I'd originally thought of writing it. I agree that
many people find postfix languages confusing (heck , I do too)
but usually this is because the functions have been named for
the infix equivalents, and not the natural language meaning
(e.g. PS has 1 2 add; more 'obvious' would be 1 2 added)
... just an opinion, I don't intend to push this any further.

Larry's letter:
'You're suggesting the ability to name a fold ?'
-actually I wasn't, I was going to stick with the conventional
'lets define functions at the start', but I think the ability
to define them as we go is a good idea. This 'after the fact'
naming seems like a natural way to express 'repeat behind', etc.
'a->b/2' yes, much better than what I'd said.
I should point out that in using ratios we are explicitly
avoiding reference to coordinates or a measured length of paper:
you don't use a ruler in origami, so why should the language
force you to?

You say it's ok to use high level primitives for such folds:
I take it you mean bases (I agree) and not collapses - 'collapsed'
models are usually all different, it would be next to impossible
to define a primitive for reducing all of these to a folded
form. This is also half the argument for not using the crease
pattern as the 'exchange format' as another writer suggests. The
other thing is that the creases need not necessarily define
a flat model, whereas the folded model is obviously flat.

I agree that we should be looking at using a 3rd party renderer
if it comes to that; but you seem to have misunderstood the problem
with the A-Z model. If I label the 4 sides of the square A,B,C,D
then they are, bottom to top, ABCD. But if D is 'tucked', then
D is under A. So D is at the bottom. But C is under D, etc. There
is no 'bottom' or 'top' layer. The solution is as suggested by
someone else, to split the polygons on all lines where they overlap.
We then have a pile of non-overlapping polygons and 2-d display
is simple.

On flipping reversing the numbering: it does so for display,
but what I meant was that there really _is_ no such thing
(intrinsically) as a front, or back, to a model. That depends purely
on which direction we are viewing it from, and so is part of
the display algorithm. Swapping the meaning of valley and mountain
is (in a programming sense) easier than renumbering the entire
polygon stack.

TCL would be fine I guess. Unfortunately, I haven't got a working
copy of wish and all the rest of the TCL things yet, or I could
make a more intelligent comment on how appropriate it would be.
- and yes, I groaned at the TCLish pun.(for non-computer geeks:
this is pronounced 'ticklish'). I'll see if I can grab it tonight
from the appropriate archive.

Tom Stamms letter:
Is this a model or descriptive language? Answer:both.
While the main intention is to write a language that can
be used to make images of a fold, in the interests of being
as widely usable as possible you should be able to write
folds down with it (and thus enter them into a computer).
If you can write it, you can read it too: someone seeing
a script in 'origamigo' or whatever should be able to fold
the model by reading it.

David Fisher's letter:
You ask how simultaneous folds are done in a program.
My approach was: mark the folds you wish to make, (using
your mouse based system) or list them , and then tell the
computer to start the fold. There are 2 things it can do
next; firstly, the equivalent of 'animating' the fold,
moving all parts simultaneously. This would almost certainly
be _very_ hard. Alternatively, it can add up the angles
at each vertex involved in the fold. Basically, if i change
from odd to even as I cross folds at a vertex, the odd
angles and even angles should separately add to 180 degrees.
If this works (to within machine tolerance) the model
is flat, and you can just move the polygons directly to
the places that they should end up.

Secondly, you ask if I'd like to do the PC version. Well,
yes and no. I don't have a compiler on the PC right now,
I had to ditch it when FAST came snooping round the Uni;
but I do have a compiler on the Unix box this mail is coming
from. I'd be happiest doing a version which was portable
to any machine: ie it takes the language & produces output
usable by printers (not just PS, but HPGL, bitmaps, etc I suppose)
and 3rd party viewers. I have an innate dislike of programs
that can't be used on any machine. I can get PC executables
made up for this tho' , and if you're using X stuff I can probably
build your program directly for Acorn Archimedes too
(Maarten might be interested in this, I think he has one...)

Finally you ask about showing layering. This doesn't need to
be done in a fully 3-d way; you just show extra edges. I don't
know how to describe this properly without a picture - all
I mean is an extra line along each edge where there is an extra
layer.

        cheers,
               Baz.





Date: Thu, 31 Mar 94 16:20:06 AST
From: larrys@zk3.dec.com
Subject: Re: description language (origo)

>It appears to me that the kind of description language that is being proposed
>right now might be unsuitable for a computer rendering program

This may be a valid point of view, but I suspect it's too early in the
game to call it.  I'd like to see some more ideas before we start picking
and choosing.  You may be right, but let's kick it around some more.

Larry Smith
larrys@alpha.zk3.dec.com





Date: Thu, 31 Mar 94 16:29:23 AST
From: Brian Ewins <gapv64@udcf.gla.ac.uk>
Subject: re: description language (origo)

Hi,
        This is pretty much what we are already describing,
but as I said in my letter where I described a fragment of
how such a language might be written, I actually pointed out
that while I hadn't covered commands for saying 'flip the paper'
'rotate drawing 45 degrees and magnify twice' -the things
which get the best viewing angle- these could be added in
later. They don't affect how a model is represented _internally_.
As an example: if I am looking at the head of an origami dog,
it remains an origami dog even if I turn it so I'm facing its
tail. I only specify the viewing angle when I come to make
a drawing.
        The thing about our 'origami language' is that it
will describe how to move between one 3D object and another:
a language which describes _co-ordinates_ for points in 3D space
(and _could_ be used to describe a series of 3D objects with
individual descriptions) is unnatural - you don't think about
origami that way.
        Programs for drawing 3-d objects from point coordinates
are 'easy' in the sense that this has been done dozens of times,
and we can get free programs to do this for us. The task at hand
is a natural-language description of origami, which has never
been done before.

        Cheers,
               Baz.
