We should support rendering of vertices and edges that do not appear in any faces. Many applications for this:

• Debugging. Maybe you've just defined your vertex set so far, and want to make sure you got it right.
• Tutorial. I'm working on a tutorial document where it would similarly be nice to be able to show "what we've built so far" as we go step-by-step through defining FOLD attributes.
• Linkages. One 6.849 group is interested in rendering linkages using FOLD.
• Crease patterns. A common use case, I think, is that software generates vertices and edges defining a crease pattern, and then take it into the FOLD web software to add faces automatically. Before clicking that "add faces" button it'd be nice to see the skeleton of the crease pattern.

Jason, is this hard to add? I don't think we don't need to worry about edgeOrders; we just need to do the "obvious" partial ordering between vertices, edges, and faces. And this is probably only necessary for vertices and edges that aren't a part of any face.

@estollnitz suggests removing redundancy from the various data structures in the spec. @origamimagiro's proposal is to split the spec into two parts:

1. Storage spec minimal nonredundant options, ideally classified by classes. These would roughly match our recommendations.
2. Internal representation spec (somewhat JS specific, essentially #16, but adaptable to other object-oriented languages) which includes computable properties. We'd also want JS code that converts between them (as in #16).

FOLD requires faces to be split into subfaces for a few reasons:

• To specify face ordering information (two coplanar nonconvex faces can be ordered one way in one part and the other way in another part)
• To represent faces with holes

We want to keep track of these subfaces (faces in the FOLD structure) being part of a single intended/represented face ("superface"). The proposed simple way is to have a new edge assignment type, "J", for joined edge. F is an unfolded crease, and is meaningful from an origami perspective, whereas J edges are just for representation purposes.

Then we'll want a function that constructs the boundaries of a superface, by DFSing over J edges. Here we can get multiple boundaries, allowing for superfaces with holes. If the superface happens to be planar, we can characterize one as exterior and the others as holes. This effectively solves #21 in a simple way, so will likely replace #21.

Incidentally, J would be the natural assignment for triangulation edges in Origami Simulator (both for inputting manual triangulation and outputting with triangulation) — the equivalent of yellow lines in its SVG input format.

(discussion with @estollnitz, @origamimagiro, @amandaghassaei)

I think GitHub Pages and NPM are enough places to put the compiled JavaScript; the .js code doesn't need to be in the main repo.

However, GitHub Pages is currently published from the root repo, so this would require changing it to a branch with the compiled js.

Type definitions for the FOLD library would allow for static type checking as well as intellisense in code editors. This could be accomplished either by providing a .d.ts type definition file for the existing code, or by implementing FOLD in TypeScript.

I don't know enough about coffeescript to fix this myself, but there is an issue in lines 2/3 of https://github.com/edemaine/fold/blob/master/src/file.coffee

when I npm install the fold package in my project I get a file.js file that reads:
#!/usr/bin/node
;
var convert, file, fs, path;
....

which throws an error. Node sure if the backticks need to be on the same line or gone, but something is not happy.

• Given vertices and faces only -> edge connections
• Test whether these connections result in manifold, and set attribute accordingly.

Tessellatica has nice support for dashing creases, skipping near the corners, for input to a laser cutter. It would be nice to be able to do this with a FOLD file too. (Related, it would be nice to have FOLD import in Tessellatica, but it would still be nice to do this without needed Mathematica.) Similarly, we could imagine automatic generation of cut patterns for cutting metal, Jason's hinges, just trimming vertices for vinyl cutting, etc.

I'm not sure whether this makes sense as a separate tool or as mode of Fold Viewer, but I lean toward separate tool.

Sam Calisch wrote some Python software for this in his 6.849 project. This might be a good reference / starting point.

I created a FOLD viewer (https://github.com/innanyun/fold-viewer-threejs) using TypeScript and Three.js.

I created it because I wanted an easy-to-use viewer and maintainable reference implementation of the FOLD specification that can easily reflect the development of the specification. Many viewer-related issues such as "Perspective Projection" (#11), "Rendering just vertices and edges" (#10), "Touch events" (#1), etc. could be easily solved.

Break the faces to resolve cyclic ordering.

Just wanted to throw this out there to gauge a response:

Can we convert the src/ folder from coffee script into ES6 Javascript or Typescript?

This would be for the sole purpose of getting more code contributions from the community. If it resulted in no increase in contribution activity I would feel like I wasted everyone's time. Can we leave this issue open for a while, and if anyone has feelings about this would you like to leave a response?

1,300-1,700 lines of coffee script code, no tests to port.

@robbykraft points out that the following natural pairings of vertices, edges, and faces are currently not in the spec:

• vertices_edges
• edges_edges
• faces_faces

We should explicitly mention that we're omitting them, or define these, including how they should be ordered. edges_edges could be ordered by one vertex and then the other — unclear whether it's useful though. faces_faces should probably be edge adjacencies.

First of all, I would like to ask how the coordinates of the waterbomb model are calculated？Like this，

Another problem is that I want to build a model like the one shown below. Can this model be implemented in a FOLD file?This is a wheeled structure, I want to model it with a FOLD file and import it into the simulation software so that we can see where its structure can be improved.This structure is derived from the basic waterbomb structure.


I have read the courses and books on your homepage. Very interested in the origami algorithm. I hope to get your advice, thank you

Challenging.

On import, we'd like to be able to specify certain line types (thickness, color) to mountain/valley/fold angle/edge properties.

Also, should (optionally?) run FOLD.filter.subdivideCrossingEdges_vertices to subdivide crossing edges.

https://coauthor.csail.mit.edu/6.849-2017/m/t6WKN7X9s4ojA29PJ

Maybe instead of just returning the fold object, transformations like "collapse nearby vertices" should report what happened (how many collapses, etc.). Requested by Amanda.

@amandaghassaei points out that the current spec does not deal with holes in faces (without subdividing them somehow), e.g.

+-----+
|     |
| +-+ |
| | | |
| +-+ |
|     |
+-----+

We should extend the spec to handle this. The tricky part is doing so in a backwards-compatible way.

Proposal 1:

• faces_boundaries: for each face, list of boundaries, first of which is outside and rest are interior holes
• boundaries_vertices/edges: counterclockwise (?) order of vertices/edges for the boundary, similar to current faces_vertices/edges
• faces_vertices/edges: can still list all vertices/edges on boundary of face (union of face's boundaries), but order is no longer particularly useful.
• When no boundaries listed, assume each face is a single boundary and already in ccw order. So this makes everything backward-compatible: when not using holes, can use FOLD as is, but when dealing with holes, work with boundaries structures instead of faces_vertices/edges.
• frame_attributes of holey (?) and nonHoley (?) to specify whether boundaries are in use

The downside of this approach is unneeded complexity: boundaries don't really need to be first-class, because will generally be used by exactly one face.

Proposal 2:

• faces_vertices becomes an array of array of vertex indices, one array per boundary, where first boundary is exterior and ccw, and other boundaries are holes and cw
• faces_edges (optional) similarly becomes an array of array of edge indices

Key question for this approach: do we want v2 to allow both forms (each element of faces_vertices is an array of indices, or an array of array of indices), or just the hole-supporting form (each element of faces_vertices is an array of array of indices)?

Rotating view with one or two finger dragging

Here is the plan for adding curved crease support to FOLD (probably version 2) via NURBS, based on discussions with Jason, Amanda, Klara:

• A curved crease is a type of edge.
• By default, every edge is a straight segment connecting its endpoints.
• To override this behavior, you must specify an edges_controlPoints field mapping each edge to a list of control points, each of which is a coordinate array.
  • Put null if you want to just an edge as a line segment.
  • Issue: Do we allow a dictionary for just specifying the curved edges?
  • Issue: Does a control point array repeat the first and last control point which are the edge endpoints?
• By default, every spline is quadratic (right? or linear) and uniform. There are two parallel arrays for overriding this default behavior:
• edges_degree maps each edge to the degree of the curve (2 for quadratic, 3 for cubic, etc.)
• edges_knotVector maps each edge to a knot vector.
• If only edges_degree is specified for an edge, the knot vector defaults to uniform open (rational B-spline): [0, 0, ..., 0, 1, 2, 3, ..., m, m, ..., m] (for appropriate lengths of the ...)
• If only edges_knotVector is specified, the degree defaults to the knot-vector length minus the control-point-array length minus 1?.
• We provide a helper to fill in all the implied information (and maybe one to delete implied information).

• Crease pattern -> flat folding
• Crease pattern + fold-angle assignment -> 3D folding
• Reverse: unfolding flat/3D folding to crease pattern

These should be automatic to compute the geometry. Not yet handling faceOrder. (But in future, we should try to brute force.) But https://github.com/origamimagiro/flat-folder does this.

Should be relatively easy.

src/viewer.coffee:

  if view.opts.properties
    buttonDiv.innerHTML += ' Property:'
    view.properties = viewer.appendHTML(buttonDiv, 'select')
    view.data = viewer.appendHTML(buttonDiv, 'div', {
      style: 'width: 300; padding: 10px; overflow: auto; \
        border: 1px solid black; display: inline-block; white-space: nowrap;'})

Should add something along this line for when axisButtons isn't enabled, so buttonDiv isn't created

if (!view.opts.axisButtons) { buttonDiv = viewer.appendHTML(div, 'div')}

http://developer.rhino3d.com/guides/rhinopython/your-first-python-script-in-grasshopper/

https://discourse.mcneel.com/t/tutorial-creating-a-grasshopper-component-with-the-python-ghpy-compiler/38552

Just wondering where in the workflow texture/image could be introduced?

Ideally I would be folding an image in a particular way, less than a handful of distinct non-overlapping folds. So, not very complicated origami.

Obviously the image would have to be supported by the fold renderer, but perhaps it could be included as meta data. There would probably need to be both back and front images defined.

Thoughts appreciated.

I would find it helpful to add support for another assignment, "C", for inline cuts/slits, essentially doubled "B" lines. This is like green lines in Origami Simulator's SVG format. Then we should write converters between "B" representation and "C" representation.

Hello! Would you like a type definition for the FOLD format itself? This is not exactly #25 or #45, nothing to do with the API, only a type definition for a FOLD object. I imagine it could live inside of its own file, like fold.d.ts? Or, feel free to use it in any way you like!

I think this is valid for versions 1.2 and 1.1, but not 1.0.

The logic behind this structure arises from how a FOLD object can contain itself in file_frames. FOLD is the intended export. FOLDFrame is the intersection of the inner and top level frames, then the inner frames and top level frame contain inheritance info and file_ keys respectively.

fold.d.ts

type FOLDFrame = {
    frame_author?: string;
    frame_title?: string;
    frame_description?: string;
    frame_classes?: string[];
    frame_attributes?: string[];
    frame_unit?: string;
    vertices_coords?: [number, number][] | [number, number, number][];
    vertices_vertices?: number[][];
    vertices_edges?: number[][];
    vertices_faces?: (number | null | undefined)[][];
    edges_vertices?: [number, number][];
    edges_faces?: (number | null | undefined)[][];
    edges_assignment?: string[];
    edges_foldAngle?: number[];
    edges_length?: number[];
    faces_vertices?: number[][];
    faces_edges?: number[][];
    faces_faces?: (number | null | undefined)[][];
    faceOrders?: [number, number, number][];
    edgeOrders?: [number, number, number][];
};

type FOLDChildFrame = FOLDFrame & {
    frame_parent?: number;
    frame_inherit?: boolean;
};

type FOLD = FOLDFrame & {
    file_spec?: number;
    file_creator?: string;
    file_author?: string;
    file_title?: string;
    file_description?: string;
    file_classes?: string[];
    file_frames?: FOLDChildFrame[];
};

@origamimagiro suggests organizing the classes into a hierarchy, where any child implies all descendants.

• orientable should be a child of manifold, so orientable automatically implies manifold
• 2D and 3D could be under concrete (parallel to abstract), which is then implied by either

Currently, Fold Viewer renders in orthographic projection. Tom Hull doesn't like it and requests a perspective projection option.

From the spec:

faces_vertices and faces_edges should align in start so that faces_edges[f][i] is the edge connecting faces_vertices[f][i] and faces_vertices[f][(i+1)%d] where d is the degree of face f.

The diagonal-cp and diagonal-folded examples violate this rule; these are the only examples which contain faces_edges. They say they were created with Crease Pattern Editor, so maybe this is a bug in that tool?

For now, just flipping through. In future, automatic animation?

• Checking developability of 3D folded state
• Checking belcastro-Hull property at each vertex (given just crease pattern + fold-angle assignment / embedding from #3)
• Checking face intersection / faceOrders (taco-taco etc.)

When programming, it's really useful for vertices/edge/faces to be represented by objects with properties, and pointers to related objects instead of integer indices. The viewer essentially builds such a data structure. We should provide conversions between the file-format representation and this pointer-based representation. The names of everything should be clear from the FOLD names.

(discussion with Jason)

filter.cutEdges's argument should default to filter.edgesAssigned('C') to work with FOLD 1.2 spec of "C" edges. Also should define filter.cutEdges and filter.joinEdges.