hm, selecting something (as in clicking on..) in librecad and hitting the del key works for me... (for the "could not figure out...")
yepp, sadly enough, fc does choke on larger dxf files.
well, one should rather say the dxf importers chokes fc, the signs are such that it is rather the importer than core that is the main culprit here, regardless of python or c importer...
actually in this particular case, I am convinced that would be possible to write an importer in python that is faster and less memory hungry than the current c importer...
it seems like the c importer consumes in the range of 1 Gb RAM for every Mb dxf - for people that know c - that has to be possible to polish a bit.
the trouble fc sometimes has with importing dxf files intrigues me, for whatever reason - think it is an interesting problem - and also think that it is important for fc's well being to have decent capabilities of importing "open" formats.
anyhow, to deal with large dxf in fc, one needs a strategy, currently that means one needs to preprocess the files outside of fc.
so, just by saving the file with lc the filesize is halved, apparently because the original file has layer specified for every entity, i.e. a lot of repeats (this does nothing for import-ability into fc though... - for obvious reasons)
btw, you never mentioned which sw has written these dxf's, one has to wonder if there are some settings there to tweak somewhere...
the issue at hand (with the larger file of the two) simply is the amounts, both amount of entities (large numbers of fc-doc objects makes fc slow) and amount of vertices.
the file is exclusively polylines, so what can one do to reduce those a bit?
one could of course manually delete selected vertices, both lc and inkscape works for that,
however for a file like this - it gets boring quickly...
so, is it possible to script?
turns out that it is - using ezdxf, one can with some simple logic reduce the number of vertices.
the script below will do that, running it twice will demolish 120k -ish points without doing much to visuals.
Code: Select all
"""
command line tool to reduce dxf files
consisting of large amounts of small linesegments
author / copyright: heda@fc-forum 2022
license: MIT
"""
import sys
import ezdxf
DRYRUN = True
MINVERTS = 20
REMOVETHRESHOLD = 0.1
args = sys.argv[1:]
if len(args) == 0:
print('need at least one input file')
elif len(args) == 1:
print('making a dryrun')
filein, = args
elif len(args) == 2:
filein, fileout = args
DRYRUN = False
print('opening file:', filein)
doc = ezdxf.readfile(filein)
print('reading file completed...')
rcount = vcount = ecount = rdist = 0
rdistmin = REMOVETHRESHOLD
for entity in doc.entities:
if entity.dxftype() != 'POLYLINE':
continue
verts = entity.vertices
lverts = len(verts)
if lverts < MINVERTS:
continue
print('POLYLINE #{}'.format(entity.dxf.get('handle')))
ecount += 1
vcount += lverts
idxr = [-1]
for i, tri in enumerate(zip(verts[0:], verts[1:], verts[2:])):
if idxr[-1] == i:
continue
v0, v1, v2 = (v.dxf.location for v in tri)
d01 = v0.distance(v1)
d12 = v1.distance(v2)
if d01 < REMOVETHRESHOLD and d12 < REMOVETHRESHOLD:
idxr.append(i+1)
rdist = max(rdist, d01, d12)
rdistmin = min(rdistmin, d01, d12)
if DRYRUN:
print(' tagged', i+1, round(d01, 4), round(d12, 4))
idxr = idxr[1:][::-1]
rcount += len(idxr)
print(' removing tagged: {} of {}'.format(len(idxr), lverts))
if not DRYRUN:
print(' dist max: {:.4f} min: {:.4f}'.format(rdist, rdistmin))
for i in idxr:
del entity.vertices[i]
msg = ('finished reduction, removed {} vertices of {} ({:.1f} %)\n'
'from {} entities. max / min length removed: {:.4f} / {:.4f}')
print(msg.format(rcount, vcount, rcount/vcount*100, ecount, rdist, rdistmin))
if not DRYRUN:
print('saving file...')
doc.saveas(fileout)
print('done...')
on my underpowered and useless laptop, this will then import as is (file is down to 4mb, and a save in lc takes it down to 2mb).
a zipped version of that file is attached, i.e. going from 16mb to 0.6 mb...
although this file will import, it still takes forever (as in hours) on my useless laptop (suppose one reason is because it goes to hdd-swap)
so, is there something else that one can do?
turns out there is...
converting the dxf to a svg makes wonders for import time to fc
let's use inkscape for that, for whatever reason inkscape will not import polylines, so one has to use the dxf saved by lc, since lc for whatever reason is converting the polylines to lwpolylines...
importing this svg into fc is quick, also on my useless laptop. the svg is attached as well.
given these circumstances in memory/speed, it clearly points towards that it is possible to write a faster py importer than the current c importer, if the svg importer can largely do the import without breaking a sweat, why would it not be possible to roll a new py importer that is reasonably quick...
afterall, the only thing needed to make an importer for this file is just to add Part.makeWire in the posted script, so with a handfull of additional lines, one has rolled ones own brand new fc-dxf importer...
using ezdxf, one could probably also start supporting nurbs and solids as well from dxf-files without too much effort (if that is something that someone thinks is desirable...)
this is just showing a way, hopefully someone brave will improve the dxf handling in fc (and using ezdxf is for sure giving an ahead start in such endevour..., incorporating on the fly cleaning options in such endevour would be the icing on the cake
)
for the other dxf, just briefly looked into that one, it is of a different anatomy, so the path outlined here does not work, one would have to find different ways. one of those ways can be libreoffice (draw), which also has a capable and swift dxf-reader and writes svg, so that can be used instead of inkscape, but even if doing that the svg import breaks in fc, it stumbles on creating a zero-length line - that is seems like a fc bug that could be fixed if someone took that on...
at last, massive kudos to the author of ezdxf - time to start using it in fc?
ps: running ezdxf gave an import error to begin with for me, turned out that the reason was a too low version of type_extension, so upgrading that allowed for a clean import of ezdxf