| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
try_swap occasionally made very bad swaps that increased the overall cost.
If asked to swap neighboring patches, the calculations were completely wrong.
|
|
|
|
|
|
|
|
My previous fix didn't really do the job. It took patches in Z-order, but runs of patches of the same color were fed into the TSP algorithm and it could embroider them in whatever order it chose. This resulted in underlays for my fill regions being embroidered AFTER the fill.
Now, the "preserve order" option has been changed to "preserve layers". Patches on different layers are gauranteed to be stitched in layer order. Patches of the same color within the same layer can be stitched in any order as chosen by the TSP algorithm.
|
|
* properly process transform parameters (ungrouping no longer necessary!)
* handle satin on beziers properly
* previously beziers were stroked as straight line segments that included control points
* allow overriding parameters on individual paths by adding extra svg params
* embroider_angle, embroider_stitch_length, embroider_zigzag_spacing, embroider_row_spacing, etc
* set using "Edit XML"
* default to 10 pixels per millimeter
* properly write CSV files in millimeters (was dividing by 10)
* always translate pattern to origin to fit in hoop
* add "running stitch length" for < 0.5 stroke width)
* don't traceback if no paths were selected
* add "repeats" option for stroke (satin/running stitch) to go back and forth over the line
* good for a double line of center-line underlay below satin
|
|
|
|
|
|
|
|
Add Franklin G-Code target as output.
Fix issue that filled area was treated as one patch per stitch.
Don't autodetect orientation; let the user choose by orienting the object.
Remove empty stitches.
Base generated inkscape path on output from file.
Allow maximum stitch length of 10 cm.
Save debug output in /tmp.
Disable almost all debugging.
Let hatching connect the segments.
|
|
|
