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
We can't know that all holes will be ccw when entering unfracture.
Instead, we set the largest polyline to be the outline and the others to
be the holes.
(cherry picked from commit 1fe956c069)
Mainly CacheTriangulation() was creating triangles using partition mode.
But this mode is optimized for Pcbnew and Gerbview and different internal units.
Now CacheTriangulation() is used in no partition, much faster in GERBVIEW_PAINTER.
Fixes#11549https://gitlab.com/kicad/code/kicad/issues/11549
This also fixes a failure to use the correct effective width for
shapes (which might, for instance, inherit their widths from schematic
defaults, netclasses, etc.).
Fixes https://gitlab.com/kicad/code/kicad/issues/11358
Inflate with linked holes needs to account for fractured polygons,
otherwise inflating with positive value will create rounded divots where
overlapping fracture lines meet and inflating with negative value will
create spaces between fracture lines.
Calling Simplify before Inflate takes an inordinate amount of time as
the Clipper healing routine is rather slow. Our own Unfracture is meant
to heal the results of our Fracture routine and works much more quickly.
After healing, we still call the Simplify routine
(cherry picked from commit 9ca35cbcee)
Clipper can handle complex input polygons but we will sometimes struggle
dealing with outputs from the inflate routine that have degenerate or
overlapping points. Calling Simplify after the inflate keeps our
polygons easier to handle
Fixes https://gitlab.com/kicad/code/kicad/issues/11036
(cherry picked from commit a24cdcb3f0)
Since we use center points to move back and forth for angle and
adjustments, we want to ensure that our center point is stable.
Rounding using integers introduces a 0.5 int uncertainty in each
measurement. These are combined together multiple times to calculate
the center point, which combines the uncertainty. Propagating the
uncertainty to the final calculation allows us to assign a range of true
values and pick the value that is most likely the correct value.
Fixes https://gitlab.com/kicad/code/kicad/issues/10739
1) Generate SHAPE_POLY_SET triangulation by outline so they can be
shared between connectivity system and other clients.
2) Don't add items to connectivity when reading board; we're going
to do a total rebuild anyway.
3) Use multithreading when caching triangulation.
Mac and some Linux configs disable menu icons. We shouldn't offer the
option when the system does not support this as it leads to confusion
Fixes https://gitlab.com/kicad/code/kicad/issues/10425
Handles checking output of the arc to ensure we don't end up generating
an invalid arc. Also keeps the limit of the arc angle to be (360,360)
excluding 0.
Fixes https://gitlab.com/kicad/code/kicad/issues/10070
(cherry picked from commit 8fc831cbc2)
Test should not be testing against the polygonization error; if done
correctly that should all be on the correct side of the shape. Use an
epsilon instead (I chose polygonization error / 10, but the value isn't
terribly important).
Fixes https://gitlab.com/kicad/code/kicad/issues/10724
The existing algorithm nicely handled the error being on the inside (where
the segment ends are error-free), but not when it was on the outside (where
the segment midpoints are error-free).
In any case, we want error-free points at each end of the arc so we don't
get ears or divots.
We do no track all the various possible issues arising from using
unbundled Mac apps. Users may choose to use KiCad this way but issues
must be recreated on a supported configuration
(Conversion was upside-down.)
Also fixes bugs with rotation angle increment not getting units
set and with a 0 footprint editor value overwriting a non-zero
pcb editor value (or vice versa).
Includes bug fix for catastrophic error in Add() for converting to
radians.
Includes bug fixes for the fact that the pcbnew test can't seem to
find the ANGLE_* objects (getting all 0's instead).
1) Unify metrics between stroke and outline fonts
2) Unify handling of rotation and mirroring
3) Bug fixes in collision handling
4) Use of VECTOR2I (instead of VECTOR2D) for world-coordinates
5) Generate outline font overbar with rounded ends and fix rotation
bugs
6) Generate wxEVT_CHOICE events from FONT_CHOICE::SetFontSelection
7) Change text-item PNS SOLIDs to use compound shapes
This one is primarily about pushing TEXT_ATTRIBUTES in to the GAL
API, but it also includes adding EDA_ANGLE signatures to some trig
routines to ease integration.
ADDED arc, circle and rectangle shapes for schematic. Shapes support
line styles and fill colors.
CHANGED sheet background color in Edit Text & Graphics Properties to
fill color (and it now affects shapes).
Pushed STROKE_PARAMS down into common and moved all shapes to using it
for stroke descriptions.
The arc2segment collision should at also include the arc endpoint projections on the segment being tested. Not sure it covers all possible cases, though.
Fixes: https://gitlab.com/kicad/code/kicad/-/issues/9023
Clipper might mess up the rotation of the indices such that an arc can be split between
the end point and wrap around to the start point. Detect if this happened and fix it as
required.
Also, handle arcs at the last segment of the chain correctly, meaning we can have arcs
towards the end of the chain that finish at the starting point of the chain.
Fixes https://gitlab.com/kicad/code/kicad/-/issues/9670
Boolean Ops on polygons with arcs are not supported (the only exception
is Simplify)
Also fix a bug in SHAPE_LINE_CHAIN::splitArc that resulted in an
exception
Partially fixes https://gitlab.com/kicad/code/kicad/-/issues/9380
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
We are not always sure of the path validity in fracture. Nominally, the
Clipper Simplify routine should remove invalid parts but in the case
where it doesn't, we need to recover gracefully, even if the output
polygon is not valid.
Fixes https://gitlab.com/kicad/code/kicad/issues/9199
Also removes the return value from the BITMAP_STORE's themeChanged
method as it will provide the wrong answer for the second frame it's
called on.
Also hooked up ACTION_TOOLBAR, the app launcher, and the project tree
to the wx event for system color changes so they change on the fly.
Fixes https://gitlab.com/kicad/code/kicad/issues/6026
- 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
The algorithm relied on the assumption that the points were
ordered anti-clockwise. When ordered in a clockwise fashion, the
result was correct but negative.
Refer to https://www.mathopenref.com/coordpolygonarea2.html
for more information.
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.
The error between the "right" shape and the polygon is slightly smaller.
The approximations of the inner arc and the outer arc are better, but not perfect.
Also add (for test and debug purpose only) the code to show the polygon when
drawing a PCB_ARC (currently disabled)
Arcs with small radius can be approximated with very few segments.
However, if the thickness is large, relative to the radius, the approximation
must be based on the external radius, not the arc radius.
The difference can be significant.
This is especially noticeable for these graphic arcs in filled zones.
When running a python script is run from a console, outside Kicad, a wxWidgets
alert was always show (even in release mode)
This is due to calling wxStandardPaths::Get() with no wxApp open( i.e. wxTheApp == O)
The fix uses a dummy wxApp in this case.
Segment approximation for arcs leaves small "indents" where the rounded
edges of two segments don't quite meet.
This gives closer approximation by calculating the inner and outer joint
points based on the radius, eliminating the indents.
Jeff Young
Seth Hillbrand
Tomasz Wlostowski
Alex
jean-pierre charras
Mark Roszko
Jonathan Haas
Roberto Fernandez Bautista
Marco Langer
Mike Williams
markus-bonk
Wayne Stambaugh
Ola Rinta-Koski
Simon Richter
Jon Evans
Johannes Pfister
david-beinder