Circles vs BSplines depending on view scale

[alivetechs]

Hi,

I imported a DXF from another app (Illustrator) that contains true circles. When I create a view, depending on the view scale, some circles appear in TD as true circles (the small ones), whereas others (the larger ones) appear as BSplines. I get the center-marks and can insert "diameter dimensions" when the circles appear as a real circle, but otherwise I don't get any center-mark and trying to insert a dimension yields "selected edge is a BSpline. Diameter will be approximate. Continue?" and when I do, I only get a zero dimension not even centered on the BSpline itself, complete fail.

I could live with that but here comes the strange part: if I scale my view down enough such that all circles are small, they all get their center-mark and are all treated as circles than I can dimension. If I scale my view up, then even the small circles become BSplines and I don't get any center-mark anymore and can't add any diameter dimension.

It's a bit puzzling. I thought I could cheat by scaling down the view, adding diameter dimensions everywhere, then scaling the view back up, but when I do of course all dimensions are screwed up and have to be redone, so it doesn't work at all.

Any hint you could give me? I guess I could maybe re-draw all circles in FC directly but it's extra work.

PS: when I "toggle frames" my circles all appear with a single handle at the 3'o'clock location, as seen in attached pic, so they are apparently perfectly round (and were created perfectly round in Illustrator before export)

>> Tested on FC 0.20-beta1 but was on 0.19 prior to that. Win64 build.

[M4x]

Welcome to the forum!

Please post your full FreeCAD version information and an example file: http://forum.freecadweb.org/viewtopic.php?f=3&t=2264

[alivetechs]

Sure! I'm on version 0.19 but the behaviour is the same in 0.20-beta1.

OS: Windows 10 Version 2009
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.24276 (Git)
Build type: Release
Branch: releases/FreeCAD-0-19
Hash: a88db11e0a908f6e38f92bfc5187b13ebe470438
Python version: 3.8.6+
Qt version: 5.15.1
Coin version: 4.0.1
OCC version: 7.5.0
Locale: French/France (fr_FR)

In the attached example file, I took a simplified DXF import, created a page then added the view twice. The second view is scaled down to 0.15 and as you can see on the left the large holes don't have the center-mark and are interpreted as BSplines, whereas on the right the same holes become proper circles and can be dimension'ed correctly.

Maybe this is the expected behaviour, I don't know. But I can't add diameter dimensions or dimensions from hole centers in the left view.

PS: also notice how in the 19 holes on the left view (which are cloned copies in Illustrator using the Rotate tool), 4 of them don't have the center-cross, but if I scale down that view to 0.60, they all get their cross properly.

[Roy_043]

All circles in the file appear to be BSplines.

To verify:
Select a Shape in the Tree view.
Use the Ctrl+Shift+P shortcut (to invoke Std_SendToPythonConsole).
Enter sub.Curve in the Python console.
Result: <BSplineCurve object>.

My guess is that the DXF in fact does not contain true circles. You can check the DXF by looking for the word "CIRCLE" or post it for inspection.

Why some of the shapes get a center-mark and others don't is beyond me.

[heda]

maybe Macro_HealArcs works (if not it should be made to work...)

[wandererfan]

If I scale my view up, then even the small circles become BSplines and I don't get any center-mark anymore and can't add any diameter dimension.

As pointed out earlier, the "circles" are BSplines. The code that tries to interpret the BSpline as a circle has a tolerance factor that isn't adjusted for scale, so that's why you get different results at different scales.

If the Dxf file does in fact specify circles, then we'll have to look for a bug in the Dxf importer.

[domad]

....

Hi alivetechs, greetings to the Community!
As stated by @wandererfan there may be a problem with FC's * .dxf importer.
Have you tried to import your * .dxf file with eg "LibreCAD" (or other cad)?
If the result was positive (correctly imported) then in FC you have to try different settings in "Preferences" -> "Import / Export" -> "DXF" panel, if in no case the import gives a positive result then there is it is really a problem in the FC importer.
If the result is not positive in another cad / s, then the problem lies in the "Illustrator" exporter.
Attached is the file in which the splines have been converted into arch chains using the @edi macro "Convert_Sketch_Spline_to_Sketch_Arcs_chain".
I advise you to attach the file in * .dxf for a more careful verification.

[alivetechs]

First of all, I'd like to thank you all for the warm welcome and for the prompt answers to my little issue!

@Roy_043: indeed not a single occurrence of the "circle" word in that DXF file. The Illustrator tool is called "ellipse" and holding the modifier key just creates an equality constraint for the X and Y dimensions, so it makes sense that everything could be represented as splines. But when I try to export the same file as SVG, then the same objects are properly imported as circles in FC (and I get the center-marks). Sadly I get other kinds of weird issues using this format, like the scaling being completely off and other strange things I'll need to investigate...

