Part of #84. Blocks the docs page (#89).
Why this is needed
The epic explicitly declines to port BOSL2's attachment system (anchor / spin / orient /
reorient / named_anchor / attachable). It is thousands of lines of BOSL2 infrastructure
with no OCCT analogue.
But Examples 2 and 3 of the deliverable both depend on it. Example 2 meshes a gear pair
using anchor="apex", orient=FWD; Example 3 positions manually using pitch_radius() offsets
plus spin=180/t2. So we need the outputs of the anchor system without the machinery.
What to build
BOSL2 computes exactly three named anchors (gears.scad:2642-2646):
named_anchor("pitchbase", [0,0,pitchoff-ctr_thickness/2+backing/2]),
named_anchor("flattop", [0,0,ctr_thickness/2+backing/2]),
named_anchor("apex", [0,0,hyp_ang_to_opp(pitch_angle<90?ocone_rad:icone_rad,90-pitch_angle)
+pitchoff-ctr_thickness/2+backing/2])
Expose these as three reference Z heights on the returned gear: a small result struct
alongside the Shape, surfaced into the manifest metadata so render-preview and downstream
consumers can use them. Callers then position with ordinary translated and rotated.
Why the apex matters
For a bevel pair to mesh, the pitch cone apexes must coincide (gears.scad:2363). Anchoring
both gears at their apex and rotating one by the shaft angle is the whole trick. It is why
BOSL2's Example 2 is three lines. Getting this right is what makes a meshing pair demonstrable
rather than eyeballed.
Worth capturing as a helper: given two gears and a shaft angle, return the transform that
meshes them. That is the piece a downstream consumer actually wants, and the correct
replacement for anchor="apex".
Acceptance criteria
Part of #84. Blocks the docs page (#89).
Why this is needed
The epic explicitly declines to port BOSL2's attachment system (
anchor/spin/orient/reorient/named_anchor/attachable). It is thousands of lines of BOSL2 infrastructurewith no OCCT analogue.
But Examples 2 and 3 of the deliverable both depend on it. Example 2 meshes a gear pair
using
anchor="apex", orient=FWD; Example 3 positions manually usingpitch_radius()offsetsplus
spin=180/t2. So we need the outputs of the anchor system without the machinery.What to build
BOSL2 computes exactly three named anchors (gears.scad:2642-2646):
Expose these as three reference Z heights on the returned gear: a small result struct
alongside the
Shape, surfaced into the manifest metadata sorender-previewand downstreamconsumers can use them. Callers then position with ordinary
translatedandrotated.Why the apex matters
For a bevel pair to mesh, the pitch cone apexes must coincide (gears.scad:2363). Anchoring
both gears at their apex and rotating one by the shaft angle is the whole trick. It is why
BOSL2's Example 2 is three lines. Getting this right is what makes a meshing pair demonstrable
rather than eyeballed.
Worth capturing as a helper: given two gears and a shaft angle, return the transform that
meshes them. That is the piece a downstream consumer actually wants, and the correct
replacement for
anchor="apex".Acceptance criteria
pitchbase,flattopandapexheights computed and exposed per gearpoints agree within tolerance