results of satin stitch

[tatyanade]

shape info:

  E.setStitch(10,20,0);
  E.hatchSpacing(3);

  E.setStitch(40,50,0);
  E.hatchSpacing(3);

  E.setStitch(100,100,0);
  E.hatchSpacing(4);

  E.hatchSpacing(3);
  E.setStitch(15,50,0);

  E.setStitch(60,60,0);
  E.hatchSpacing(2.5);

  E.setStitch(30,50,0);
  E.hatchSpacing(2);  

[golanlevin]

Hi @tatyanade , could you try setting the third argument of setStitch() to a non-zero number closer to 1.0? This controls the amount of "noise" in stitch placement. Values of 0.5 and higher should have the effect of removing some of the regularity.

[tatyanade]

Same run with respective noises of: 0.5, 0.5, 0.75, 0.5, 0.8, 0.95 (doing more variations)

[golanlevin]

@LingDong- — is there anything that can be done to [offer control over] staggering the stitches in the SATIN zig-zag? The artifacts in the alignment here are pretty serious.

[LingDong-]

Hi @golanlevin , yup I was already thinking about this, and have a potentially nice solution in mind:

Since we're dealing with it pixel by pixel here, we can say for every even line if x%10!=0 then remove the stitch, for every odd line if (x+5)%10!=0 remove the stitch, and create basically the same effect I did for PARALLEL mode but probably a lot more performant.

[golanlevin]

That's fantastic @LingDong- , thanks. Please make it so. People will expect the SATIN stitch to look a lot smoother :)

Check out this nice satin stitch from 1740:

[LingDong-]

@golanlevin @tatyanade New resample algorithm for satin added: 100c7582e39a8212f3c2b0ff8b3eedc487837167

^ stitch position is now maximally staggered between adjacent lines

[golanlevin]

Oh, that looks good. @tatyanade , please take it for a ride :)

[LingDong-]

Hi @golanlevin @tatyanade

I added a 1740 flower example! f3dd7f5e91f4c76556ecd4bbc25db5d1e78060f6 (examples/PEmrboider_flower)

It all uses SATIN stitches.

However there seems to be a color optimization bug that showed up (probably due to the fact that there are 174 color changes :P). Will look into it!

[tatyanade]

Spacing of 5 four (ran out of thread ) 3.5 (color shifted cause bright orange doesnt scan well but this way you can see the details)

And the flower looks exciting! I will give it a run tomorrow & post results

[golanlevin]

Hmm! I have questions about a few things.

1. Shouldn't this curvy diagonal line be underneath the satin stitching?

2. I'm concerned about these gaps that are opening up at the branching points (admittedly, much worse for wide spacing). Do they look bad up close?

3. I still see some bumps/valleys in the SATIN mode, despite the staggering. Does it look bad in person, or is it OK?

[LingDong-]

@golanlevin @tatyanade

Added experimental option SATIN_NO_ZIGZAG = true which parallelizes the zig-zag lines, which may be helpful for the gap.

Also I tried to color-optimize the 1740 flower design for 8 hours yet it couldn't reduce even a single color change. 118 layers is simply too much permutation :P I've got another idea in mind, will try it out.

[tatyanade]

@golanlevin

2. Yeah the gaps are quite noticable with larger spacing numbers:

[3.5 ] [5, 4]

3. They are noticeable in person; Im going to test the new no zig zag and will update on the results as well as try a few different settings. I think this could also be improved with different staggering - instead of .5 a .33 or smaller would probably be more effective

Also worth noting in hand embroidery a Satin Stitch actually covers the length of the shape with no stitch ends in the middle at all, so it is more effective for smaller width and we wont be able to get a perfect match without doing that & it will look somewhat similair to parallel because of this.

[golanlevin]

Thanks @LingDong- for trying the SATIN_NO_ZIGZAG variant, perhaps it will work better. Though, I notice that it has a funny anisotropy; endpoints on some edges look better than others.

@LingDong- , I was looking carefully at Theodore Gray's solution, and it looks like he extends branch-points one stitch deeper into the shape (past the split point). Perhaps this is how he avoids producing the gap?

[LingDong-]

@golanlevin

