| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Split into classes for Fill, Stroke, and SatinColumn. Renamed params to be
the same across XML attributes and OptionParser. Added distinct stitch length
params for satin underlay. Renamed "satin underlay" to "contour underlay" and
split out "center walk underlay" and "zigzag underlay".
The code is ten times more readable, parameters make more sense, and everything
is specified by the user in millimeters. Basically, everything is way better.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The algorithm was terrible. In general, it seems to work a lot better to just
have the human choose what order things are stitched in than to try to
do it automatically.
|
|
|
|
The code was poorly implemented and unclear. I haven't ever had a need for
preamble. I think my machine (brother SE400) might do it automatically.
|
|
|
|
|
|
|
|
|
|
the code's a total hack, but it gets the job done
|
|
|
|
|
|
|
|
|
|
|
|
* added "flip" option for fills to start stitching in upper left rather than right
* line up rows in abutting fills properly
* handle intersect_with_grating intersection result that is a line or single point (skip row)
* skip endpoint marker tags in SVG files (subtags look like paths)
* dashed stroke indicates running stitch (<=0.5 width still works but is deprecated)
* in running stitches, add a stitch at apex of sharp corners
|
|
|
|
|
|
|
|
|
|
zigzag length
|
|
|
|
Instead of staggering stitches like this:
--*--*--*-
*--*--*--*
stagger like this:
---*-----------*-----------
------*-----------*--------
---------*-----------*-----
------------*-----------*--
---*-----------*-----------
This ends up looking much prettier on the fabric. The number of staggers
is configurable; a value of 2 would behave like the previous commit.
|
|
Previously, each row in a fill region was offset by a random amount. This
looks better than not offsetting at all (which will create visible columns of
stitches), but humans are very good at finding patterns in randomness. The
result is that fill regions look weird.
This commit instead carefully orders the stitches in fill regions such that
each row's stitches are offset by half of max_stitch_length from the previous.
There are also a couple of other miscellaneous fixes and features in here --
sorry about that.
|
|
|
|
Variable satin does zigzag stitches between two arbitrary paths. This lets you do satin stitching of variable width and angles, which is useful for filling smaller regions where tatami filling doesn't make sense. It's also good for doing satin around corners, because it doesn't leave the outer part of the corner sparsely-stitched.
To use variable satin, create an object containing two paths in inkscape. Each path should have the same number of vertices. Zigzag satin will be drawn between the two paths such that a stitch always aligns with each corresponding pair of vertices. This lets you control the way the stitches are angled by subdividing the paths appropriately. Tip: you can add a vertex to a path by double-clicking the place on the path where you want the new vertex.
Be careful when going around corners, especially sharp ones. The number of stitches is based on the zigzag spacing parameter measured around the _longer_ of the two beziers in each segment. Around corners, even if the outside angle is sharp, you may want to make the inside angle slightly rounded to avoid having a bunch of stitches all land at exactly the same point, which could poke a hole in your fabric.
|
|
|
|
The greedy algorithm can be fairly effective, and it's not particularly
expensive to calculate given the relatively small number of patches in
any given set. Instead of doing a greedy algorithm starting from the
furthest point from the centroid (what's the theory there...?), just
find greedy paths from all possible starting points and pick the best.
This gets us pretty close to optimal right out of the gate.
|
