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
1) Tests can't expect accuracies around 1 to work. PCBNew defaults
to 5000.
2) Tests shouldn't artifically expand tolerance just to match the
results.
3) Tests should guarantee that end point is on arc, not just close
to it.
4) Standard polygonization of a circle is inside so splitting the
error needs to increase radius, not decrease.
5) Special-case first and last points so that they're exact.
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
Previously, SHAPE_POLY_SET::CacheTriangulation() was able to handle polygons
with holes.
Due to recent changes, CacheTriangulation( true ) handle polygons with holes,
but CacheTriangulation( false ) did not handle polygons with holes, due to a
missing call to Fracture(), lost in latest changes.
This is now fixed.
Fixes#5606https://gitlab.com/kicad/code/kicad/issues/5606
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
When loading footprints, we need to skip the triangulation trigger in
rotate. If the triangulation cache is invalid when starting the
rotation, do not retriangulate after the rotation.
The use of printf, wxLogDebug, and std::err/std::out causes excessive
debugging output which makes finding specific debugging messages more
difficult than it needs to be.
There is still some debugging output in test code that really needs to
be moved into a unit test.
Add debugging output section to the coding policy regarding debugging
output.
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
A 360° arc will have the mid point on the opposite side of the circle
from both the start and end points. This will make both slopes the
same, leading to a degeneracy in the calculation. We address this by
noting that the center will be halfway between the midpoint and the
start point.
Returning the poly index is not useful as it does not allow the use of
other SHAPE_POLY_SET Hole* functions that expect to get the indices of
holes rather than the outline
the old calculations was creating a slightly too small shape for rounded corners.
Now the polygon is outside the perfect shape (as required to create a shape with clearance)
Fixes#4805https://gitlab.com/kicad/code/kicad/issues/4805
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.
* Implement ReparentQuasiModal for OSX natively
* Implement ForceFocus of OSX natively
This change means we no longer rely on the kicad-specific functions in our osx wx fork.