I couldn't think of a way to do it so far. The fundamental assumption of the raster method is, every pixel is iterated exactly once (like a flood fill), and this is exactly what happens currently (and is what make it so much more simple and robust than the vector method). The gap is due to the pattern of the connecting stroke between rows, and there isn't really a way to know about it or even represent in the current system. In my observation the situation only happens when the trunk is much wider than the branches, and only when the row number is of certain parity. It happens to happen a couple of times in the 45° case of TG's shape. I tried to look carefully at TG's gif but from the cartoonish rendering I couldn't see how he's dealing with it (it doesn't show the connecting strokes, only the parallel ones and fat stripes) or if he's dealing with it at all. Perhaps he was using a vector method, leveraging Mathematica's powerful computation engine.

EDIT: One way I could think of now is to not use connecting strokes: the row scan will first happen from left to right, step to next row, and go from right to left, then left to right, then right to left. So the zig zag is part of the fill, and not a result of connection between rows. But that would be twice as complicated as current algorithm (x2 amount of cases to check) and has to be rewritten (nearly) from scratch. But theoretically I think this might yet be the easiest way.

[golanlevin]

Hi @LingDong- , I sincerely regret the pain in the ass, but I encourage you to try your suggestion in the edit, above. The reason is that I predict our tool will be heavily judged on the quality of its SATIN rendering. The big companies will be frightened if we solve this well.

However, I can give you a gift, which is the name. This technique is called BOUSTROPHEDON, a fantastic word from the Ancient Greek, which means, "as the ox plows". It turns out that the ancient Greeks and Etruscans, would write text in alternate lines in opposite directions, with mirror writing!

Definitely keep the old version around though!

[tatyanade]

These are results of no_zigzag=true ; which did get rid of the most dramatic gap from the 4 spacing

spacing of 3

spacing of 4

And the original design with the new resample algorithm and with the previous noise values, but not with zigzag enabled

[LingDong-]

@golanlevin looks like BOUSTROPHEDON is gonna work

[golanlevin]

AMAAAAZING!

[LingDong-]

@golanlevin @tatyanade

BOUSTROPHEDON mode added! d014bdefcf2dce0f5bc9486a3019071610c2e10c

Usage:

E.satinMode(ZIGZAG); // classic
E.satinMode(SIGSAG); // zigzag parallelized, replacing SATIN_NO_ZIGZAG = true
E.satinMode(BOUSTROPHEDON); // the new mode!

[tatyanade]

boustrophedon spacing of 4 3 This got rid of the large gaps but there are more smaller gaps; would benefit from a smaller hatch spacing im sure (2 or so maybe, i can make a print) but the bumps and valleys seem more pronounced

[golanlevin]

It's terrific that the machine can print this shape in one shot :) Yay Lingdong's satin algorithm!

The need for a smaller spacing makes sense, because the threads are more parallel than before. I think that's what's causing those small gaps: tiny differences/irregularities in the machine's execution — not a PEmbroider software problem (as the big gaps from earlier had been).

As for the valleys, I think it might look nicer with longer stitches, and perhaps some dithering noise in setStitch()?

[tatyanade]

These are both with setsitch of (10, 80, .75)

hatchSpacing(2)

hatchSpacing(1.5) this one is to close together

Looks good :)

Is there a command similair to parallel_resampling_offset_factor? the current value is to large for a spacing of 2 and does warp some (more so in 1.5 then 2) But more noticably makes the bumps/valleys more noticable

[LingDong-]

Added E.SATIN_RESAMPLING_OFFSET_FACTOR=0.0~1.0 that works similarly to PARALLEL_RESAMPLING_OFFSET_FACTOR. The factor will be rounded to discrete values depending on the stitch length though, due to the raster nature of the algorithm.

be2a8a455e8d22a37651ce9c90c836cb701363f4

[golanlevin]

@tatyanade that should help a lot :) Thanks @LingDong- !

[tatyanade]

Hi @LingDong-

does it round to the tenth place? I'm having issues finessing the resampling factor - 1 & .5 work as expected but 0.2, 0.25, 0.6, 0.33 all look relativly similar in that it only repeats 2 unique stitch placement patterns instead of how parallel_resample behaves (where your input determines how many different ones repeat ie. .33 = 3) so it still has noticable bumps and valleys

you can see what i mean here ^

[LingDong-]

Hi @tatyanade ,

Ok! I see what you mean, I've now changed it to work that way: ca8bcb3432e00c07805a711151660770364e3592

[tatyanade]

Awesome thanks! here are the results, looks much better

[golanlevin]

Oh my goodness, that looks amazing, this is the first time I've really seen SATIN look so perfect. Good work @tatyanade & @LingDong- !