If the last three points of a tesselation are concave, we will never be
able to triangulate them. They were likely formed from a bad polygon,
so we will drop the triangle and return completed
Fixes https://gitlab.com/kicad/code/kicad/issues/9380
Changes a dot to be a square pixel (linewidth x linewidth). This allows
the removal of IU dependencies and ensures that a dot is always visible
on screen. Also makes sure that cairo is setting the current linewidth
during its stroke routines
Fixes https://gitlab.com/kicad/code/kicad/issues/9362
- allows setting a minimal seg count for circles and rounded end segments.
- When using ERROR_OUTSIDE, ensure the arc correction is the actual value
needed by the segment count, not the max value allowed
This ensures that the arc shapes remain correct after removing
a point belonging to an arc or inserting a point in the middle
of an arc.
Simplify implementation of Replace( ..., aP ). Now a Remove
operation followed by an Insert operation.
Improve QA test for SHAPE_LINE_CHAIN Append, Insert and Replace
Implement SHAPE_LINE_CHAIN::splitArc to break up an arc into two
Implement SHAPE_ARC::ConstructFromStartEndCenter and add qa test
m_shapes now has two possible indices. The first one is populated if
the point is associated with an arc and the second index is populated
if the point is shared between two arcs.
- Some are related to shape errors when the allowed error to approximate circle
by segment is large and arc radius small.
- fix the actual error used in ConvertToPolyline().
- Use SHAPE_ARC::DefaultAccuracyForPCB() instead of a fixed value as extra margin
in zones. It should not change something, because it is also a fixed value
(5 micrometers), but it is not a magic number.
-TransformArcToPolygon() fix some issues and add a new algo, based on the arc actual
outline shape (initial algo is still available in code, just in case).
Note also the transform is still not good: the same parameters are applied
to convert inner arc, outer arc and middle arc of a thick arc to segments.
But these parameters depend on arc radius (or circle radius) value.
This was leaking windows headers and partial wx headers to 1084 compilation units......
This also means math/util.h is leaking to 1084 compilation units which seems a bit high too.
Use the connecting straight tracks even if not exactly parallel - allow
an error margin configurable in ADVANCED_CFG (default 1 degree). Also
be less strict about end point matching and use the width of the track
as the criteria to determine suitability.
Finally, delete any short lengths of track at the end of the operation
and amend the arc end points to keep connectivity.
Fixes https://gitlab.com/kicad/code/kicad/-/issues/7967
Is some cases a created pad stack name had the same name as an other pad stack
having a slightly different shape, thus creating pads with a incorrect shape on board.
Fixes#6495https://gitlab.com/kicad/code/kicad/issues/6495
This fixes some DXFs imports where unforunately CAD tools like SolidWorks
randomly decide to mirror circle definitions across the "z" axis (resulting in x or y axis flips in 2d)
Most likely live projection from 3D to 2D drawings introduces this.
However this is DXF specification to describe it so obtusely with vectors for a 2d drawing.
Start, mid and end are the "real" properties and come with less
error.
Also collapses two arc polygonization routines into one.
Also fixes DRC checks to be cognizant of arc approximation error.
Fixes https://gitlab.com/kicad/code/kicad/issues/6039
The snap obeys only the Ctrl key and not the global preference setting
for drawsegments because rectangles are _always_ on H/V lines when drawn
Fixes https://gitlab.com/kicad/code/kicad/issues/5607
1) For a while now we've been using a calculated seg count from a given
maxError, and a correction factor to push the radius out so that all
the error is outside the arc/circle. However, the second calculation
(which pre-dates the first) is pretty much just the inverse of the first
(and yields nothing more than maxError back). This is particularly
sub-optimal given the cost of trig functions.
2) There are a lot of old optimizations to reduce segcounts in certain
situations, someting that our error-based calculation compensates for
anyway. (Smaller radii need fewer segments to meet the maxError
condition.) But perhaps more importantly we now surface maxError in the
UI and we don't really want to call it "Max deviation except when it's
not".
3) We were also clamping the segCount twice: once in the calculation
routine and once in most of it's callers. Furthermore, the caller
clamping was inconsistent (both in being done and in the clamping
value). We now clamp only in the calculation routine.
4) There's no reason to use the correction factors in the 3Dviewer;
it's just a visualization and whether the polygonization error is
inside or outside the shape isn't really material.
5) The arc-correction-disabling stuff (used for solder mask layer) was
somewhat fragile in that it depended on the caller to turn it back on
afterwards. It's now only exposed as a RAII object which automatically
cleans up when it goes out of scope.
6) There were also bugs in a couple of the polygonization routines where
we'd accumulate round-off error in adding up the segments and end up with
an overly long last segment (which of course would voilate the error
max). This was the cause of the linked bug and also some issues with vias
that we had fudged in the past with extra clearance.
Fixes https://gitlab.com/kicad/code/kicad/issues/5567
Partititioning small polygons causes excessive partitions when we use a
fixed number of cells per side. Partitioning by size keeps the
partition count limited and speeds the calculations.
Also adds an option to not partition the grid for elements (like 3d
raytracing) that do not need it.
Fixes https://gitlab.com/kicad/code/kicad/issues/5579
This implements a copper-layer RTree with functions for iterating over
the elements in a copper layer and providing Nearest Neighbor returns
for BOARD_CONNECTED_ITEMS
1) An actual distance of 0 is still a collision, even if the allowed
distance is 0.
2) Be consitent about edges and interiors. Everyone expect the edge
of a RECT to be part of the RECT; same with a CIRCLE. SHAPE_POLY_SET
shouldn't be any different. (And SHAPE_LINE_CHAIN was a split-
personality with the edge considered part of it for Collide() but not
for PointInside()).
There were a lot of plotters, exporters, etc. that were rolling their
own implementations.
This also introduces a lazily-built set of SHAPE objects for doing
collision detection and some forms of rendering (and later DRC).
Dragging filled zones in OpenGL was extremely slow due to the
invalidated triangulation cache. Moving the zone should also move the
triangles and keep the cache valid.
The hittest needs to use distance calc rather than squared distance.
This also adjusts the radius value to be double as to avoid unneeded
loss of precision
The arc shapes need to connect with their adjacent points. By storing
the relevant points, we allow exact point matching on both ends of the
arc as well as localize point storage.
Previously, all overlapping polygons (pads and min thickness areas to remove) were
merged.
Drawback: pads attributes are lost. In Gerber this is annoying.
Now the pads are plot as flashed or Regions items, and min thickness areas are added
but shapes are not merged and keep their attributes.
This only tests the InterceptsPositiveX() and InterceptsNegativeX() used
for finding the midpoint of an arc.
Tidy up some of the trigo.h header Doxygen comments.
Johannes Pfister
jean-pierre charras
Jeff Young
Seth Hillbrand
Roberto Fernandez Bautista
Wayne Stambaugh
david-beinder
Jon Evans
Marek Roszko
luz paz
Tomasz Wlostowski
Thomas Pointhuber
Marcus A. Romer
Dominik Wernberger
Mikolaj Wielgus
hoijui
Simon Richter
Ian McInerney