You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@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)?
The text was updated successfully, but these errors were encountered:
Update on this topic: FOLD 1.2 supports "J" assignment for join edges, which is one way to represent holes (subdividing holey faces into simply connected faces).
@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 currentfaces_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 withboundaries
structures instead offaces_vertices
/edges
.frame_attributes
ofholey
(?) andnonHoley
(?) 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 offaces_vertices
is an array of array of indices)?The text was updated successfully, but these errors were encountered: