kicad-developers team mailing list archive
Mailing list archive
Re: Arc Adjustment proposal
Welcome back! Start-center-end is under constrained and requires the
additional knowledge of which direction the arc is going.
The center point in my proposal will still be user-adjustable and
snappable, just not stored in the file where we write floating points
values instead of ints. Does that address the concern? If not, we
could think about an additional 'direction' parameter.
On 2019-07-10 13:29, Jon Evans wrote:
(back on the internet, slowly reading more emails)
I agree that the storage method should be changed. Thanks for taking
this on, Seth.
I am curious why start-midpoint-end is better than start-center-end,
I think the latter is used more often in mcad tools, although I could
Having a non-rounded center point stored seems like it could be useful
if the center point location is important to the arc geometry (for
example, if it's supposed to be snapped onto another point).
I can't think of why having the mid-angle point being stored precisely
would be as useful.
On Wed, Jul 10, 2019 at 1:26 PM Seth Hillbrand <seth@xxxxxxxxxxxxx>
I'd like to adjust how our arcs are handled and stored. This is
the arc tracks work package but is sufficiently tangential that I
it bears checking before I implement.
Problem: Arcs are stored in the pcbnew file using center, start
and arc angle. This leaves the end point of the arc subject to
errors. This causes problems in STEP export as well as (for the arc
tracks) connectivity issues as dragging requires point matching, not
just copper overlap.
Proposed solution: I would like to adjust the pcbnew file format and
internal SHAPE_ARC, DRAWSEGMENT arc and EDGE_MODULE arc to use a
format consisting of start point, mid point and end point. Mid
here is defined as the point along the arc that is at the half-angle
the full arc.
In this case, the values used and saved for connectivity and edge
continuity will be fixed. The center point of the arc may vary due
rounding issues but arc will remain continuous with its neighboring
segments. Since the mid point of the arc is also saved, we closely
constrain the arc extent as well.
To get the arc center in this case (for drawing/plotting), we would
GetArcCenter() from trigo.cpp.
Does anyone have objections to this course of action? If not, I'll
around the patch for testing before pushing.
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp