Hatches being output in unexpected order

[andenacitelli]

Here's a short video to demonstrate:

I want the vectors to be output strictly top-right to bottom-left (the direction of the hatch angle, or 90deg from it - you get the gist). However, I'm seeing that some vectors entirely below the hole are being output before some vectors to the right of the hole. I want vectors directly parallel, across from each other across the hole, to be burned one right after another, so you get a nice, linear progression down and to the left (in this example).

Any idea what's going on here? Am I right to assume this could be remedied by LinearSort (which I've submitted a separate issue for, as I think it's flawed)?

Thank you!

[drlukeparry]

In theory, you should be able generate the hatch vectors in the preferred order (i.e. scanning parallel across the hole) . Using the PySLM the order 'should' be retained if you use the clipLines function and then sort the scan vector following clipping. See the excerpt from below.

The 3rd column (or z coordinate) from the hatch vectors is the sort order usually created by numpy.arange. This is then used following clipping to sort the order of the hatch vectors.
`

        # Clip the hatch fill to the boundary
        clippedPaths = self.clipLines(paths, hatches)
        clippedLines = []

        # Merge the lines together
        if len(clippedPaths) > 0:

            clippedLines = BaseHatcher.clipperToHatchArray(clippedPaths)

            # Extract only x-y coordinates and sort based on the pseudo-order stored in the z component.
            clippedLines = clippedLines[:, :, :3]
            id = np.argsort(clippedLines[:, 0, 2])
            clippedLines = clippedLines[id, :, :]

`

This is not to say it is perfect. I have seen a few rare occasions where the scan order is not preserved (e.g. bad incorrectly oriented clipping boundaries) or the PyClipper tolerance is set too low.

If you can confirm by providing the example, I can look further into this, but the behavior described above does appear unusual.

[andenacitelli]

I previously had that id = np.argsort(clippedLines[:, 0, 2]) changed to id = np.argsort(clippedLines[:, 0, 1]), as it was erroring out, but I now realize that's probably what's leading to unanticipated behavior (i.e. I was doing something along the lines of sorting based on y-coordinate). However, I'm unsure of why id = np.argsort(clippedLines[:, 0, 2]) leads to an error.

Here's my debugger:

It seems clippedLines is of shape (1988, 2, 2), where to my understanding the code expects (1988, 2, 3). There should be a "z-coordinate" there, but there isn't. Tracing the code a bit, it seems hatches a few lines earlier has a z-coordinate (corresponding to its burn order or something similar) whereas clippedPaths seems to lose that information. Tracing clipLines a bit, it seems to have a z-coordinate in lineList, but loses it during the conversion to lineOutput:

I believe the small tweak I mentioned prior was my only change to the framework - one I shouldn't have done in the first place. I've since recompiled everything and the issue persists. I will continue looking into it and see if I can get together a reproducible example. If you have any input in the meantime, feel free.

[andenacitelli]

While this doesn't actually solve this specific issue, I was able to fix this by essentially commenting out the sorting lines and successfully using LinearSort, as detailed in Issue #16 . Here's some gifs of the finished result: