GeometryHelper 13.6.0

GeometryHelper 13.6.0, with GeometryHelper.CadConvert, GeometryHelper.IfcConvert and GeometryHelper.TeklaConvert.{2020,2025,2026} at 13.6.0.

NEW IN 13.6.0

A minor release: no public member added, removed or renamed. Its fixes are to solids far out, the cut of openings,
the weld of booleans and the meshing of faces, and its speed is in Clipper2; the results callers will see change
are those that were wrong.

FIXED, solids
- TryCutOpenings, GetVolume, TryGetVolume, GetSurfaceArea, GetCentroid, GetMassProperties, Section and
  Mesh3.ToCells of a body far out are worked out near the origin, as its booleans are since 13.5.0: a body
  reaching more than 2^20 out and more than 1 024 times the size of its box is moved by whole coordinates, with
  its openings, a section's plane or a grid's origin, and the answer moved back; a corner kept comes back as it
  was given, to the bit. Of 617 prisms with two or three openings ten million to a thousand million out, wrong
  answers at a thousandth 745 -> 8 and at a hundredth 853 -> 8. Within a million of the origin nothing changed, to
  the bit. Far out these take 4 to 12 per cent longer at a thousandth and a hundredth, 10 to 13 per cent less at a
  millionth.
- The cut of a solid's openings no longer leaves a sheet inside the material where walls of two openings stand a
  fraction of the tolerance apart: a strip still lying against a face once the gluing has taken what it could is
  read again with that face, and what they share goes from both. Of 4 500 prisms with two or three such openings,
  areas wrong at a hundredth and at a thousandth 576 -> 2, at a millionth 579 -> 0, and none that was right moved.
  The booleans glue their cells the same way: of 25 200 unions, common parts and differences of such prisms and
  boxes, 3 not worked out are right now; 13 ten million to a thousand million out, asked below the far frame's
  gate, that were right come out wrong.
- A union, a common part or a difference welded closed takes, of the corners that move the volume by nothing but
  rounding, the one tilting the faces round the others least, where it took the first met. A cube of 100 and a
  block 40 by 30 running 0.001 into its top held 1.39 less than the two less their overlap and holds 0.39 less. Of
  210 797 booleans of the gate corpora, 5 that were wrong are right and none is made wrong; given the same bodies,
  .NET 10 and .NET Framework 4.8 work them alike, to the bit. They take as long as they did.

FIXED, meshing
- GeoFace3.TriangulateSurface covers what the face covers, to rounding, where its corners stand within the
  tolerance of edges they are not on: the rings of a face cut into strips are read within rounding, where corners
  closer than the tolerance were merged. Of 48 904 faces with steps, notches, spikes, dents and holes 1E-6 to 0.02
  across, 24 622 areas wrong at a hundredth, 20 293 at a thousandth and 392 at a millionth are right, and none
  that was right moved. A loop thinner than the tolerance is still a seam with no triangle: one plate a thousand
  million out, whose cut keeps sheets 0.00018 thick, holds 0.057 too much read as the triangles in its faces.

CHANGED, Clipper2
- Shapes Clipper2 joins into one path one after another unite without slowing with the square of their number:
  50 000 squares of side 10 standing on a strip took 10.6 seconds to unite with Boolean2.Union on .NET 10, 9.8 of
  them in Clipper2, and take 1.1, 0.3 in Clipper2.
- Clipper2 builds a polytree of many holes in one path, or of shapes joined one after another, in time growing
  with their number: 20 000 teeth standing on a strip, each with a hole and an island, took 33 seconds to unite
  into a polytree on .NET 10 and take 0.44. Small clips take as long as they did. Of 80 000 sets of random paths,
  combs, zigzags, rows of squares, lattices and strips under every fill rule, no answer moves by a bit.

Details in CHANGELOG.md.

Earlier releases: https://github.com/nguyenthanguth/GeometryHelper/blob/main/CHANGELOG.md