It turned out that the "moving up" of the gear shape was responsible for
the majority of processing time: it took 10x longer then the pipe
creation and 100x longer then the mirroring.
Now the moving is done of the helix and base face so that the other faces
are generated directly where they should be, thus preventing a movement
of all of them.
In addition, as we don't have to transform the final shape, we don't have
to use transformGeometry, but just change the placement via translate --
again much faster.
The now only helicalextrusion is the one working on a face, not a wire,
and allows extrusions of "faces with holes". This is required for the
internal gears but also allows e.g. center holes for ordinary gears as
well (not in this commit).
The original, now replaced, way had the benefit of reusing the existing
helicalextrusion method, but the following boolean cut operation was a)
slow and b) suffered from co-planar issues. The new way extrudes the
face directly which does not have these shortcommings.
Unfortunaly, we had to use a different API: the original one is simple
and straight forward, gives no easy way to access the end of the sweep.
Collecting the wires manually, filtering on the position of all vertexes,
unvailed tolerances heigher then 0.1, so that a face created from it was
not planar and prevented ceating a valid solid.
The now used API requires more manual work in the initial setup, but the
end wires for construction the top face are directly accesible and the
tolerances are below 0.001 so we can create a planar face and valid solid.
This new way also much faster (1.6 sec vs. 5.0 sec on my machine
using default gear parameters on a double helix, naively measured via
`time.perf_counter()`).
Currently, the new helical extusion method is only used for the internal
gear. Migrating the other usages will be done as a separate commit.
This reuses the same (external) tooth profile from pygear but swap some
parameters to make the resulting gear internal.
This prototype is mostly a copy of the external involute gear. Eventually
we should refactor this to share more code but this has to be coordinated
with the megagrant endevour. Otherwise merging becomes a nightmere.
Note that in contrast to the involute rack I choose to base the
"thickness" on the pitch diameter, not the root diameter. This has the
benefit of keeping the outside diameter stable when e.g. adjusting the
clearance. And setting the outside diameter directly could result in an
invalid shape when chaning the numnber of teeth.
The default head value of "-0.4" is choosen to match the invernal gear
profile from the PartDewign WB.
Previously, the `preview_mode` of the crown gear returned a compound of
the base and the cut-outs. This caused problems in PD::Bodies where a
single solid is requried.
The solution in this commit changes the preview_mode to only output the
base, not generating the cutout shapes at all. This is consistent with
the involute gears having "simple=true" and saves again 0.5 Seconds
processsing time on my system using defaults (15 teeth, 4 loft profiles).
In addition, "preview = false" is also speed up by first collecting all
cut-outs, and then passing them all at once to a single cut operation.
This reduced the cutting time from 3.0 Seconds to 2.2 Seconds here.
So preview now generats the shape immediately (0.0008s vs 0.5s) and the
actual crown is generated in 2.7s instead of 3.5s (again, using the
defaut parameters, measued via Python's time.perf_counter).
Heavy-lifting done using the "Part::AttachExtensionPython" extension
cf. https://wiki.freecadweb.org/Scripted_objects_with_attachment
Objects greated with earlier versions are automatically updated on
recompute.
Other types of gears not touched yet.
By checking whether the additional properties are available, gears
created with earlier versions can still be manipulated in FreeCAD.
And when first touching an older gear, it gets updated with the new
additional properties.
The values are already calculated by pygear and this change make them
available as properties in FreeCAD.
The naming should be in line with the rest of fcgear's nomenclature,
derived from https://qtcgears.com/tools/catalogs/PDF_Q420/Tech.pdf
