Extend object3d_from_contours() to have an option to produce an inverted shell contour

This will be useful when extruding voids within objects during 3D export.

Add void *userdata member to the POLYAREA object

This is intended to allow client code operating on polygons to assign
arbitrary additional data to the polygon contours.

The initial target use-case is in 3D export code, where it is helpful to
have temporary links between POLYAREA contours being extruded and the 3D
object structures being generated. Allowing this tagging directly avoids
the need to maintain a hash-mapping or similar.

Alter cntr_in_M_POLYAREA() to return which POLYAREA which the passed PLINE was found inside.

In the case which previously returned FALSE, where the PLINE was not found
inside any of the linked POLYAREA, the funciton returns NULL.

Subtract vias from ...

Rename PinPoly to PinClearPoly, re-introducing PinPoly to create the shape of the pin.

Debug stuff

Extend object3d code to support arc-segments in POLYAREA contours

Remove left over debug

Disable debug

Copy contour is_round information when copying polygons

Polygon debug

XXX: THIS IS NOT TO BE EDITED, JUST A CHERRY PICKED COPY FOR DEBUG... Add polygon parentage tree debug view

NB: Also contains some probably bug fixes for PBO operations,
in particular - relating to bad exit codes when a NULL poly is
copied.

Debug wonky copper polygon generation

Enable output of via pads, and dial down circular approximation accuracy

Turn off debug hacks in object generation

Re-enable board core emission

Disable small edge EPSILON hack for computing edge normals

Prepend when adding things to lists

hid/step: Add copper layer export to 3D model

Comment object3d_draw_debug() call during expose

Adjust coordinate system GOODNES KNOWS WHETHER THE GEOMETRY IS CORRECT... IDA-STEP SEEMS TO COPE THOUGH

Extend board export

Include emission of soldermask etc..

V2: Apply the solder-mask on top of the board (core) thickness, don't shrink the core to account for it

XXX: SEE BELOW.. Alternative, more thorough STEP export code

This has mostly been copied and refactored from the 3D code in the branch
local_customisation_pcb+gl. They MAY have diverged, and a common history
should be recreated if possible.

Change scroll-wheel bindings to match more GTK applications

Add STEPcode based assembly export function

Add action to reconstruct pins / vias / holes

Add action to break elements to pieces in place

Add name tags for line contours (and provide partial support for arcs)

Add name tags to contours and feature naming for pins and vias in STEP export

step: Fixup for refactored HID / HID_DRAW API

Add simple STEP exporter for the board outline

Fix 3D contour export

Refactor circular contour handling to be more generic

Remove pseudocode for assembly emission

Rework step generation a little

Add wrapper function for appending to GList of step_ids stuffed into pointers.

Avoids casting

And working again (mostly)

Dangling fixup from old way of emitting board contours

Well on the way to completely messing up the STEP code, just by flipping the Y coord!

Attempt to refactor the STEP emission somewhat

STEP changes from continue-tinkering-with-3d

STEP changes from more-play-with-quad-edge-data

STEP stuff from wip-on-quad-edge-play

STEP stuff from play-with-quad-edge-data

Remove object3d test cube and associated debug

Splice a cylinder onto the top of the board outline (hacky test)

Continue tinkering with 3D games

Add reversed orientation field to face3d structure

More play with quad edge data-structures and STEP export

Play with quad-edge data-structure - using PCB as a framework for GL!

Squashes: WIP on quad edge play

Remove debug from outline generation

Temporarily disable rendering short-cut for round contours

This lets us see the underlying approximation and edge data instead.

Revert "Test routine for poly_InvContour"

This reverts commit e1de240da219e7cd5696ed8dde04b0483abd6e54.

Test routine for poly_InvContour

Tag VNODEs with details of circular contour segments

The idea here is to track that the PWL segments actually came from a
particular underlying curve. This should allow us to reconstruct that
curve (approximately at least) if these segments survive in the final
polygon (are not intersected or removed by boolean operations).

The convention is that the curve shape tagging of a vertex corresponds
to the edge spanning this, and the net vertex around the list. (As per
other existing edge related flags).

NB: STILL DOES NOT WORK CORRECTLY IN ALL CASES. SEE:

circ_segs_test4_still_procuces_bad_contour_when_starting_with_arc.pcb

(SUSPECTED BUG IN THE GATHER / JUMP ROUTINES)

Debug rendering for board outline

More debug for circsegs stuff

Unite clearance polygons to compute a board-outline polygon...
Lets us explore operations on more specific basis.

Invalidate board contour when a via / pin is altered

The drill-holes of vias and pins can affect the board contour

Disable polygon heritage

Revert "DEBUG STUFF - looking into bad polygons"

This reverts commit 292c3e44c385e3ca13127339cbfdeda1d7f6587e.

DEBUG STUFF - looking into bad polygons

polygon.h: Reduce circ_segs to 8 for debug clarity

Test poly-curve support

Limit virtual memory size of PCB process to avoid swapping my machine to death!

Sometimes the polygon code exploded...

Add polygon parentage tree debug view

polygon.c: Temporarily disable coalescing adjacent line segments

We need to extend the tests to properly account for arc segments.

Compute the correct boundingbox for a polygon with arc segments.

Temp

Add support for arc segments in polygon object outline definitions

Test with a polygon like this:

  Polygon("clearpoly")
  (
    [5.0000mm 7.0000mm included_angle: 90] [7.0000mm 5.0000mm]
    [28.000mm 5.0000mm included_angle: 90] [30.000mm 7.0000mm]
    [30.000mm 28.000mm included_angle: 90] [28.000mm 30.000mm]
    [7.0000mm 30.000mm included_angle: 90] [5.0000mm 28.000mm]
  )

NOTE THAT THE ARC BOUNDS ARE NOT YET INCLUDED IN THE BOUNDING BOX CALCULATION,
SO THIS WILL BREAK VARIOUS THINGS PRETTY HORRIBLY IF AN ARC PROTRUDES AS AN
EXTREME FEATURE IN EITHER THE +/-X or +/-Y DIRECTIONS.

Fix for arc bounding box calculation split from later patch

This probably wants merging with where the problem was introduced,
but at this moment I've not had chance to review the fix is good.

Refactor arc bounding box calculations to separate out thin case

The thin-arc case will be useful for arc-segments within polycurves.

Fix labeling of contour which ends up as all SHARED / SHARED2, or all UNKNKWN

SHARED / SHARED2 labelling does not propagate, so if this occurs for an entire
contour, the labelling code would loop forever. (Same as if no cross-connected
vertex with definitive INSIDE / OUTSIDE information was found).

Catch when we wrap around the edge list and then decide how to classify the
whole contour. If it is all UNKNWN, we re-classify it as not intersected. The
cntr_label_POLYAREA() routine is adjusted to handle the possibility that the
label_contour() routine for ISECTED contours changes the contour status back
back to UNKNWN.

If the whole contour is SHARED or SHARED2, we leave it as ISECTED, since there
is no handling of that condition for an entire contour. (It will either be
dropped, or re-constructed, depending on the boolean operation being performed).

Remove debug from hairline handling etc..

Fix polygon hairline handling

Refactor hairline edge checks

More work in progress

More debug stuff

Temp attempt to try adding nodes when dealing with the inconsistent edge hairline case

Remove debug from hairline edge code

Work in progress

Try to do something about the hairline edges

TMP

Identify and filter out shared edges within each input polygon after intersecting

Shared-edges can result from snap-rounding during intersection turning distinct
edges with similar slopes into new edges which may share identical portions.

These shared edges then confuse the polygon edge labeling code, which needs to
identify distinct spans of inside / outside each contour. As the edges are
identical, they have ambigous sort-order in the resulting CVCList.

Temporarily disable the circular contour radius adjustment

Was part of adding arc support, now temporarily borrowed for debugging

Allocate VNODE with g_slice_new0, rather than calloc

g_slice should be optimised for lots of small allocations - lets try this..

polygon1.c: Move jump call to bottom of Gather..

We call Gather from Collect1, having in Collect(), established using the j_rule,
that the edge we wish to start with is not marked, and it suitable for inclusion
in the new polygon contour. (Passing what will be the resulting "from" vertex
into Collect1 to start processing).

The first step in Gather was previously a Jump call - which could switch to the
other polygon contour. (Without including our start edge). The key problem here
is that Jump makes the assumption that the vertex it is passed was reached having
been included in the resulting polygon. (It starts inspection of the CVCList from
the assumed entry edge that reached the given vertex).

In our startup condition, the vertex we pass (usually a from vertex, of a FORWARD
polygon traversal of an edge in the 'A' polygon to be included in the resulting
contour), is not necessarily preceeded by an edge on that same source contour that
will end up in the resulting polyon - leading to the possibility that Jump gets
the wrong result. (This is a by-inspection / theoretical issue, not one yet known
to cause any particular bug).

The fix is to include the edge segment we start with, BEFORE calling jump in Collect.
Once our start edge is included, the assumptions made by Jump should hold.

Use g_critical_if_fail rather than assert for edge_label

Attempt to splice in edge_label routine from later in patch series...

This corrects the bogus fix for hairline edges in the previous patch,
simplifying edge_label, but it DOES NOT address how to deal with these
hairline edge pairs.

With debugging on the test-cases causing problem will fail.

With arc radius compensation disabled in polygon.h, the following will
produce hairline edge pairs, and cause problems..

Via[8475.00mil 5575.00mil 40.00mil 30.00mil 0.0000 20.00mil "" ""]

Layer(1 "component")
(
)
Layer(2 "solder")
(
  Line[8425.00mil 6250.00mil 8425.00mil 4475.00mil 25.00mil 30.00mil "clearline"]
  Line[8475.00mil 5575.00mil 8475.00mil 4425.00mil 15.00mil 30.00mil "clearline"]
  Polygon("clearpoly")
  (
    [6350.00mil 6650.00mil] [6350.00mil 4150.00mil] [9050.00mil 4150.00mil] [9050.00mil 6650.00mil]
  )
)

The diff for polygon.h:

diff --git a/src/polygon.h b/src/polygon.h
index a369096..0cba2bf 100644
--- a/src/polygon.h
+++ b/src/polygon.h
@@ -37,11 +37,28 @@
 #define POLY_CIRC_SEGS 8//40
 #define POLY_CIRC_SEGS_F ((float)POLY_CIRC_SEGS)

+#if 0
+/* THIS IS BROKEN:
+ *
+ * IT BREAKS THE CIRCULARITY OF CIRULAR CONTORS, AS THE FIRST
+ * FIRST VERTEX ADDED BY CirclePoly IS NOT RADIUS ADJUSTED.
+ *
+ * IT BREAKS CIRCULARITY OF ALIGMENT BETWEEN A LINE AND ITS END-CAPS,
+ * LEADING TO MORE COMPLEX CONTOURS FOR COMMON LINE-LINE INTERSECTIONS,
+ * SUCH AS 90 AND 45 DEGREE ANGLES
+ *
+ * IT WAS INTENDED TO AVOID DRC ERRORS WITH "TOO-CLOSE" FEATURES,
+ * BUT COULD OTHERWISE CAUSE THEM FOR "TOO THIN" FEATURES - INSIDE/OUTSIDE
+ * CONTOUR APPROXIMATION NEEDS TO BE CONTROLED DEPENDING ON THE REQUIREMENT
+ */
 /* adjustment to make the segments outline the circle rather than connect
  * points on the circle: 1 - cos (\alpha / 2) < (\alpha / 2) ^ 2 / 2
  */
 #define POLY_CIRC_RADIUS_ADJ (1.0 + M_PI / POLY_CIRC_SEGS_F * \
                                     M_PI / POLY_CIRC_SEGS_F / 2.0)
+#else
+#define POLY_CIRC_RADIUS_ADJ 1.0
+#endif

 /* polygon diverges from modelled arc no more than MAX_ARC_DEVIATION * thick */
 #define POLY_ARC_MAX_DEVIATION 0.02

XXX: ON REFLECTION, THIS "FIX" IS BOGUS... Fix bug in polygon contour generation

Incorrect contours were emitted in some cases when snap-rounding of vertices to
the integer grid cause coincident shared vertices from the same polygon to meet
at a cross-connected vertex.

The geometry required to create this situation is tricky, but could be provoked
in certain conditions by exactly touching line clearance polygons. (Due to
subtle rounding errors in the clearance polygons don't always meet exactly).

Distilling a simpler test case, the following polygons (on layer A and B)
should be united to reproduce the bug. (NB: The A POLYAREA has two contours
which touch at a single point):

  Layer(1 "A")
  (
    Polygon("")
    (
      [51.0000mm 18.0000mm] [51.0000mm 12.0000mm] [140.0000mm 12.0000mm  ] [144.0000mm 18.0000mm]
    )
    Polygon("")
    (
      [51.0000mm 6.0000mm] [144.0000mm 6.0000mm] [140.0000mm 12.0000mm] [51.0000mm 11.99996mm]
    )
  )
  Layer(2 "B")
  (
    Polygon("clearpoly")
    (
      [139.0000mm 5.0000mm] [145.0000mm 5.0000mm] [145.0000mm 19.0000mm] [139.0000mm 19.0000mm]
    )
  )

In this case the two contours of the 'A' polygon each have an edge that is
horizontal (or very close to horizontal), and meet at a single point inside
the 'B' polygon contour. Due to rounding onto the integer grid, both lines
intersect the B contour at the same point, leaving two coincident edge
fragments belonging to the A contour meeting at that one vertex on the B
contour.

In the above example, operation ordering conspires to insert the two identical
A edges into the CVC list for the common intersection point on the B contour,
in an incorrect order. (They are sorted by pseudo-angles, which are identical
in this case). The reversed order of these paired edges then upsets contour
labeling in node_label().

This commit fixes node_label() to look for and skip pairs of identically angled
edges from the same polygon when iterating around the CVC list. (We can
determine the INSIDE/OUTSIDE status when we find the next, non-paired edge from
the other polygon).

Introduce macros for traversing between edges and nodes in a specified direction

This greatly simplifies the code, at the cost of the traversal direction being
slightly less explicit.

polygon1.c: Refactor poly_Copy0 to use poly_Create(), rather than open-coding

This ensures all polygon initialisation happens in a common place

polygon1.c: Fix unitialised output polygon upon when hitting allocation failure

This was a bug present in the poly_Boolean() routine. We need to set the output
polygon to NULL if we are going to return early on memory failure. This was
noticed during general review after observing problems due to our copy routines
incorrectly returning FALSE when copying a NULL polygon.

Fix return codes from poly_Copy* functions when coping NULL input polygons

Copying a NULL polygon results in a NULL return polygon. This is not an error,
so be sure to return TRUE for success, otherwise we can abort boolean
later processing incorrectly, such as in poly_Boolean and poly_BooleanFree

polygon1.c: Remove now unused memory allocation macro MemGet

polyon1.c: Rework InsCntr to re-use poly_Create() rather than open-coding

This allows us to ensure common initialisation is performed in poly_Create().

This commit removes the single case where the memory allocation macro MemGet
was called, which will be removed in a later commit.

Make poly_Copy1 a static function internal to polygon1.c

polygon.c: Refactor NoHolesPolygonDicer to call poly_Copy0 rather than poly_Copy1

poly_Copy1 is much more of an internal function to polygon1.c, and this is its
only external caller. Replace this occurance with poly_Copy0, which is intended
to be the public API.

Attempt to fix bad rtree usage in polygon code

We need to delete the rtree entry before updating any bounds, otherwise
bad things might happen (and certainly, with NDEBUG undefined, we may
get asserts firing in rtree.c)

To avoid computational expense deleting and removing from the rtree in
the general case (where we wouldn't expect bounds to change), a new
test function has been added which determines whether the contour bounds
will be updated or not.

Try applying Martin's upstream patch (or similar)... and see how that looks with our new macros

Rename v->e and e->v to clairfy edge vs. vertex usage

polygon1.c: Rename rule and v_rule to j_rule for consistency