@heda: thank you, but trying that macro produced odd results (all the large circles, precisely the ones that did not get a center-mark, transformed into gigantic ones randomly placed... let's say that it did not go as expected!

@wandererfan: any way I could force them to be interpreted as circles maybe? Because when they fall into said tolerance factor, I'm able to dimension them perfectly fine. Side question: is it normal that when I try to dimension them as splines I always get a dimension of zero appearing completely off in the center of the view? (sure there is a warning telling me the diameter will be approximate, but here it simply fails in the end I think)

And it's also puzzling that in the first view, all 19 small circles that are supposed to be identical, sometimes fall into the tolerance and sometimes not nope? I tried to see if there were minute differences between them but could not find any clear pattern explaining what is happening.

@domad: I believe Illustrator DXF export is rather crappy. I had to try nearly all settings combinations before managing to get something to import properly in FC. Actually I had to force the oldest DXF version (R13/LT95) otherwise the global scale was completely wrong. When I import my file in LibreCAD, all circles look like deflated balls... or potatoes. There's clearly something not right with the way those circles are exported.

Thank you for your work on improving Edi's macro suite, which I just downloaded and did not know existed prior to that. But pardon my ignorance, as after looking everywhere (and even searching through the code itself) I'm not able to find the conversion function you mention. Google and this forum search features are not helping either. Could you please tell me how I could perform the same conversion you did?

-

Anyway this is overall just a minor annoyance and I found a "cheat workaround": I opened TD preferences dialog, copied the symbol used for diameters, added "extent dimensions" to my non-circles, then set the dimension format to "arbitrary" and pasted the diameter symbol and the known numerical dimensions. Not as pretty as a genuine one, but good enough!

The problem appears to be on Illustrator's side and TD is most probably performing as designed!

[heda]

yeah, HealArcs gave interesting results...
and shuffling anything cad related between programs is in general annoyingly cumbersome (the forces dragging it that way are strong...)

afaikt, turns out that there is a bug in one of the draft functions used...
someone brave might come around to fix that bug in src based on the below

Code: Select all

# useless result HealArc.FCMacro
# originating from Draft function

import Part

# relevant conversion code called from HealArcs
# mod/draft/arc.arcFromSpline(edge)

def arcfromspline(edge):
    # circle
    print('where wrong?')
    p1 = edge.Vertexes[0].Point
    print('fcn p1', p1)
    ml = edge.Length/2
    print('fcn length', edge.Length)
    p2 = edge.valueAt(ml)
    print('fcn p2', p2)
    print('it is wrong to use length to pick up p2..., is this api-change? occ-change?, think neither...')
    print('fix is to use parameter instead')
    midpar = (edge.LastParameter - edge.FirstParameter) / 2
    # will only work if first par is the only one being negative...
    p2 = edge.valueAt(midpar)
    ray = p2.sub(p1)
    ray.scale(0.5, 0.5, 0.5)
    center = p1.add(ray)
    print('fcn center:', center)
    radius = ray.Length
    print('fcn radius:', radius)
    try:
        return Part.makeCircle(radius, center)
    except Part.OCCError:
        print("couldn't make a circle out of this edge")
        return None


for x, y in ((5, 5), (-5, 5), (-5, -5), (5, -5)):
    print('==== {}, {} ===='.format(x, y))
    c = Part.makeCircle(4, App.Vector(x, y, 0))
    Part.show(c.Curve.toShape(), 'circle')
    cv, = c.Vertexes
    print(c.Curve)
    print('circle vertex:', cv.Point)
    print('circle length:', c.Length)
    s = c.Curve.toBSpline()
    print('spline start, end:', s.StartPoint, s.EndPoint)
    sh = s.toShape()
    Part.show(sh, 'spline')
    sv, = sh.Vertexes
    print(sh.Curve)
    print('spline vertex', sv.Point)
    print('spline length', sh.Length)
	
	
    arc = arcfromspline(sh.Edges[0])
    Part.show(arc, 'spline2arc')
    arcv, = arc.Vertexes
    print('converted', arc.Curve)
    print('converted vertex', arcv.Point)
    print('converted length', arc.Length)

if you want to help yourself, the above code (although solely used to hone in on where things went wrong) together with what is already in HealArcs should allow you to put together a working macro until someone has fixed it in src.

wonder if this is behind some of the ridiculously large arcs one from time to time can observe when playing around with dxf-imports, or it might just be that it draws the sector of the arc that should not be drawn (and skips the sector that should be drawn).

[Roy_043]

@heda

For a general midpoint function see:
https://github.com/FreeCAD/FreeCAD/blob ... #L166-L171

This may also be of interest:

Code: Select all

edge.Curve.toBiArcs(0.1)