Threads2

conceived: 2024-11-07
subject: WSPROJECT-201219, WSPROJECT-201282, WSPROJECT-201283
related: p1645, p1646, p1647, p1662, p1663, p1664, p1665, p1666, p1667, p1668
related: WSITEM-201166, WSITEM-201167, WSITEM-201173, WSITEM-201174, WSITEM-201175, WSITEM-201176
related: p1668, p1669, p1670, p1671
related: WSITEM-201178, WSITEM-201279, WSITEM-201300, WSITEM-201301

I've been wanting to 3D print large nuts and bolts for purposes of making components that can mount through round holes in thin plastic, for example to attach hunidity sensors to terrariums made out of cat litter tubs, or for making ports or indicators similar to these Powerwerx PowerPole ports and USB chargers.

I had already printed some threads matching those on wire-mouth mason jars and their rings, but these just barely worked, requiring a lot of trial-and-error, and I didn't feel like I had really nailed down the design. Plus, I wanted a single library that was capable of doing various standard threads, and to do it using my own polyhedron generation library to it can compose with other TOGMod1 shapes.

So I've been working on a new library to generate 3D-prunt threads, mostly standard UNC shapes, because that's what bolts I have to test with.

The first attempt used a very simple algorithm: Given a pitch (millimeters per thread) and a 'thread radius function' that returns a radius for a phase value from 0 to 1, it generates a series of $fn-sided polygons based on the radius function, rotating them 360/$fn degrees per layer. Getting this to work for both right and left-handed threads required adding a $tphl1_quad_split_direction parameter to indicate which way to split quads into triangles. But once that was done, I could generate some very nice threads.

TODO: Show threads w/ v2, fn=16, explain that the $fn had to be set low
otherwise there's too many polygons and you can't see what's going on!

Hence v3, which uses a more OpenSCADdish approach, basically a rotate_extrude with an offset.
Less 'clean' but fewer polygons.

while I liked the simplicity of this approach,
it just wasn't going to work for long bolts or high $fn;
excessive polygons and time to generate!

Turned out slowness was mostly from vertex deduplication, which was O($fn**4).
Disabling that made the difference between v2 and v3 less
noticeable at low $fn, but v3 still clearly beats v2 for larger $fns
(0:34 instead of 3:36 to render p1674 with $fn=96).

See 3DPrintingLog.org#2024-11-11-threads2-performance-testing for details.

TODO: Maybe auto-render a bunch of p1674s using v2/v3, with/without edges, $fn=16,32,64,96;
Leave deduplicatoin off lemao.