PEmbroider icon indicating copy to clipboard operation
PEmbroider copied to clipboard

Documentation of "spine" hatching — new example

Open golanlevin opened this issue 4 years ago • 13 comments

Hi @tatyanade , Please see PEmbroider_shape_hatching_experimental. I would be grateful if you could document "spine" hatching mode, as demonstrated in the upper row of this example. It requires some advanced bullshit (offscreen graphics buffer etc.) but it's pretty cool I think. You can comment out the SPIRAL shapes for the photos.

Spine hatching is experimental. It looks like SPIRAL hatching is also having issues, as we've discussed before. (@LingDong- , please see this example.)

PEmbroider_shapes_hatching_experimental

golanlevin avatar Jul 02 '20 20:07 golanlevin

Hi, will do some more tests but there seems to be an issue with stitch placement. The file was way to large stitch-count-wise so i split it in 2 , with the triangle, arcs, and left shape in one(which was still to large for the machine), and the shape on the right in the other. Was printing the right shape and it got this far image and then stopped cause it was trying to put hundreds of stitches (it started there on stitch four-hundered-something and now is at 639 and counting) in the same exact spot (which is the dot the the right of what got filled in the pic) Maybe worth making a limit to number of stitches possible at the same exact point.

Will try on the other shapes later today and see if it does something similair

tatyanade avatar Jul 02 '20 22:07 tatyanade

@LingDong- , this is the second time we've had difficulty exporting "Spine" hatching, because the number of stitches was too large. Could you please check to see if maybe there is a simple bug that is causing duplicate data to be exported?

golanlevin avatar Jul 02 '20 22:07 golanlevin

@golanlevin @tatyanade Fixed: 1091522c2ec9478bc39c4618b8de49332e8e4588

The vector field is causing the stitch to go back and forth infinitely. When stitch is on one side of the hill top, the field tells it to go forward, which makes it leap to the other side, and where the field tells it to go backward, so it keeps spinning around. It's the same kind of glitch when people make their first zombie AI :)

LingDong- avatar Jul 03 '20 00:07 LingDong-

Funny. I'm glad you found that. @tatyanade please try again.

golanlevin avatar Jul 03 '20 00:07 golanlevin

(thread broke on the 2 left shapes that's why they have a small gap)

Printed without error :) ; here's the results from experimental spine hatch image

tatyanade avatar Jul 03 '20 16:07 tatyanade

Well, I think SPIRAL mode should be considered experimental for now, it's got (known) bugs, and it's not that different from CONCENTRIC, anyway.

Spine hatch is looking good. @tatyanade , could you please re-print just the top row (ditch the spiral stuff). If you want, you could add a shape of your own :) And we'll call it a wrap on this demo.

golanlevin avatar Jul 03 '20 17:07 golanlevin

Screen Shot 2020-07-03 at 4 42 53 PM

I tried to make a different SPIRAL algorithm but it seems like it has a different set of issues (and is slower)...

EDIT: I now have yet another idea...

LingDong- avatar Jul 03 '20 20:07 LingDong-

Screen Shot 2020-07-03 at 5 21 21 PM

This idea finally worked!

LingDong- avatar Jul 03 '20 21:07 LingDong-

Ah! Super nice!!! We'll have to do some tests with SPRIAL on difficult shapes (holes etc) but it's so much better!

golanlevin avatar Jul 03 '20 22:07 golanlevin

I think the improved algorithm is still mostly restricted to convex-ish, round-ish shapes.

The algorithm works by matching every vertex on each super-sampled ring to every vertex on next ring (which btw is somewhat slow on larger shapes) with a 1-to-1 mapping. However sometimes the matching simply wouldn't work, because the general geometry of the shape can change drastically from one ring to the next, so some vertex should actually to many vertices (while some none).

E.g. consider this screw case.

                         ________
                        /  ____  |
                       /  /   |  |
                      /  / /| |  |
                     /  / /_| |  |
.-------------------'  /______|  |
|_______________________________/

The long part of the first ring is too skinny for the spacing, so its gone in the second ring. However, both rings will be supersampled to, say 1000 vertices, and attempted to be matched, which causes it to explode like crazy.

consider another screw case involving super sharp angle:

                                      ______
                          _____.-----'     _
              _____.-----'  ________.-----'
  _____.-----'             B----------------
A'------------------------------------------

Ideally A and B will be matched. However they're so far away, and many points on the outer ring are closer to B than A. Sometimes the algorithm will get it right, because it evaluates all the vertices and tries to come up with a solution that best satisfies all the vertices, however sometimes the difference is just too large and causes it to explode like crazy.

LingDong- avatar Jul 03 '20 23:07 LingDong-

Hi @LingDong- I'm getting the same stuck-in-position error when running a perfect circle (gets stuck up and down at the origin)

tatyanade avatar Jul 12 '20 21:07 tatyanade

The perfect circle is a special case because it has no "spine", i.e. the skeletonization of it is an empty set.

And there isn't a very reliable way to detect the stuck loop afterwards, because it does not go back and fro between 2 positions like the cases I fixed. Instead the stitch walks around the "singularity" in a small random doodle, e.g.: (magnified 10 times)

Screen Shot 2020-07-12 at 6 10 21 PM

There're two simple ways for the user to resolve this:

  • draw a tiny black dot (2px radius) at the centre of the circle. The skeletonization will now be well defined and hatchVF work as normal
  • Use new overloaded method hatchSpineVF(PImage,spacing,maxVertices) e.g.
hatchSpineVF(pg,E.HATCH_SPACING,50);

which limits the maximum stitches of every hatching stroke to the specified number, hence stopping it before it can get stuck in position.

LingDong- avatar Jul 12 '20 22:07 LingDong-

I noticed when using hatchSpineVF it draws an outline even when using E.noStroke()

// Test program for the PEmbroider library for Processing:
// Filling an image with the experimental SPINE hatch

import processing.embroider.*;
PEmbroiderGraphics E;
PImage myImage;

void setup() {
  noLoop(); 
  size (600, 600);

  E = new PEmbroiderGraphics(this, width, height);
  String outputFilePath = sketchPath("PEmbroider_bitmap_image_2.pdf");
  E.setPath(outputFilePath); 

  // The image should consist of white shapes on a black background. 
  // The ideal image is an exclusively black-and-white .PNG or .GIF.
  myImage = loadImage("processing_logo.png");

  E.beginDraw(); 
  E.clear();


  E.noStroke();
  E.fill(255, 0, 0);
  // Uncomment for the Alternative "Spine" rendering style:
  PEmbroiderHatchSpine.setGraphics(E);
  PEmbroiderHatchSpine.hatchSpineVF(myImage, 5);

  //-----------------------
  // E.optimize();   // slow, but good and important
  E.visualize();  // 
  E.printStats(); //
  E.endDraw();    // write out the file
  // save("PEmbroider_bitmap_image_2.png");
}


//--------------------------------------------
void draw() {
  ;
}

stephanschulz avatar Sep 09 '20 15:09 stephanschulz