edemaine / fold Goto Github PK
View Code? Open in Web Editor NEWFOLD file format for origami models, crease patterns, etc.
License: MIT License
FOLD file format for origami models, crease patterns, etc.
License: MIT License
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')}
Maybe instead of just returning the fold object, transformations like "collapse nearby vertices" should report what happened (how many collapses, etc.). Requested by Amanda.
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.
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.
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.
@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 eitherType 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.
@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.
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?
@estollnitz suggests removing redundancy from the various data structures in the spec. @origamimagiro's proposal is to split the spec into two parts:
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
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
.
Break the faces to resolve cyclic ordering.
FOLD requires faces to be split into subfaces for a few reasons:
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)
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.
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[];
};
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.
Challenging.
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.
@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 holesboundaries_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.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 useThe 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 cwfaces_edges
(optional) similarly becomes an array of array of edge indicesKey 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)?
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.
For now, just flipping through. In future, automatic animation?
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.
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.
Currently, Fold Viewer renders in orthographic projection. Tom Hull doesn't like it and requests a perspective projection option.
Here is the plan for adding curved crease support to FOLD (probably version 2) via NURBS, based on discussions with Jason, Amanda, Klara:
edges_controlPoints
field mapping each edge to a list of control points, each of which is a coordinate array.
null
if you want to just an edge as a line segment.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.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 ...
)edges_knotVector
is specified, the degree defaults to the knot-vector length minus the control-point-array length minus 1?.We should support rendering of vertices and edges that do not appear in any faces. Many applications for this:
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.
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.
Rotating view with one or two finger dragging
Should be relatively easy.
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)
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.