Inkscape, line segments?

I converted the .svg to .dxf in Lightburn first, since IntelliCAD does not know that format. I did 3 versions, one at 0.01, 0.02 & 0.04 & that was the only change I made in that dialog & zip file contains them in .DXF format. I tried setting the Convert adjacent line segments into arcs but didn’t see a change in file size to speak of. See if any of these are better. All those threads could stand to be retraced to make it look cleaner but might look alright depending on how far away you are viewing it.
Assm - ISO Drawing v0_01-04.zip (715.2 KB)

1 Like

Perfect.

I had to use SVG because ESTLCAM was scrambling the DXF. I think it was just to crazy. Let me see what has the the least segments.

Dang that combine most things and came down to 800+ segments, but it scrambled the threads pretty good. I might give the big one a shot as it might not be noticeable.

Thank you!!!

This worked better than expected. I might have to add some details as I do want it to stay busy for a while. I don’t want to have to change it constantly all day. Maybe I will add an iso of the other machines as well.

AutoCAD also has the option to delete stuff like that in some cases. If you want I can try.

Thanks, let me see how this goes, I think 1/3 the moves is really going to make it much better. Flashing it now.

Tracing over that leadscrew in CAD would not be too much trouble since most of the threading could be copied. There appear to be over 6000 line segments on the leadscrew out of 46,788 total segments in the original .svg file. At least those are the numbers I get when I explode all the polylines to lines & then select them.

Ok I’m already late but it was a fun puzzle.

Python program
from svgpathtools import svg2paths, Line, wsvg

input = "cleaned5.svg"
output = "cleaned5_fixed1.svg"

def joinpaths(p1, p2):
    p1start = p1[0].start
    p1end = p1[-1].end
    p2start = p2[0].start
    p2end = p2[-1].end
    dists = [ abs(p1start-p2start), abs(p1start-p2end), abs(p1end-p2start), abs(p1end-p2end) ]
    if min(dists) == dists[0]:
        t1 = p2.reversed()
        t2 = p1
    elif min(dists) == dists[1]:
        t1 = p2
        t2 = p1
    elif min(dists) == dists[2]:
        t1 = p1
        t2 = p2
    else:
        t1 = p1
        t2 = p2.reversed()
    t1.append(Line(t1[-1].end, t2[0].start))
    for seg in t2:
        t1.append(seg)
    return t1


def resolve(indir, ix):  # sorta like union find
    while indir[ix] != ix:
        ix = indir[ix]
    return ix


apaths, attributes = svg2paths(input)

paths = []
cpaths = []
for p in apaths:
    if p.isclosed():
        cpaths.append(p)
    else:
        paths.append(p)

print(f"Number of open, closed paths: {len(paths)}, {len(cpaths)}")

indir = list(range(len(paths)))

nearby = []

prox_threshold = 0.3

print("searching for nearby pairs...")

for i in range(len(paths)):
    p1start = paths[i][0].start
    p1end = paths[i][-1].end
    for j in range(i+1, len(paths)):
        p2start = paths[j][0].start
        p2end = paths[j][-1].end
        mdist = min(abs(p1start-p2start), abs(p1start-p2end), abs(p1end-p2start), abs(p1end-p2end))
        if mdist < prox_threshold:
            nearby.append((i, j, mdist))

print(f"number of pairs that are nearby: {len(nearby)}")

s_nearby = sorted(nearby, key=lambda x: x[2])

print("merging...")

for trip in s_nearby:
    i = resolve(indir, trip[0])
    j = resolve(indir, trip[1])

    if i == j:
        # print("already collapsed")
        continue
    p1start = paths[i][0].start
    p1end = paths[i][-1].end
    p2start = paths[j][0].start
    p2end = paths[j][-1].end
    mdist = min(abs(p1start-p2start), abs(p1start-p2end), abs(p1end-p2start), abs(p1end-p2end))
    if mdist < prox_threshold:
        # join paths paths[i] and paths[j] into new path and stuff into paths[i]
        paths[i] = joinpaths(paths[i], paths[j])
        indir[j] = i
        paths[j] = None

for p in paths:
    if p is not None:
        cpaths.append(p)

wsvg(cpaths, filename=output)

Find all pairs of (non-closed) paths, and if the end of one is within 0.3 mm of the end of the other, join them with a segment to unify them into a longer path.

It doesn’t scale particularly well (quadratic time) but it is fast enough for this task and ended up with 1534 paths for the LR3:

cleaned5_fixed1

7 Likes

That is awesome regardless! Wow.

2 Likes

Well I just tore the machine apart and packed it up… I can try it when I get there.

I hope to learn programming a little better. The way some of you just whip stuff like that up is magical to me.

1 Like

Love these isometric’sh technical line drawing views. Appreciate they’re time consuming to produce.

Cool looking machine, what’s it called? :slight_smile:

1 Like

Lord Richard the 3rd… LR3 for short :smiley:

1 Like

Am I missing something here? Looks like you have more line segments than the original version. I took your cleaned5_fixed1.svg & imported it into lightburn as I did the other one. Scaled it to match the width of the original one & exported it to DXF. I opened the DXF I created from the original SVG Assm - ISO Drawing v0.dxf that Ryan posted & took out the 2 colored insets to match your graphics. After exploding the polylines in each drawing to lines, I get 43054 line segments for yours & 40114 for original without running that overkill command. That is 2940 extra lines by my count. I did not run the overkill command on either of these in this test. Since I didn’t use the overkill command, I probably didn’t need to scale it in lightburn to match the original.

1 Like

Yes. I’m not counting line segments, I’m counting poly-lines (paths) because that’s what determines Z up/Z down cycles.

You’re correct that the number of segments is higher. My adjustment is not at all simplified from the original and only adds (very short) connecting segments to join numerous short poly-lines into fewer, longer poly-lines.

The number of poly-lines (and therefore Z cycles) is roughly 1/4 of the original.

6 Likes

Thanks for the info. Figured there was something I was missing.

2 Likes

After seeing Jamie’s script produce less paths, I went back to Lightburn to see if I could find a tolerance setting that might combine more paths. Clearly there were more paths that could be combined. I did not directly find a solution, but I found out some things that were interesting and an indirect solution.

It turns out that importing DXF files into Lightburn is different than importing SVG files. DXF files are auto-joined automatically when imported based on a tolerance setting in Settings/File Settings:

image

So, if, in Lightburn, you import the DXF instead of the SVG, there is a tolerance setting you can play with to see if you can further reduce the number of paths.

In addition, I found out that, when combining multiple paths that meet at the same point, Lightburn will favor taking the straightest path. This might be beneficial for pen drawings. I’m not sure what (if any) that algorithm would have on the number of paths needed.

2 Likes

Put in the 525(?) pre-Burly trucks (the ones with the arc on them). They’re distinctive, and those who know, will know.

Or just an evolutionary chain of trucks or cores…

Oh that is cool! Lightburn is such a great piece of software. I hope they venture into CAM…