I was playing around with Inkscape and doing something along those lines, but the path operations in Inkscape work on closed curves. You can’t just make a collection of lines and do an “intersection”, for example. I was thinking that I could make a “comb” (think a parallel-lines zig-zag path with the first and last nodes connected), then do path operations on that. That would leave the area fill as lines, but it would also leave a “dashed” outline, as the nodes where the “infill” intersects with the outline of the shape would alternate open and closed as viewed from the perspective of following the outline.
Theoretically, I could do some post-processing on the resulting “infill” to statistically determine the mode of the slopes of all the linear segments in the path’s data, then remove all path segments that do not match that slope. (Basically, turn the contents of the d attribute into a collection of “move, line, move, line” subpaths.) I’d have to also consider what to do with the literal edge case of a fill segment being superimposed on an outline segment. (Should the fill segment be dropped so you don’t double-scratch, and if so, what’s the tolerance of “superimposed”? Less than 50% of the line spacing?) With a “comb” generator, a path Intersection operation, and a post-processing extension to remove the extraneous outline segments, I could achieve a complete linear infill. Following that twice, and you’ve got a crosshatch.
If there were a more straightforward “make linewise fill” Inkscape extension, things would be easy on the user side. Unfortunately, I may not grok the math of curves well enough at present to consider that within my current capabilities of being something I could write well. This may change, and I may be able to come up with an acceptable approach that makes it click in my head. For now, it’s trivially easy to do in LightBurn, and converting the resulting G-code from laser to diamond drag bit application is pretty straightforward. I’ll be happy when there’s a nice free and open workflow, but $40 for LightBurn to make life easy seems reasonable, as that’s below the price of a diamond drag bit. Plus, I can probably work up a user-friendly laser/drag-bit converter, since the G-code changes are all but trivial.
Carbide Create “Texture” toolpath info:
I was hoping to be able to do something with just Carbide Create, but the “Texture” toolpath does not get you what you need. I set “Stepover” to my desired line spacing, “Stepover Variation(%)” to zero, “Min Depth” and “Max Depth” both to 1mm, “Min Length” and “Max Length” equal and well over the longest possible line across my design (e.g. 500mm or whatever), “Min Overlap (%)” and “Max Overlap (%)” both to 100, and “Angle” to my desired angle (45 degrees in this case). The resulting G-code looked like this:
G1Z0.000F635.0
G1X280.090Y204.908Z-0.422F1905.0
X275.746Y200.564Z-0.750
X271.398Y196.217Z-0.942
X267.383Y192.201Z-1.000
X263.367Y188.186Z-0.942
X259.019Y183.838Z-0.750
X254.675Y179.494Z-0.422
X250.671Y175.490Z0.000
G0Z12.700
The Z depth was not constant, as I would have expected. With this result, I went back and changed the “Max Depth” to 2mm and exported the G-code again. Looking at the results of that experiment, it is now clear what the “Min Depth” and “Max Depth” values actually are. They’re the range of the maximum depth of each texture segment. Each texture segment’s actual Z depths range from the surface at the ends to a randomly selected maximum depth somewhere between the entered “Min Depth” and “Max Depth” values.
So, “Texture” toolpath option does not yield G-code suitable for diamond drag bit engraving.