Polylines with arcs.

Creating polylines with arcs has from V1-V7 created the left pattern when hitting Point1 ,P2, P3....... great. See pic .

When in V8+ it creates the right hand pattern hitting the exact same Points.

Can someone explain to me who on Earth has a use for this. Either this is a bug or its a compatibility issue that seems totally useless. Pls explain.

Cheers Patrik

Comments

  • Ahhh the right hand result can be acheived by hitting arc/entre, line/enter, arc/enter ....... but Before you just hit arcs once.
  • Seems to me that P4 is not he same in the right hand result...
  • This is done in the exact same manor .  Left V1-7 right V8+ picked on a grid 150x150.

    Polyline then hit P1 ,P2 arcs P3 , P4 , P5 ...

    I just dont see any use for the new random behaviour (its not random but repetable) . I could make use of the old way but hitting Line/enter,arc/enter etc all the time makes it useless. Its a definite regression but maybe someone can give me an explanation as to how this can be useful because I can´t see it. I see no way in predicting outcome.

  • OK. I understand the issue now. I agree that the 'Old' behavior is nicer and more predictable. I can only assume that this is a compatibility issue. Maybe you should send in an SR.
    FWIW: In my tests I get different results. And I never get a straight segment between P3 and P4.
  • I can't repeat the right hand side example. Only time I get something like this is if I forget to alternate between the Arc and Line option in PLINE.

    The following code will alternate between drawing line and arc segments within the polyline. Always starts with a line segment, then moves to arc etc.
    Note this is pretty crude, don't try overriding options while in use.
    [code];Alternates between drawing a line and arc segment
    (defun C:PolyLineArc ( / p1 opt)
        (setq p1 (getpoint "\nPick a start point"))
        (setq opt "_L")
        (if p1
            (progn
                (command "._PLINE" p1 pause)
                (while (wcmatch (getvar "CMDNAMES") "PLINE")
                        (setq opt (if (= opt "_L") "_A" "_L"))
                        (command opt pause)
                )
            )
        )
    )[/code]

    Regards,

    Jason Bourhill

    CAD Concepts


  • I don't remember the behavior being different (pline; arc; line; etc), but after about V10 if you try to draw something like that using a lisp routine with esnap set to non-nil the results are likely to be similar to that shown on the right.
  • I don't think this has anything to do with (e)snap, ortho or polar, let alone with compatibility - the arc mode simply looks completely broken.
    Just try something like this:

    : pl
    ENTER to use last point/Follow/: 0,0
    Arc/Distance/Follow/Halfwidth/Width/: 0,10
    Arc/Distance/Follow/Halfwidth/Width/Undo/: a
    Angle/CEnter/CLose/Direction/Halfwidth/Line/Radius/Secondpt/Width/Undo/: 2,10
    Angle/CEnter/CLose/Direction/Halfwidth/Line/Radius/Secondpt/Width/Undo/: 2,5

    Quite astonishing that such basic defect could go undetected for so long (v11 on linux already had it)...

    You just might argue that AutoCAD's polyline implementation is so shitty anyway that it would be a waste of resources to recreate it fully. To do things at least partially better, I think that if the user enters arc mode but inputs data that would result in an arc with zero bulge, the program should detect this and draw a straight segment instead, without leaving arc mode.
  • Roy , as you say, and that I added, you have to hit arc, line,arc...  not very convenient.   Jason, Thanks the script does the trick. I still don't see the use for the "new" std behaviour its just strange.  John having now played with this even more I get even stranger results .Check this one. Points 1-10 choose polyline pick P1 and p2 then arcs and keep picking the points. Red one first snapgrid 150x150 ,no ortho, no others snaps Version up to 7 . from v8 alter between arc/line same result. Then yellow no grid, orto on, endsnap on and superimposing the points. Finally Ortho off  grid off, nearest snap on , same points. As I'm not 100% angular  it resembles the red one.

    imagePoly2.jpg
  • So to summarise, issue occurs when you try placing consecutive arc segments? Certainly looks like there is something not right with this, particularly for the second consecutive arc segment following on from a line segment.

    I wrote a few LISP functions to test PLINE with arc segments. results are interesting. BricsCAD doesn't necessarily obey the coordinates given. Testing in another popular cad application gave quite different results, although it still tripped up on the first arc segment following a line segment. De-curving the generated PLINE should show the underlying coordinates given by the LISP functions.

    Attach LISP, dwg, and screen grab for anyone wanting to play.


    Regards,

    Jason Bourhill

    CAD Concepts


    PlineArcs.dwg

    imagePlineArcs.png

    PolyLineArc.lsp

  • @Patrik,

    I have been reminded that there is another method to alternate between arcs and line segments with a polyline (thanks Damian), and that is to use the _FILLET command with the _Polyline option. In the case of a looping line at a 150 spacing you would set you fillet radius to 75 to achieve a semi-circle.

    Not an answer to your bug, but potentially a better workaround.

    Regards,

    Jason Bourhill

    CAD Concepts


    imageFilletPolyLine.png
  • Nice one I never even noticed it was there.

    THANKS / Patrik

This discussion has been closed.