Previously the snap points computed for oval pads didn't get all the
points correct. This breaks out the "find snap points for ovals"
into a function, reworks the logic, adds some tests.
Also adds "extremum points" when the oval isn't exactly H/V.
Fixes: https://gitlab.com/kicad/code/kicad/-/issues/15594
Using the new ITEM_MODIFICATION_ROUTINE system, drop in two new
tools: chamfer and line extend. These are two geometric operations
that are relatively common when editing footprints in particular.
Chamfer delegates the geometric calculations to a dedicated unit
in kimath/geometry.
Its members can be on copper layers, but the group itself isn't on any
layer.
Also fixes a bug where we were trying to clone TRIANGULATED_POLYGON::TRI
shapes as indexable sub-shapes. (The TRI only has indexes into its
parent, so cloning it will only result in segfaults down the line.)
Also fixes a bug where we weren't including copper items inside groups
when checking footprint net ties.
Fixes https://gitlab.com/kicad/code/kicad/-/issues/15021
1) Also reorders parameters to make sure the compiler helps out.
2) This also makes it harder to mess up the discrepency between
BOX2I/wxRECT/etc::Inflate() and SHAPE_POLY_SET::Inflate.
3) Also fixes a couple of bugs where the corner strategy was passed
in as a segCount.
4) Also fixes a couple of bugs where the error wasn't forced to the
outside to match the ERROR_LOCATION.
5) Also fixes a couple of bugs where the seg count was specified
without regard to an already passed-in max deviation
1) Don't fracture font glyphs when generating them; we're going
to fracture during triangulation anyway.
2) Don't check for self-intersection when deciding to fracture.
It costs nearly as much as the fracture does.
3) Cache drawing sheet text.
4) Use the current font when checking for cache validity.
5) Parallelize glyph triangulation.
6) Don't invalidate bounding box caches when offset by {0,0}
7) Use the glyph cache when generating text effective shape.
8) Short-circuit NormalizeJustification() if its center/center.
9) Don't triangulate for GuessSelectionCandidates()
10) Avoid sqrt whenever possible.
11) Pre-allocate bezier and SHAPE_LINE_CHAIN buffers.
Fixes https://gitlab.com/kicad/code/kicad/-/issues/14303
Adds QA checks to copper sliver tests. Adds the following checks:
- Dot product between two arms (quickly avoids checks for >90°)
- Checks the sliver is convex (area test)
- Eliminates minor slivers with angles that are approximately 0 and ones
with the opposite side width beneath a configurable level
- Updates Clipper2 to fix a couple of jagged edges on inflate
- Adds simplify during zone fill inflation to limit jaggies
Fixes https://gitlab.com/kicad/code/kicad/issues/14549
This library is meant to move non-EDA items (language extensions,
library extensions, etc.) into the lowest-level of our dependency chain.
This library should never depend on anyother non-thirdparty code in the
kicad codebase.
acos(1) returns 0, so this implies infinite segements to get to 0 error.
This is not reasonable but might be encountered in bad arcs or circles
that have 0 radius. Instead of returning infinite or std::max segments,
we limit the error to be at least 1 IU
Rounded line ends when deflating leads to microscopic jags in the
outline that are not visible but add substantial computation time and
minor error when computing polygon offsets.
Instead, the chamfer deflate method prevents these jagged lines by
clipping angles < 90° by the error level. This does not impact deflate
calls where we explicitly require the angles to be maintained
Nominally, the zcode of a vertex is unique. This is not 100% true,
however, as we must interlace two 32-bit numbers into a single 32-bit
number. Sorting needs to account for the possibility that the zcode
will be the same while other elements of the vertex are different. This
commit fixes the broken boolean logic to more clearly handle these cases
Fixes https://gitlab.com/kicad/code/kicad/issues/13867
Just testing a single point to find copper that is outside the board works
until the arc->segment conversion moves the board outline just enough to
have the filled copper slightly (few IU) outside of the converted outline.
Instead, we do an expensive check of comparing the size of the
intersection between the island and the island's intersection with the
board. If the intersection is at least half as large as the original
island, we can say with certainty that the island is inside. The margin
could be much smaller than half but this preserves the intent without
picking an arbitrary number that might be violated
Fixes https://gitlab.com/kicad/code/kicad/issues/13717
The segment iterator creates segments when needed, so using it in a dual
loop creates NlgN more copies than we need. This shifts to a single
copy algorithm that then uses a sorting to preemptively abort the search
once the segments are outside of the search bounding box
Fixes https://gitlab.com/kicad/code/kicad/issues/13191
If the poly set is self-intersecting, the triangulation may be
problematic and the full set needs simplification before. We don't do
this uniformly because the simplification can be a slowdown if it is not
needed
Fixes https://gitlab.com/kicad/code/kicad/issues/12806
For unknown reasons, Clipper2 only returns Paths structures from the
ClipperOffset::Execute routine. Further, the Paths are not properly
ordered (outline->hole in outline, outline2->hole in outline2).
To get proper hierarchy, we need to run an additional pass of the
solution with the paths as Subject in a null union. This is effectively
a Simplify() call but we keep the data in Clipper format to reduce the
churn/calc time
Some clipper cases do not get resolved with the `FAST` mode, so in those
cases, do a second pass in the `SIMPLE` mode. If both fail, return a
broken polygon instead of an infinite loop
Fixes https://gitlab.com/kicad/code/kicad/issues/12761
In Clipper1, we had a flat tree structure on returns. Clipper2 nests
these, so we need to properly handle the nesting structure when
importing the polygons
Currently this lives behind the advanced config flag `UseClipper2`.
Enabling this flag will route all Clipper-based calls through the
Clipper2 library instead of the older Clipper. The changes should be
mostly transparent.
Of note, Clipper2 does not utilize the `STRICTLY_SIMPLE` flag because
clipper1 did not actually guarantee a strictly simple polygon.
Currently we ignore this flag but we may decide to run strictly-simple
operations through a second NULL union to simplify the results as much
as possible.
Additionally, the inflation options are slightly different. We cannot
choose the fallback miter. The fallback miter is always square. This
only affects the CHAMFER_ACUTE_CORNERS option in inflate, which does not
appear to be used.
Lastly, we currently utilize the 64-bit integer coordinates for
calculations. This appears to still be faster than 32-bit calculations
in Clipper1 on a modern x86 system. This may not be the case for older
systems, particularly 32-bit systems.
SHAPE_ARC::IntersectLine() fails when one of the arcs start points
is on the center point of the other -- in this case we can't extend
the line to the arc intersection because one point does not define
a line....
Fixes https://gitlab.com/kicad/code/kicad/issues/12609
Oh dear, there was a bunch going on here. Firstly the move from int
to long long int for ValueFromString() means that we were no longer
catching overflows (as we were C-style casting it back to int in many
places). But even when the overflow is caught, it would run in to
wxWidgets' empty string bug while trying to log it.
Fixes https://gitlab.com/kicad/code/kicad/issues/12577
The hash table for integer hashes is extremely limited and places most
elements in the same buckets. This leads to a linear search time for
structures built on this.
This blocks hashes, directing the coder to utilize std::set or std::map
structures instead of hash tables for implementing integer-based
lookups.
1) Move a bunch of std::map's to std::unordered_map to get constant-time
look-ups
2) Lengthen progress-reporting intervals to spend more time doing work
and less time talking about it
3) Reverse order of SHAPE_LINE_CHAINs in thermal intersection checks to
make (much) better use of bbox caches
4) Don't re-generate bboxes we already have
5) Fix some autos that weren't by reference (and were therefore copying
large datasets)
6) Rename delta progressDelta so it's easier to search for in future
7) Get rid of a few more autos (because I don't like them)
8) Pass large items to lambdas by reference
Fixes https://gitlab.com/kicad/code/kicad/issues/12130
The change in c9c31fcbc2 missed a number of cases. This reverts back to
the system as it existed before 2be352b9f9
but using the revised method of determining A-B-C distance and avoiding
resizing the arrays
(cherry picked from commit 675a5a6e7b)
Fixes a slowdown caused by erasing elements from the middle of a vector
during a hot loop in SHAPE_LINE_CHAIN::Simplify(). This gets called
quite a bit when loading boards and updating lines, so it needs to be as
fast as possible
Fixes https://gitlab.com/kicad/code/kicad/issues/12115
(cherry picked from commit c9c31fcbc2)
Placing via in walkaround mode and colliding with an arc triggered an
unneeded assertion.
Also fixes the bad assertion format that did not receive strings
(cherry picked from commit df9cf0a0c3)
In addition to showing resolved clearance, we also show the calculated
clearance in the same method as is used for DRC. This will allow users
to better examine their system while working.
Fixes https://gitlab.com/kicad/code/kicad/issues/7934
The fractional part of Altium schematic units is an integer number of
1/10000 mil segments, which is 2.54 nm. The internal unit of eeschema
is 10 nm, so each fractional unit in Altium is 0.254 base eeschema
units. To be consistent with
cf33cfcad1
we round to the nearest 10nm for each element
Fixes https://gitlab.com/kicad/code/kicad/issues/11742
We now test the midpoint (B) of the 3 consecutive polyline points (A, B, C), since (assuming the angle between AB and BC is > 90 degrees) AC is always longer than
AB or BC. This minimizes the distance computation rounding error (in the previous algorithm, taking the point C for colineraity test) if AB is short and BC is very long, the test would
often fail due to rouding error in projection/line distance computation
jean-pierre charras
Alex Shvartzkop
John Beard
Josue
Jon Evans
Marek Roszko
Jeff Young
Roberto Fernandez Bautista
Seth Hillbrand
Kuba Sunderland-Ober
qu1ck
Tomasz Wlostowski
Ian McInerney
Nimish Telang
Ian McInerney
Vincenzo Fortunato
Jonathan Haas
Marco Langer
Mike Williams