Embed Size (px)
Citation preview
Knitting Skeletons: A Computer-Aided Design Toolfor Shaping and Patterning of Knitted Garments
Alexandre KasparMIT CSAIL
Cambridge, MA, [email protected]
Liane MakaturaMIT CSAIL
Cambridge, MA, [email protected]
Wojciech MatusikMIT CSAIL
Cambridge, MA, [email protected]
Figure 1: Samples of knitted garments designed and customized with our tool, and fabricated on a wholegarment industrialknitting machine. (A) Various garment prototypes on a 12 inch mannequin; (B) a glove with lace patterns on its palms; (C) aninfinity scarf with noisy lace patterns; and (D) a sock with a ribbed cuff.
ABSTRACTThis work presents a novel interactive system for simple gar-ment composition and surface patterning. Our approach makesit easier for casual users to customize machine-knitted gar-ments, while enabling more advanced users to design theirown composable templates. Our tool combines ideas fromCAD software and image editing: it allows the compositionof (1) parametric knitted primitives, and (2) stitch patternlayers with different resampling behaviours. By leveragingthe regularity of our primitives, our tool enables interactivecustomization with automated layout and real-time patterningfeedback. We show a variety of garments and patterns createdwith our tool, and highlight our ability to transfer shape andpattern customizations between users.
Author KeywordsComputerized Knitting; CAD; Shaping; Patterning
CCS Concepts•Applied computing → Computer-aided manufacturing;•Computing methodologies→ Graphics systems and inter-faces;
INTRODUCTIONRecent advances in textile manufacturing are poised to revolu-tionize our everyday garments [20], communication capabil-ities [22], and possibly even our health monitoring [15, 22].The maker community has also found various applications fortextiles in additive manufacturing [23, 34, 7], made ingenu-ous uses of programmable textiles [1, 19], and created novelprocesses [18] and low-cost machines that target industrialtextile manufacturing [24, 35, 25]. This work is specificallyinterested in whole-garment knitting using industrial knittingmachines [27, 29], which provide digital control over eachsingle loop of yarn being created, while requiring minimaluser intervention during the manufacturing process.
1
arX
iv:1
904.
0568
1v2
[cs
.HC
] 3
1 Ju
l 201
9
Figure 2: Left: the base stitch unit in black, its course con-nections in purple, and its wale ones in orange. One can thinkof courses as "rows" and wales as "columns". Middle: widthincrease by split stitch. Right: width decrease by mergingneighboring stitches using move transfers.
These machines are capable of creating whole garments withfull customization, but unfortunately their programming iscomplicated and requires skilled experts. Low-level machineprograms are typically represented as colored needle-time im-ages (Figure 8) whose pixels are per-needle operations thatget compiled into machine instructions. Existing commer-cial softwares also provide garment templates with a set ofcustomizable properties (width, length, etc.) for predefinedshapes (such as gloves, hats, or sweatshirts). However, tem-plate parameters only modify the garment geometry (knownas shaping); the surface texture and appearance (known aspatterning) must be modified through separate tools, or bymanipulating the local instructions generated from the tem-plate [27].
Our system unifies and simplifies these existing approacheswithin a single workflow, while trying to alleviate two of theiroriginal limitations: (1) existing templates cannot be com-posed, which limits their potential to a fixed set of predefinedshapes, and (2) these templates lack a bidirectional decouplingbetween shaping and patterning, so any alteration of shapeparameters requires recreating the associated patterns.
We propose an interactive system to compose parameterizedknitting primitives similar to knitting templates, while ensur-ing knittability and allowing continuous user customizationof both garment shape and patterns. The contributions of ourwork include:
• A web interface for creating and customizing knitting tem-plates for everyday garments
• A domain specific language for patterning
• A novel layered pattern representation with different resam-pling behaviours for decoupling shapes and patterns
Furthermore, we release our web interface and its source codeto allow the democratization of computer-aided knitting. Seethe project page: http://knitskel.csail.mit.edu.
BACKGROUND AND RELATED WORKWe begin with a brief overview of knitted fabric and the mech-anisms of the knitting machine we use to create it.
The smallest unit of knitted fabric is a stitch (as illustrated inFigure 2). Typically, a stitch is created by pulling a yarn loopthrough a pre-existing stitch; this new loop is later stabilized
Figure 3: Illustrations of important components of a V-bedknitting machine. Top-left: needle beds holding a tubular struc-ture of yarn across both sides. Bottom-left: a correspondingtop diagram. Right: example of that top diagram as part of ourneedle bed visualization.
by having another stitch pulled through it. The neighborhoodof each stitch defines the local topology of the fabric, and mustfulfill certain criteria to prevent the fabric from unravelling.In this work, we refer to rows of stitches as courses, andcolumns as wales. Every stitch has two course neighbors,except when the yarn starts and ends. Regular stitches alsohave two wale neighbors: the preceding stitch it was pulledthrough, and the subsequent one that stabilizes it. However,irregular stitches have more or fewer wale connections due toincreases, decreases, or the yarn’s start and end.
Our system is targeted at knitting garments on weft knittingmachines. In particular, we target V-bed machines1, whichconsist of two parallel beds of stitch needles, angled towardeach other in an inverted V shape. Individual needles can holdmultiple loops of yarn in their hook, as illustrated in Figure 3.They can be actuated as one or multiple carriers bring yarnover the beds. The main per-needle operations include knitwhich pulls a loop of yarn through the current ones, tuck whichadds an open loop in the needle hook, and miss which movesthe yarn without triggering the needle operation. Furthermore,each needle on a given bed has a counterpart that is directlyacross the gap, on the opposing bed; these needle pairs canperform a loop transfer, which moves a loop from one bed tothe other. Although the needle positions are fixed within eachbed, the lateral offset between the two beds (known as racking)can be manipulated. Thus, the counterpart of a given needlecan change. By combining racking and transfers, loops areable to move laterally along the beds. For a detailed review ofhow these machines work, we refer the reader to the knittingreference by Spencer [28], the thesis of Underwood [31], andthe algorithmic review of McCann et al. [16].
Knitting As A ServiceCurrent industrial knitting machines are expensive. Althoughmaker projects have attempted to create low-cost versions [24,25], we still would not expect users to own such machines be-cause they require expertise to operate. Just as manufacturing-grade 3D printing is generally not done at home but througha 3D printing service2, this work follows a recent vision of1This work uses a Shima Seiki SWG091N2 with 15-gauge needles.2 See https://www.shapeways.com/.
2
(a) Full time-needle bed layout (b) Compacted layout for local editing (c) Zoom on local yarn pattern
Figure 4: The time-needle bed depicts the knitting process over time. We provide a compact version that collapses suspendedstitches to allow a local composition of primitives instead of the traditional composition over time. By zooming on the layout, wecan inspect the local patterning operations and the simulated pattern flow. Finally, the user can view either side of the garment.
knitting as a service3, in which users send their knitting jobsto a company, which then ships back their customized knittedproduct. This requires a means for the user to specify theircustom-made garment, which motivates our work.
Knitting 3D MeshesSeveral early works have tackled the problem of converting a3D mesh to hand knitting instructions such as for plushes [9,10]. More recently, Narayanan et al. [17] tackled the automaticmachine knitting of 3D meshes, and posited a theoreticaldescription of machine knittable structures 4. This descriptionmotivates our shape skeleton.
We avoid the external 3D modeling step, by building a CADsystem for whole garment knitting in the traditional sense,where we assume modeling is done from scratch. The firstmotivation is that the primitives for garment knitting are lessvarious than the diversity of topologies that can be representedby general 3D meshes. The second reason is that surfacepatterning requires specifying knitting patterns on top of theshape. Texture mapping could allow this on meshes, but itintroduces several unnecessary challenges [39] and tightlycouples the pattern with the shape. Instead, we seek to decou-ple shape from pattern; thus, we use a novel layered patternrepresentation for general graphs.
Shaping PrimitivesMcCann et al. [16] built a similar CAD-like approach, witha language and algorithm for the machine knitting of generaltubular shapes. One of their contributions was the time-needlebed visualization (see Figure 4), which we build upon. Theyalso introduced machine knitting building blocks (e.g. sheets,tubes, short rows), which are manually instantiated onto thetime-needle bed. Our system uses similar building blocks, butprovides automatic bed layout. Additionally, we tackle theproblem of surface pattern customization while allowing thecontinuous editing of both shape and pattern.
3 See https://ministryofsupply.com/, https://unless.me/.4Note that machine knittability, which we require, is more constrain-ing than hand knittability.
Modeling Garments and PatternsMultiple works have looked at modeling the garment makingprocess. Sensitive Couture [30] tackles the specification ofsewing patterns for woven structures. Other works focus onmodeling the yarn directly on top of specialized structuressuch as stitch meshes, with applications in realistic rendering[11, 38]. More recently, these have been translated to handknittable structures [36, 37]. We build upon a similar stitch unitas theirs, but do not use 3D meshes. Instead, we use a multi-layered 2D embedding that enforces machine knittability andallows pattern design similarly to image editing. This allowsus to reuse the plethora of manually-codified pattern recipes [6,4], as well as those directly inferred from images [12].
Parametric DesignOur system takes inspiration from traditional CAD softwares,together with novel systems that they have inspired. Oneexample is Robogami [26], which combines custom-maderobot components for easy fabrication. Similarly to the shape-and volume-authoring tools Antimony [13] and Foundry [33],we use composable primitives, and a pattern representationbased on short function expressions that can be modified bythe user.
Domain Specific LanguageVarious Domain Specific Languages have been designed totackle dedicated problems, such as shade trees [5] for ren-dering, or Lindenmayer systems [21] for generating complexstructures. More recently, the Knitout language [16] proposesa set of low-level instructions and a compiler dedicated tomaking machine knitting independent from the machine target.Another recent set of instructions [12] targets machine knittingof patterns. We introduce a patterning DSL that employs thislast instruction set within a two-stage process (select + apply)inspired by the dataset visualization language, D3.js [2].
KNITTING SKELETON OVERVIEWIn this section, we present a typical workflow session, and thenelaborate on several individual components and features of oursystem. The following sections detail the shaping primitivesand patterning DSL, before discussing our user feedback andresults. For interactive sessions, please see the project page.
3
index finger
middle finger
ring finger
pinky
4-fingers palm
thumb
palm cuff
Figure 5: Sideways view of a compact glove in our system.The underlying skeleton graph is highlighted on top, withtubular sheet nodes in blue and split nodes in fuchsia.
Typical WorkflowOur user starts from a base shape primitive (flat or tubularsheet) and modifies its shape parameters (e.g. size, layout,seams) by interactively manipulating them on the time-needlebed (Figure 4, detailed below). These interactions includedragging primitive boundaries for sizing, as well as dragginglayout elements to change their location.
The user can also use a contextual menu to directly edit allexposed properties. In the global context (no shape selected),users can create new shapes and define user parameters (suchas a glove’s base finger length). While hovering over a shapeprimitive, users can rename it, delete it, or edit any of itsproperties. Finally, by clicking on a shape boundary (called aninterface), the user can "extend" the given shape by connectingit to an available interface with valid matching parameters, orby creating a new primitive (which will automatically connectto the selected interface, and assume matching parameters).
After creating the desired shape, the user switches to the pat-tern editing mode, where the toolbar actions affect individualstitches. In this mode, the user can either (1) draw the desiredpattern directly onto a shape primitive, similarly to a pixelediting program, or (2) write pattern programs using our DSLin an editor. As the user zooms in/out, we display varyinglevels of information, including the type of pattern operation,and the local yarn topology (course and wale connections).
Finally, the user can visualize the yarn structure with a forcelayout tool, save the resulting skeleton, load a new one, orinspect and export the necessary machine code.
Shape SkeletonThe recent work of Narayanan et al. [17] showed that anyshape whose skeleton can be drawn on a plane without self-intersection can be machine knitted. This motivates our under-lying shape representation, which is a skeleton graph whosenodes are shape primitives, and edges are connections betweennode interfaces, as illustrated in Figure 5. The garment shapeis defined by the node types, connections and parameters. Thefinal surface pattern is defined by pattern layers associatedwith each node, and applied on the stitches locally. Together,these produce the final knitted structure.
By construction, our shape primitives allow for a continuousyarn path within each node and across interfaces, thus ensur-ing knittable skeletons. However, issues can still arise since
Figure 6: Warnings regarding a long-term dependency thatwould collapse the yarn (left). By highlighting the conflictdependencies, the user can more easily fix the pattern (right).
(1) shape parameters across interfaces may be in conflict (e.g.different widths), and (2) user patterns may produce unsoundstructures or put excessive stress on the yarn. We identify suchproblems, but we do not fix them, because there is typicallyno “correct” solution without knowing the user’s intention. In-stead, we issue warnings (detailed later), and let the resolutionto the user.
Time-Needle BedThe main visualization onto which the shape skeleton is com-posed is the time-needle bed. This is a common representationfor machine knitting [27, 16], illustrated in Figure 4. Theactual bed layout is automatically computed as the user ex-tends or modifies the underlying skeleton. This representationhas two advantages: (1) it directly shows the time processfollowed by the knitting machine, which allows us to produceinterpretable warnings if the user creates undesirable knittingstructures (see Figure 6), and (2) it introduces a grid regularity,which allows the user to draw complex patterns in a mannersimilar to layered image editing.
Yarn Interpretation and SimulationOur system interprets the yarn path through time to providewarnings and errors to the user as they create their shape andcombine patterns, as shown in Figure 6. The main issues wecatch are (1) unsafe yarn tension prone to yarn breakage, (2)too many yarn loops on a needle, risking pile-up or failedoperation, and (3) reverse stitches when the opposite bed isoccupied (e.g. in full-gauge tubular knitting). We providefeedback both textually with the types of issue and potentialfixes, and visually by highlighting the problematic stitchestogether with their conflict dependencies.
We also provide a force-layout graph simulation [32] as anapproximate preview of the yarn deformation after knitting, asillustrated for a glove in Figure 7.
Low-Level Machine CodeFinally, we provide a view to inspect the low-level code thatis generated for the current layout, as illustrated in Figure 8.This allows experienced designers and machine operators toinspect the actual program used by the machine.
4
Figure 7: Force-layout simulation to preview the impact of theyarn stress forces on the final shape.
Figure 8: Part of the low-level instructions for a simplifiedversion of the glove, to be processed with KnitPaint [27]. Thex axis corresponds to the needle bed. The y axis correspondsto time. The center shows individual machine instructions,and the sides include various options.
SHAPING PRIMITIVESEach of our three knitting primitives (Sheet, Joint, and Split)play a specific role in the garment’s final shape. We detaileach primitive and its properties, then provide more details onour skeleton editing paradigm.
As skeleton nodes, all primitives have a name (for visualiza-tion and pattern references), a pattern, and a gauge, whichwe detail in the next section. All nodes also define a set ofinterfaces which can be connected to other nodes.
Sheet / TubeThe Sheet primitive is the base component for knitting any flator tubular structure. Its two main parameters are its length,defining the number of courses making up the sheet, and itswidth, defined over the length. While the default configura-tion is a regular rectangle (sheet) or cylinder (tube), users cancreate more interesting shape profiles through stitch increases
and decreases (illustrated in Figure 2). These modulate thenumber of stitches on consecutive courses, in order to growand/or reduce the shape over the bed. At a high-level, the usercan modulate the width as a piecewise linear function overthe normalized length interval [0;1], yielding non-rectangularprofiles. If desired, the user can also customize the stitch-level shaping behavior (i.e. placement of stitch increases anddecreases) using one of multiple predefined behaviours, or auser-provided function that specifies how to allocate wale con-nections when changing the course width. We provide detailsfor these functions in the supplementary material, includingexamples of how the shaping behaviour affects the appearanceof the yarn with the location of seams. The primitive layoutcan be customized by choosing a specific alignment, whichimpacts both the bed layout and the yarn stress distribution.This primitive has two interfaces: the top and the bottom.
width
length
Property ValuesType Flat, TubularLength IntegerWidth [0;1]→ R>0Shaping Uniform, Sides,
Left, Right,Center, Custom
Alignment Left, Right,Center
Bottom InterfaceTop Interface
Figure 9: A tubular sheet, and the table of its properties
JointOur Joint primitive captures the second shaping process, calledshort rows, which only knit across a subsection of the currentcourse, while suspending the other stitches. These partialrows induce bending in the structure, as in a sock heel. AJoint represents a collection of such short rows. The user canspecify the number of short rows, the width of each, andtheir respective alignment. Users can also specify a layout,which controls the normalized location of short rows along theinterface boundaries, i.e. their offset for flat knitting, or therotation for tubular knitting. The interfaces are the same as forthe Sheet primitive.
rows
Property ValuesRows IntegerWidth [0;1]→ R>0Layout [0;1] or "auto"Alignment Left, Right,
Center
Bottom InterfaceTop Interface
Figure 10: Joint primitive as the heel of a sock, and the tableof its properties
5
Split / MergeFinally, our Split primitive allows for more complicated struc-tures (like gloves) that require topological branching and/ormerging. It merely consists of a base interface and a set ofbranch interfaces. It has a branching degree together with abranch layout. For automatic layouts, the user can also pro-vide the branch alignment. Furthermore, for tubular bases,the branching can be folded (tubular branches) or not (flatbranches) as illustrated in Figure 12. Flat bases only allowflat branches. Finally, since the interface connections are notrestricted in any direction, this primitive can be used both tosubdivide an interface or to merge multiple interfaces.
degree=2 Property ValuesDegree IntegerLayout [0;1]d or "auto"Alignment Uniform,
Left, Right,Center
Folded True or False
Base InterfaceBranches List[Interface]
Figure 11: Split primitive between one sheet branching intotwo, and the table of its properties
Editing Primitive ParametersOur system allows multiple interaction strategies. One canwork exclusively with the abstract skeleton graph, and editparameters using a tabular inspection panel. Alternatively, onecan drag the mouse to interactively extend the shapes on thebed layout. In this approach, more complicated parameterscan be specified using the contextual menu that allows thesame fine-grained control as the tabular parameter panel.
When specifying parameters through the input panel or thecontextual menu, the user can enter either direct numbers,or #expressions that introduce global design parameters.These are global variables that can be reused across differentinputs and node parameters, providing a means to exposeimportant design parameters (such as a glove’s width or lengthscale). For example, the user could specify the length of aglove finger via (#Len + #LenDelta) which introduces twoparameters, #Len and #LenDelta. Each of these could beindependently applied for the other finger specifications, andany changes to the variable value would be reflected globally.These expressions can also refer to node properties with @prop.For example, the width of a sheet could be made equal to itslength using the expression @length.
PATTERNINGGiven a shape skeleton, our system assembles stitches for eachof its nodes, and then merges stitch information at the inter-faces, producing a stitch graph whose nodes are individualstitch units (see Figure 2). Initially, the stitch connections(course and wale) are defined by the shape primitives. Eachstitch also includes a pattern operation that describes how tomodify the stitch with respect to its surrounding neighborhood.
(a) Tubular branchesFolded = True
(b) Flat branchesFolded = False
Figure 12: Diagram illustrating the difference between foldedand non-folded splits for a tubular base across the two needlebeds. The two branches are highlighted with different colors.
(a) Knit (b) Purl (c) Tuck
(d) Miss (e) Move (f) Cross
Figure 13: The different stitch operations with 8×8 patternillustrations, both as a diagram and a knitted artifact.
These operations allow the user to design special surface tex-tures and appearance on top of the shape.
Pattern OperationsFor the pattern operations of each stitch, we use the instructionset of Kaspar et al. [12]. The main difference is that we applythose instructions not on a one-sided regular grid, but on thestitch graph, which is then projected back to the time-needlebed to generate the final low-level machine code. Figure 13illustrates the types of pattern operations we support.
Importantly, our pattern operations do not create or deletestitch units. Instead, they modify how individual units are in-terpreted, either by providing a different operation to the targetneedle (purl or tuck instead of the default knit), or by alteringthe wale connections (miss, move and cross). In the case ofmiss, any previous wale connections of the missed stitch are
6
Category Methods ExplanationFiltering all(), filter(pred) Stitches that match a logic predicate
Sets or(x,y), and(x,y), minus(x,y), inverse() Standard operations on sets of stitchesIndexed wales(rng), courses(rng), select(c, w) Indexed stitches within a range
Neighborhood neighbors(rng), boundaries() Stitches at some distance from selectionNamed named(), shape(name), itf(name) Stitches located by a named entity
Masking stretch(grid), tile(grid), img(src) Stitches that match a given grid mask
Table 1: Our categories of pattern queries with their main methods and usage explanation
transferred to the subsequent one. Move and cross operationschange the subsequent wale connection to a neighboring onealong the next course.
If a neighboring wale target does not exist (e.g. at the borderof a flat sheet), then the operation is not applied. Note thatcourses of tubular sheets are treated as cyclic, so a neighboringwale connection always exists (possibly on the other bed). Thesystem ignores move and cross operations on irregular stitches(increase/decrease) to ensure structural soundness.
Patterning DSLTo apply pattern operations on the stitch graph, we designeda domain specific language in which the user first specifies asubset of stitches of interest – the query – onto which theycan apply a given patterning operation.
Our types of queries are listed in Table 1, and a subset is illus-trated in Figure 14. The main query is filter, on which allother queries are based (with some specialized implementa-tions to improve speed).
Drawing LayersAll our patterns are synthesized using our DSL. We split thepattern specification into a sequence of layers: (1) an initialglobal layer spanning all stitches, (2) varying sequences ofper-node layers modifying stitches of specific nodes, and (3)a final global layer. By default, all base layers are empty andwe assume the base pattern is a standard knit stitch.
Users can write their own program, use pre-existing ones, orinteractively draw node pattern layers in a manner similar toimage editing softwares that allow pixel-level modifications.We preview the impact of the patterns on the wales, as illus-trated in the right of Figures 4 and 6, where move operationsdisplace the upper wale targets.
Our pattern layers can be exported, imported and resampledfor different shapes and sizes. The resampling behaviour canbe specified by using different types of layers. We providethree pattern drawing types – singular, scalable and tileable– whose behaviours are illustrated in Figure 15.
Singular LayersThis is our default drawing mode, which does not resamplethe initial pattern, but simply modifies its location to accountfor the change in size (e.g., by centering the original pattern).
Scalable LayersThese layers resample their pattern by nearest neighbor resiz-ing. In this mode, we do not allow cross operations, which are
Initial Range of wales . . . of courses
Area select Union neighbor
img mask tile mask Filter with noise
Figure 14: Illustrations of some of the main pattern queries,each highlighted on a 30×30 flat sheet.
coupled in paired groups and typically applied with a limitedlocal range constraint to prevent yarn breakage.
Tileable LayersThese layers resample their pattern by applying a modulooperation so as to create a tiling of the original pattern.
From Drawings to ProgramsDrawings are stored as semi-regular grids of operations, whichcan be empty (for no operation, the default). To apply thedrawing, we transform it into a basic program that makesuse of the drawing data together with a resampling functiondepending on the type of layer. Singular layers relocate thedrawing information, whereas scalable and tileable layers usethe stretch and tile functions, respectively.
Half-Gauge KnittingFor each primitive, the user can choose a desired gauge (ei-ther full or half ). This property is important because patternoperations that modify the side of the stitch operation (regular
7
(a) Pattern (b) Singular behaviour (c) Scalable behaviour (d) Tileable behaviour
Figure 15: A base 3×3 pattern and the different resampling behaviours of each of our layer types.
(a) Tubular in full gauge.width = 10
(b) Tubular in half gauge.width = 5
Figure 16: Illustration of the gauge parameter. The width ismodified to keep the same bed support. The half-gauge variantuses different offsets between beds to allow reverse stitches.
vs reverse, or “purl”) can only occur on a given stitch if theneedle directly across from it (on the opposite bed) is empty.In the case of tubular fabric, the opposite bed holds the otherside, which can lead to conflicts. In such case, half-gaugeknitting is a typical solution, which consists in knitting onevery other needle, with both sides offset such that any nee-dle’s counterpart on the opposite bed is empty, as shown inFigure 16. Note that the need for half-gauge depends on boththe shape and the pattern. Even if it is unnecessary, it may stillbe desirable because it creates looser fabric. Thus, we do notautomatically choose which gauge to use, but let the decisionto the user. For full-gauge primitives, we detect conflictingpatterns and show a warning to suggest switching gauge.
RESULTSOur first results explore the range of garments that are machine-knittable using our shaping primitives. We then consider theuse of our different pattern layers, and their behaviors as nodeparameters change.
Span of Shaping PrimitivesOur first collection of knitted results is illustrated on the 12inch mannequin shown in Figure 1, together with adult-sizeversions of a patterned infinity scarf and a ribbed sock. Weshow the individual pieces in Figure 17, each knitted with adifferent yarn color. This includes:
• a hat using one cylindrical sheet with a narrow closed topand a wide open bottom;
• a scarf with pocket ends, using one main flat sheet and endsthat are split-converted into cylinders (one end is open to letthe other end through, and the other is closed as a pocket);
Figure 17: The individual garment pieces from Figure 1. Thescarf uses a single-sided part that would curl on itself bydefault. Thus we used simple 2 by 2 ribs to keep it flat.
• a yoked shirt using one open tube split into three tubes (twofor the sleeves, one for the main body);
• sweatpants as a waist tube with a split branching into twotubular structures;
• two socks using a joint for the heel and two tubes, one ofwhich narrows down to the toes where it closes.
Pattern Layers in ActionThe top part of Figure 19 illustrates how shape modificationsalter two overlapping patterning layers. The background con-sists of a tileable layer repeating a sequence of left and rightmoves to create lacy holes, whereas the foreground is a scal-able image mask applying normal knit stitches. As the sheetsize changes, the layers behave differently: the backgroundkeeps tiling the same small move sequence, whereas the catforeground expands with the size. The bottom part illustratesan extension that includes a pure program layer for the mar-gin, and two complementary scalable foregrounds layers withdifferent stitch operations (knit and purls).
In Figure 18, we visualize the mesh of a patterned infinityscarf, which uses a layer decomposition similar to the tiledlace. However, the tiled lace is applied within a program maskthat makes use of 2D simplex noise to create a random areaselection. Its boundaries are mapped to regular stitches within2 stitches, and to purls from 3 to 4 stitches away.
8
Figure 18: Visualization of the pattern of our infinity scarf (left) with our mesh visualization (center) and a close-up (right).
Figure 19: Top: impact of shape size on a two-layer pattern.The holes are tileable moves from Figure 13. The foregroundcat is scalable and stretches with the shape. Bottom: a similarfour-layer pattern with an additional programmatic margin,and two scalable foregrounds for different shades of a Corgi.
Then in Figure 20 we transfer the global hole pattern to twonodes of a glove skeleton with open fingers. This figure alsoillustrates the potential impact on shaping that some patterns
Figure 20: Patterning the glove for the teaser from left toright: base shape, cuff in half gauge, half-gauge cuff with a ribpattern, and final glove with transferred hole pattern on mainpalm, as well as an additional pattern for the 4 fingers palm.
have. Here, the cuff of the glove has a constant width thatmatches the palm node. The ribbed cuff shrinks considerablyeven though it is knitted over the same bed width (in halfgauge). This is the same glove as in Figure 1.
USER EXPERIENCETo verify that our interface could be used by non-expert usersand receive important feedback, we asked two potential userswithout prior knitting experience to use our system.
ProcedureThe users were provided a 30 minute introduction to the basicoperations involved in machine knitting, including the notionsof shaping and the types of stitches. We also supplied a fewsample videos of expert user sessions, and an introductorydocument for our user interface. We asked them to complete afew tasks: the first ones about patterning, and the later one forshape and pattern customization.
Patterning TaskFor the first subtask, the users were given a base skeleton witha single flat sheet, featuring an initial program pattern thatflattens its margins (to prevent the single-sided fabric fromcurling up). Their task was to draw some additional patternson the sheet.
9
Figure 21: A reference beanie on the left and two customizedbeanies on its right. The rightmost one required a few passesto adjust the lace pattern and its tension.
In the second subtask, we provided examples of lace patterns,and asked the users to create their own lace involving at leasta few move operations.
For the last subtask, we provided a more complicated templateof a wristband, which is similar to the pocketed scarf in 17.The users had to import a pattern from their previous subtasksand apply it on the main part of the wristband. Please see thesupplementary material for these results.
Shaping / Patterning Customization TaskThe second task was to customize an adult-size garment oftheir choice, given an initial skeleton.
Our users chose to customize a beanie and a glove. For thebeanie, users had to change the shape profile of the top section,and optionally modify the pattern of the brim or core sections.For the glove, the goal was to change global, shared design pa-rameters (finger length and width, and/or cuff length) insteadof directly changing the individual node widths. The corre-sponding results are shown in Figures 21 and 23. Figure 22shows a closeup on the laced beanie and its brim.
Feedback and ResultsAlthough none of the users had prior knitting skills, eachone successfully designed sophisticated, machine-knittablestructures that we were able to fabricate. Users were surprisedby their new ability to customize garments, especially largerones (e.g., the beanie).
During the design process, users cited a mismatch betweentheir perception of the garment size (based on our bed visu-alization), and size of the actual knitted result. This suggeststhat, beyond local editing, it may be worth tuning the relative
Figure 22: Beanie closeup showing the main section’s laceand the curled brim with a knit/purl zigzag.
size of wales and courses to perceptually match that of the realyarn. However, realistic sizing is an open problem, as currenttension parameters are hand-tuned and must be adapted forcomplicated patterns (e.g., changing the tension impacts thegarment size substantially). It will require a better simulationthat takes the yarn tension into account.
Our users generally found the patterning interface intuitive,as the image editing analogy was sufficiently familiar. Still,it was difficult for them to reason about the ultimate effectof complex lace patterns. Eventually, they discovered thatthe mesh simulation was more helpful to preview the patternimpact, and made extensive use of it. They alternated betweenthe two views (layout and mesh). Furthermore, one user foundthat complex skeleton constraints could hinder pattern exper-imentation. Instead, they preferred to design their patternson separate, flat sheets, then import the design onto the finalstructure. These behaviours emerged organically.
Although our users were allowed to create new shapes, theydid not actively try to do so in our task setup. This suggeststhat non-experts would likely prefer to start from templates.Our tool might also be valuable for professionals, designersand other expert users, but we have not validated such cases.
Knittability ConstraintsFlat patterns were always knitted successfully on the first try.However, this was not the case for complex patterns on tubularstructures, such as for the adult-size garments.
We show three result beanies, the right one having requiredmultiple iterations to work properly. Our machine translation
10
Figure 23: Three glove variants. The green one took multipleattempts because of the complicated tension requirementsassociated with continuous cross patterns.
had very few issues, but some patterns triggered complicationsduring the knitting process, mainly because of fabric pile-up,which arises from non-optimal yarn tension.
In the case of the gloves, all fully knitted from start withoutpile-up, but we discovered that the sequence of knitting hadsome unexpected impact on the yarn. Fingers are typicallysuspended on the bed before being knitted over to create thepalm and one user decided to use complex patterns on thefingers themselves. This led to previous fingers being exces-sively stretched while suspended, and the yarn locally broke.Finding the appropriate tension was the main complicationfor both the patterned beanie and glove, which required a fewtrial-and-error attempts. We show the evolution of the greenglove of Figure 23 in the supplementary material.
DISCUSSIONWe first discuss some of our design decisions, and then go overour system limitations, highlighting potential improvements.
Scope of Our PrimitivesBy composing three types of primitives (Sheet, Joint and Split),our design space already spans many common garments in-cluding varieties of gloves, socks, scarves, headbands, hats,pants and sweatshirts. The garments which we do not handlenicely are traditionally sewed garments such as pullovers withRaglan sleeves or drop shoulders. The general challenge isspecifying continuous interfaces that glue primitives over mul-tiple courses. We provide further details and an investigationof potential solutions in the supplementary material.
Smarter Pattern LayersOur pattern layers are not guaranteed to behave nicely whenresampled or applied to a shaped primitive. A “correct” be-haviour is often ill-defined: for example, at the top of a verti-cally striped hat, should the stripes become thinner or mergetogether? Thus, it is reasonable to defer to the user in suchscenarios, as we do. A different, recently proposed strategy [8]would be to adapt calibrated patterns to the local context.
Handling Multiple Yarn CarriersWe do not yet support multiple yarns on the bed at once (e.g.,for intarsia). However we envision that such specification ofthe yarn can be done similarly to our patterning by additionallyintroducing a stack of yarn at each stitch. The main modifi-cation would be that yarn tracing would now also involve thespecification and optimization of the different yarn interac-tions. This would allow not only intarsia but also functionalfiber routing, yarn inlays, spacer fabric, and pockets.
Large-Scale InteractivityOur system runs in a browser and can currently remain inter-active with human-sized gloves, socks and beanies. Patterningor shaping full-sized sweaters or sweatpants is challengingbecause of their scale. Computationally, the garments requireprocessing a very large amount of stitches. Their size alsopresents challenges for user pattern specification, as simplepixel-based operations are insufficient.
We expect to solve the computational challenge by using hi-erarchical data structures that do not instantiate all stitchesbut only the required information (e.g., at the boundaries orwhere the size changes). As for the design issue, we assumea similar hierarchical process would help. We envision usingmeta-patterns on higher-level stitch representations to be in-stantiated for the machine. Finally, recent patch-level patternsimulation [14] has shown promising interactive results.
Machine IndependenceCurrently, our system exports machine code for a set of specificmachine targets (Wholegarment® knitting machines [27]).However, our design assumptions are that of general V-bedmachines. Since our system uses very regular course struc-tures, it should be easy to support exporting Knitout code [16],allowing us to potentially target other V-bed machines as well.
CONCLUSIONWe presented a novel interactive system for composing knittedprimitives that encompass a large variety of common garments.This work also introduced a domain specific language forpatterning, along with novel pattern layers that enable patternspecification akin to image editing, complete with differentresampling behaviours. Many works follow, including thesupport for multiple yarn carriers, which will allow morecomplex appearance and functional customization. We arealso interested in optimizing the interactivity using hierarchicalstitch representations, and providing more realistic simulation.
AcknowledgmentsWe would like to thank James Minor for the help with thepaper and voice-over, Tom Buehler for the video composition,our external users Tim Erps and Mike Foshey for their time andprecious feedback, as well as Jim McCann and the members ofthe Textiles Lab at Carnegie Mellon University for providingus with the necessary code to programmatically work with ourindustrial knitting machine. This work is supported by the Na-tional Science Foundation, under grant CMMI-1644558, grantIIS-1409310 and Graduate Research Fellowship 1122374.
11
REFERENCES[1] Lea Albaugh, Scott Hudson, and Lining Yao. 2019.
Digital Fabrication of Soft Actuated Objects by MachineKnitting. In Extended Abstracts of the 2019 CHIConference on Human Factors in Computing Systems(CHI EA ’19). ACM, New York, NY, USA, ArticleVS01, 1 pages. DOI:http://dx.doi.org/10.1145/3290607.3311767
[2] Michael Bostock, Vadim Ogievetsky, and Jeffrey Heer.2011. D3: Data-Driven Documents. IEEE Trans.Visualization & Comp. Graphics (Proc. InfoVis) (2011).http://idl.cs.washington.edu/papers/d3
[3] Ann Budd. 2012. Knitter’s Handy Book of Top-DownSweaters: Basic Designs in Multiple Sizes and Gauges.Interweave.
[4] Butterick Publishing Inc. 2016. The Art of Knitting(Dover Knitting, Crochet, Tatting, Lace). DoverPublications.
[5] Robert L Cook. 1984. Shade trees. ACM SiggraphComputer Graphics 18, 3 (1984), 223–231.
[6] Nanette Donohue. 2015. 750 Knitting Stitches: TheUltimate Knit Stitch Bible. St. Martin’s Griffin.
[7] Nur Al-huda Hamdan, Simon Voelker, and Jan Borchers.2018. Sketch&Stitch: Interactive Embroidery forE-textiles. In Proceedings of the 2018 CHI Conferenceon Human Factors in Computing Systems. ACM, 82.
[8] Megan Hofmann, Lea Albaugh, Ticha Sethapakadi,Jessica Hodgins, Scott Hudson, Jame McCann, andJennifer Mankoff. 2019. KnitPicking Textures:Programming and Modifying Complex Knitted Texturesfor Machine and Hand Knitting. (2019).
[9] Yuki Igarashi, Takeo Igarashi, and Hiromasa Suzuki.2008a. Knitting a 3D model. In Computer GraphicsForum, Vol. 27. Wiley Online Library, 1737–1743.
[10] Yuki Igarashi, Takeo Igarashi, and Hiromasa Suzuki.2008b. Knitty: 3D Modeling of Knitted Animals with aProduction Assistant Interface.. In Eurographics (ShortPapers). Citeseer, 17–20.
[11] Jonathan Kaldor. 2011. Simulating yarn-based cloth.(2011).
[12] Alexandre Kaspar, Tae-Hyun Oh, Liane Makatura, PetrKellnhofer, and Wojciech Matusik. 2019. Neural InverseKnitting: From Images to Manufacturing Instructions. InProceedings of the 36th International Conference onMachine Learning (Proceedings of Machine LearningResearch), Kamalika Chaudhuri and RuslanSalakhutdinov (Eds.), Vol. 97. PMLR, Long Beach,California, USA, 3272–3281.http://proceedings.mlr.press/v97/kaspar19a.html
[13] Matthew Keeter. 2013. Hierarchical volumetric objectrepresentations for digital fabrication workflows. ACM.
[14] Jonathan Leaf, Rundong Wu, Eston Schweickart,Doug L. James, and Steve Marschner. 2018. InteractiveDesign of Yarn-Level Cloth Patterns. ACM Transactionson Graphics (Proceedings of SIGGRAPH Asia 2018) 37,6 (11 2018). DOI:http://dx.doi.org/https://doi.org/10.1145/3272127.3275105
[15] Ali Maziz, Alessandro Concas, Alexandre Khaldi, JonasStålhand, Nils-Krister Persson, and Edwin WH Jager.2017. Knitting and weaving artificial muscles. Scienceadvances 3, 1 (2017), e1600327.
[16] James McCann, Lea Albaugh, Vidya Narayanan, AprilGrow, Wojciech Matusik, Jennifer Mankoff, and JessicaHodgins. 2016. A compiler for 3D machine knitting.ACM Transactions on Graphics (TOG) 35, 4 (2016), 49.
[17] Vidya Narayanan, Lea Albaugh, Jessica Hodgins,Stelian Coros, and James McCann. 2018. AutomaticKnitting of 3D Meshes. ACM Trans. Graph (2018).
[18] Huaishu Peng, Scott Hudson, Jennifer Mankoff, andJames McCann. 2016. Soft printing with fabric. XRDS:Crossroads, The ACM Magazine for Students 22, 3(2016), 50–53.
[19] Hannah Perner-Wilson, Leah Buechley, and MikaSatomi. 2011. Handcrafting Textile Interfaces from aKit-of-no-parts. In Proceedings of the Fifth InternationalConference on Tangible, Embedded, and EmbodiedInteraction (TEI ’11). ACM, New York, NY, USA,61–68. DOI:http://dx.doi.org/10.1145/1935701.1935715
[20] Ivan Poupyrev, Nan-Wei Gong, Shiho Fukuhara,Mustafa Emre Karagozler, Carsten Schwesig, andKaren E. Robinson. 2016. Project Jacquard: InteractiveDigital Textiles at Scale. In Proceedings of the 2016 CHIConference on Human Factors in Computing Systems(CHI ’16). ACM, New York, NY, USA, 4216–4227.DOI:http://dx.doi.org/10.1145/2858036.2858176
[21] Przemyslaw Prusinkiewicz and Aristid Lindenmayer.2012. The algorithmic beauty of plants. SpringerScience & Business Media.
[22] Michael Rein, Valentine Dominique Favrod, Chong Hou,Tural Khudiyev, Alexander Stolyarov, Jason Cox,Chia-Chun Chung, Chhea Chhav, Marty Ellis, JohnJoannopoulos, and others. 2018. Diode fibres forfabric-based optical communications. Nature 560, 7717(2018), 214.
[23] Michael L Rivera, Melissa Moukperian, DanielAshbrook, Jennifer Mankoff, and Scott E Hudson. 2017.Stretching the bounds of 3D printing with embeddedtextiles. In Proceedings of the 2017 CHI Conference onHuman Factors in Computing Systems. ACM, 497–508.
[24] Gerard Rubio. 2014. OpenKnit: Open Source DigitalKnitting. http://openknit.org. (2014). [Online;Accessed: 2018-09-01].
[25] Triambak Saxena, Gerard Rubio, and Tom Catling. 2017.Kniterate: The Digital Knitting Machine.
12
https://www.kickstarter.com/projects/kniterate/
kniterate-the-digital-knitting-machine. (2017).[Online; Accessed: 2018-09-01].
[26] Adriana Schulz, Cynthia Sung, Andrew Spielberg, WeiZhao, Robin Cheng, Eitan Grinspun, Daniela Rus, andWojciech Matusik. 2017. Interactive robogami: Anend-to-end system for design of robots with groundlocomotion. The International Journal of RoboticsResearch 36, 10 (2017), 1131–1147.
[27] Shima Seiki. 2011. SDS-ONE Apex3. http://www.shimaseiki.com/product/design/sdsone_apex/flat/.(2011). [Online; Accessed: 2018-09-01].
[28] D.J. Spencer. 2001. Knitting Technology: AComprehensive Handbook and Practical Guide.Technomic publishing.https://books.google.com/books?id=zsoRvDWPd2gC
[29] Stoll. 2011. M1Plus pattern software.http://www.stoll.com/stoll_software_solutions_en_4/
pattern_software_m1plus/3_1. (2011). [Online; Accessed:2018-09-01].
[30] Nobuyuki Umetani, Danny M Kaufman, Takeo Igarashi,and Eitan Grinspun. 2011. Sensitive couture forinteractive garment modeling and editing. ACM Trans.Graph. 30, 4 (2011), 90–1.
[31] Jenny Underwood. 2009. The design of 3D shapeknitted preforms. (2009).
[32] Vasturiano. 2018. Force-directed graph rendered onHTML5 canvas.https://github.com/vasturiano/force-graph. (2018).[Online; Accessed: 2018-08-22].
[33] Kiril Vidimce, Alexandre Kaspar, Ye Wang, andWojciech Matusik. 2016. Foundry: Hierarchical materialdesign for multi-material fabrication. In Proceedings ofthe 29th Annual Symposium on User Interface Softwareand Technology. ACM, 563–574.
[34] Anita Vogl, Patrick Parzer, Teo Babic, Joanne Leong,Alex Olwal, and Michael Haller. 2017. StretchEBand:Enabling Fabric-based Interactions through RapidFabrication of Textile Stretch Sensors.. In CHI.2617–2627.
[35] Waag. 2014. Building the OpenKnit Machine.https://www.instructables.com/id/
Building-the-Open-Knit-machine/. (2014). [Online;Accessed: 2018-09-01].
[36] Kui Wu, Xifeng Gao, Zachary Ferguson, DanielePanozzo, and Cem Yuksel. 2018a. Stitch meshing. ACMTransactions on Graphics (TOG) 37, 4 (2018), 130.
[37] Kui Wu, Hannah Swan, and Cem Yuksel. 2018b.Knittable Stitch Meshes. ACM Transactions onGraphics (2018).
[38] Cem Yuksel, Jonathan M Kaldor, Doug L James, andSteve Marschner. 2012. Stitch meshes for modelingknitted clothing with yarn-level detail. ACMTransactions on Graphics (TOG) 31, 4 (2012), 37.
[39] Cem Yuksel, Sylvain Lefebvre, and Marco Tarini. 2019.Rethinking Texture Mapping. Computer GraphicsForum (Proceedings of Eurographics 2019) 38, 2 (2019),17. to appear.
13
– Supplementary for –Knitting Skeletons: A Computer-AidedDesign Tool for Shaping and Patterning
of Knitted GarmentsCONTENTThe supplementary material contains:
• Implementation details regarding the process from ourskeleton to machine layout and low-level program• Implementation details regarding our shaping functions
for specifying the local behaviour of increases and de-creases in Sheet primitives• Details about the limitations of our current primitives• Details about our system’s performance• Additional results from the non-expert user sessions• Details about the making of the green glove
IMPLEMENTATION OVERVIEWWe provide a brief overview of our pipeline implementation.Code will be made available publicly. It borrows ideas fromboth Stitch Meshes [38, 36] and Automatic 3D Machine Knit-ting [16, 17]. The initial input is the user-generated skeletonas well as a starting interface to knit from. The stages are, inorder:
1. Shape generation: each node is translated into its indi-vidual set of stitch courses, initial wale connections arecreated (but not course connections across courses), andinterface courses are merged across shapes;
2. Course scheduling: connected components are groupedtogether, topologically sorted and then a course-by-course schedule is generated;
3. Yarn tracing: continuity courses are generated, courseconnections are generated between distinct courses, cre-ating the actual yarn path;
4. Pattern application: pattern layers are translated intotheir corresponding programs and executed, effectivelyassigning a pattern instruction to each stitch;
5. Layout optimization: the node courses are organizedinto layout groups, whose offsets and bed sides are opti-mized iteratively to reduce the stress between stitches;
6. Knitting interpretation: the whole time-needle bed isgenerated, and the yarn path interpreted using both associ-ated pattern instructions and wale connections to generatesequential per-bed passes (namely cast-on, actions, trans-fers, cast-off);
7. Knitting simulation: the bed passes are processed toevaluate potential dangerous yarn situation (large moves,yarn piling up) and generate appropriate warning or errormessages;
8. Bed Compaction: for visualization purpose, we use anadditional pass in which we compact the knitting bed byremoving some of the suspended stitch beds
9. Code generation: the bed passes are translated into low-level machine instructions including specialized needlecast-on and cast-off procedures to prevent yarn from un-ravelling.
Shape GenerationEach skeleton node is individually transformed into a genericshape made of a sequence of stitch courses, some of whichare annotated as interfaces (with respective names similar tothat of the skeleton nodes). Each shape’s course is assembledwith its neighboring courses using the node’s shaper program,layout and alignment properties.
Then all node’s interfaces are processed: connected ones arebound across shapes, and disconnected ones are either leftas-is or closed if chosen by the user.
At this stage, note that some stitch connections have notbeen generated. Notably, course connections across differ-ent courses require orientation information which depends onscheduling, happening next.
Course SchedulingGiven the various shapes and their courses, we first groupsthem into connected components, and then each group is sepa-rately scheduled, course-by-course.
The scheduling is done by topologically sorting the coursesaccording to knitting order constraints: we require previousbranches to be knitted before allowing merge operations insplit nodes.
Yarn TracingGiven the course schedule, we can now trace the path of theyarn and generate course connections. This also involvescreating additional continuity stitches so that the yarn doesn’tjump between far away stitches.
PatterningAt this stage, we have the final stitch graph, and we use ourpatterning layers, transforming them into programs that assignpattern instructions to each stitch.
Layout OptimizationFrom the course schedule, we generate individual disjoint nee-dle bed assignments. The offsets and relative sides betweencourses of a same node are fixed to optimal assignments with-out taking other nodes into accounts, creating groups of fixedbed layouts.
Then, the bed layout groups are optimized w.r.t. each-other’soffsets and relative sides. The main trick here is that we caneasily pre-compute optimal alignments by approximating theyarn stress between two full beds by pre-computing their stitchpairs, as well as their corresponding center of mass, whichshould typically align for the minimal stress assignment.
Knitting InterpretationThe time-needle bed is generated by aggregating the layoutgroups, and a first pass interpret each bed time, bed after bed,generating consecutive per-bed passes over time.
14
1 l e t r a t i o = M / N;2 l e t j 1 = Math . round ( i * r a t i o ) ;3 l e t j 2 = Math . round ( ( i + 1 ) * r a t i o ) ;4 i f ( j 2 == j 1 + 1) {5 / / i maps t o a s i n g l e c e l l ( j 1 )6 i −> j 1 ;7 } e l s e {8 / / i s p l i t s i n t o two c e l l s ( j 1 and j 1
+1)9 i −> ( j1 , j 1 + 1) ;
10 }
Listing (1) Uniform shaper program
1 l e t d = N − M;2 l e t o1 = Math . round (M/ 2 − d / 2 ) ;3 l e t o2 = o1 + d ;4 i f ( i < o1 )5 i −> i ; / / l e f t p a r t6 e l s e i f ( i < o2 ) {7 / / i n c r e a s e s p l i t s i n c e n t e r8 i −> ( o1 + 2*( i−o1 ) , o1 + 2*( i−o1 ) +
1) ;9 } e l s e
10 i −> ( i +d ) ; / / r i g h t p a r t
Listing (2) Center shaper program
Figure 24: Standard shaper programs: (left) uniform distributes the increases and decreases uniformly, (right) center accumulatesthem in the center of the course. Notice the visible seam in the center. At the top are program illustrations for M = 10, N = 14(these numbers are here for illustration, they vary for every row in a real knitting structure). At the bottom are the bed layouts aswell as the knitted results for a flat triangular sheet.
This generates the following (potentially empty) passes foreach time-step:
• Cast-on: empty needles are cast yarn onto (requires spe-cialized procedures to ensure the yarn catches, which isdifferent from typical already-cast knitting);• Actions: per-needle actions are computed for each stitch
of the current time’s bed according to their number of up-going wales, their locations, the previous stitch actions,and their corresponding pattern instruction. Potentialactions include: Knit, Purl, Tuck, Miss, Knit Front/Back,Kickback Knit, Split Knit;• Transfers: necessary transfers are processed per-side at
once, with relative orderings specified by the instructiontypes (e.g. Cross instructions, Stack instructions);• Cast-off: stitches that should be cleared off the bed are
cast-off using dedicated procedures to prevent unraveling.
Knitting SimulationGiven the interpretation, the actual knitting process is simu-lated to discover potential issues due to large yarn stretchingor long interactions between stitch operations (e.g. knit-over-miss for large miss sections, which ends up collapsing theyarn, or several loops merging onto one, beyond the needle
knitting capabilities). This produces potential warning anderror messages that the user can use to correct their layout /parameters.
Code GenerationThe bed pass interpretations are translated into low-level ma-chine instructions, which can then be processed by the machine(typically re-compiled there to check for further issues andassign machine parameters before knitting).
SHAPINGIn our system, shaper programs allow the user to specify thewale binding between successive course of Sheet primitives.Although the main change in shape from such primitive comesfrom the difference in course sizes, the local wale connectionshave two important impacts:
• They induce visual seams around the change of wale flow• They impact the stitch stability (and thus can lead to
knitting failures)
A shaper program describes a function which links stitch unitsbetween two consecutive course rows of sizes M and N. Sincethe order is not important as we are creating bidirectionalwale connections, we assume that M ≤ N. The program takes
15
Body
Sleeve
Glueing
Figure 25: Illustration of one strategy to glue sleeves to themain body – here, a Raglan sleeve. The body and sleeveswould both be knitted separately (i.e., next to each other, oneat a time), and then they would be joined with a sequence ofglueing operations joining both sides up to the neck section.
as input M, N, as well as the current index i within the firstcourse (0≤ i≤M), and potentially other context parameters.Its output is a (possibly empty) sequence of mappings betweencells of the first course and cells of the second course. For twocourses of same sizes, the simplest mapping is i→ i. Two com-mon shaping programs (uniform and center) are illustrated inFigure 24. Given the mapping from the shaping program, oursystem then creates corresponding wale connections betweenthe associated stitch units.
In comparison, systems that build upon meshes such as Au-toKnit [17] or Stitch Meshes [38, 36, 37] do not directly pro-vide user control over increases and decreases. Instead, theseare implicitly encoded in the original mesh. Figure 24 showsthat we can use such programs to control the location of seams,which is of interest when customizing a garment.
LIMITATIONS OF THE SHAPING PRIMITIVESOne constraint of wholegarment industrial knitting machinesis that they cannot instantaneously introduce a new garmentsection (i.e. tubular or flat sheets) with a perpendicular waleflow. Instead, perpendicular wale flows must be joined in acontinuous gluing operation that connects the two suspendedsections laterally, as illustrated in Figure 25.
The current primitives of this work do not support such contin-uous gluing operation. This notably means that we cannot knitgarments with sleeves extending perpendicularly to the basetrunk. Note that it is quite different from our Joint primitivewhose flow is continuously changed from its bottom to itstop, because it does not split the flow, but only redirect it in asingle direction.
Possible solutions we envision include:
• Adding a specialized T-Junction primitive (although weare looking for a more general and simpler-to-specifyprimitive)
• Introducing lateral interfaces for flat sheet primitives,which – combined with Joints and Split – would allowthe creation of T-Junction structures (and more)• Introducing an Anchor primitive that would allow speci-
fying regions on top of current other primitives, to specifyadditional interfaces (e.g. hole sections, from which wecould generate new lateral primitives).
Any of these unfortunately comes with many complication interms of implementation and layout optimization because wecannot work with full courses alone and must allow bindingcourses to parts of other courses over time (i.e. for the lat-eral gluing operation). There is also the problem of how theuser would parameterize the gluing process as many variantsexist [3].
PERFORMANCEThe running time for our system is highly dependent on theclient machine and web browser being used. However, westill provide performance tables here to highlight the currentprocessing bottlenecks: (1) the stitch instantiation and (2) thepattern development.
For both issues, we refer to Table 2 where we provide timingsfor most of the shape skeletons within the paper, excludingrendering times. These are captured on 64-bit Ubuntu 16.04with Intel® Core™ i7-3820 CPU @ 3.60GHz i7 (8 proces-sors) and 24GB of RAM. The test browser was Chromium74. To have a reasonable idea of the peak performance, weran the profiling by loading the skeleton file, then switchingto Compact mode, and generating the output 7 times consecu-tively before actually measuring the times we report here. Thiswarm-up leads the browser to optimize hot functions with itsJust-In-Time compiler. We then export the machine code 3times before measuring the code generation time.
The compaction time isn’t actually needed except for shapesusing branches (here mainly glove) but our implementationinstantiates a new bed whether there is a need for it (branching)or not, so the total update times might be smaller in practice ifthe user does not toggle bed compaction.
Generally, these timings are not meaningful as absolute num-bers, but to understand the relative profile of different pro-cesses w.r.t. different shape complexities. Both shape andpattern updates have mostly linear runtimes as shown in Fig-ure 26 for the considered shapes. However, the complexity ofuser patterns is of course going to be dependent on the userpattern. The linear behaviour for pattern development comesfrom the fact that filter operations traverse all stitches, andthus most of our operations end up being linear in that number.
Instantiating StitchesIn the current implementation, we generate the layout fromscratch every time a change happens. This makes our imple-mentation very simple, but prevents us from reusing most ofthe data that doesn’t change. Unfortunately, reusing stitchinformation is not easy because simple stitch modificationscan have drastic impacts on the whole needle bed (e.g., addinga course at the beginning shifts all following stitches). For theshape part, our system runs mostly linearly in the number of
16
` Skeleton a ` Shape a Pattern ` Layout a ` Yarn a ` Update a Code
Name Nod
esPa
ttern
sSt
itche
s
Cre
ate
Sche
dule
Trac
e
Dev
elop
Cre
ate
Opt
imiz
ePa
ck
Inte
rpre
tSi
mul
ate
Com
pact
Shap
e
Patte
rn
Tota
l
Gen
erat
e
cat-32x32 1 2 1024 3 1 8 30 4 1 7 6 1 2 33 51 63 27cat-64x64 1 2 4096 8 1 15 21 3 <1 18 14 1 5 65 62 86 40
glove 10 3 5030 12 1 11 27 6 9 36 24 9 8 116 119 143 46cat-128x128 1 2 16384 46 <1 70 97 9 1 71 52 9 20 278 259 375 77
sock 6 1 17740 46 <1 50 89 18 <1 70 46 8 34 272 265 361 101corgy 1 4 19200 22 1 78 129 13 <1 83 60 11 24 292 320 421 76
beanie 3 1 28774 141 <1 79 124 29 1 107 67 7 51 482 386 606 96noisy-scarf 1 1 85000 199 <1 328 1034 54 <1 309 219 86 140 1335 1842 2369 335
Table 2: Runtime performances of our system for the shapes within the main paper. All times are in milliseconds.
Number of stitches
Upda
te ti
me
[ms]
40
6080
200
400
600800
2000
1000
2000
4000
6000
8000
1000
0
2000
0
4000
0
6000
0
8000
0
Shape Pattern Total
Figure 26: Plot of the update times for the models in the mainpaper. Shape update includes the time to rendering, minus thepattern development. Pattern update includes the time frompattern development to rendering. Both stitch and time axeshave logarithmic scales.
stitches, and thus we are limited in the size of our garmentshape.
When purely editing the pattern, we avoid recreating the wholedata-structure since the pattern development does not removeor add stitches. Instead, we clear the stitch operations of allstitches, and re-apply the patterns, interpretation, simulationand compaction steps (since these are dependent on both theshape and the pattern).
Pattern DevelopmentThe pattern code evaluation is of course going to be longer toevaluate the more complex the pattern is. Our DSL implemen-tation packs all stitches in a linear array and then mainly relieson filtering the set of indexed stitches for the queries, whereasthe operations are done by traversing the current selected in-dices and applying the operation on the corresponding stitchobjects. The implementation we provide performance for ispurely CPU-based.
We expect possible improvements through a GPU implementa-tion that would compile our DSL as shaders or other computeprograms for GPGPU.
ADDITIONAL NON-EXPERT RESULTSFigures 27 and 28 present additional results from the pattern-ing task of our non-expert user sessions. Although neither ofour users had previous experience with knitting, both wereable to generate interesting, machine-knittable results within afew hours of their start with our system.
MAKING THE GREEN GLOVEThe green glove of the last Figure from the main paper wentover a few complicated iterations whose main results areshown in Figure 29. The initial design was intending to addgripping texture under the fingers. It was going to do so withcontinuously shifted cross patterns. Furthermore, its fingerends were to be closed with some shaping at their ends.
The first issue arose from the finger ends that had used veryquick increases, with unstable kickback operations next tofuture increases. This led to a few holes at the finger tips.This can be fixed by changing the shaping, but also showsthat one would definitely benefit from being able to manuallyspecify the expected shaping seams, since then one could routethe yarn correctly and avoid unstable increases. We plan toautomate the detection and fixing of such problems.
The more interesting issue came from the move patterns onthe fingers. The basic glove skeleton we used was starting theknitting from the fingers to avoid having to split the fingersinto multiple knitting sections. This would have been requiredif starting from the cuffs, because a large knitted section iseventually suspended (the palm), from which smaller branchesextends, one-by-one. In that case, the tension at the boundaryof the branches increases the farther the finger knitting is,which eventually leads to the yarn breaking.
Typically, this can easily be solved for gloves by starting theknitting from the fingers. However, one issue is then that thefingers are kept suspended until the palm can be knitted (i.e.,all fingers have been knitted). Unfortunately, this means thatpatterning the individual fingers with patterns that includelarge movements leads to the suspended yarn being stretched
17
Figure 27: Lace patterns generated during our non-expert user sessions. The leftmost pattern was an expert reference that weprovided for inspiration; the center and rightmost designs were novice user results.
Figure 28: The third patterning task required users to transfer an existing pattern onto a provided wristband template. The patternswere either designed by users in a previous step, or selected from our repository of pre-tested designs. The leftmost column showsan expert reference; the others were designed by our users.
continuously. This is possible, but ended up breaking the yarnin random locations with the tension we used.
Instead, our user decided to move the pattern to the main palm,which solved the issues with the fingers (after also improvingthe shape of finger tips to be stable). Unfortunately, knittingcontinuous cables over a large area requires a correct tensionparameter. Our initial setup was incorrectly estimating thatthe required yarn tension should be very loose (because of themany cables), but effectively they all combined into small 2×1shifts, that do not stretch the yarn beyond 2 needle pitchesglobally. Having a wrongly loose tension typically leads tothe yarn not catching correctly, and more unfortunately init catching onto wrong needles on the sides. This leads tounpredictable behaviours and eventually led to fabric pile up(stopping the machine and also breaking a needle during theclearing process). Fixing the tension led to a completely fineglove.
This illustrates that although our system can allow users tocreate programs for shaping and patterning, there are stillcomponents missing to allow fully automated knitting as aservice. We still require some expertise in how to handle thetension and other machine parameters, which brings up manyinteresting avenues for research.
18
Figure 29: The evolution of the green glove from right to left.
19
