Pocket/Rough operation off-by-one: generates N-1 passes instead of N

[KevinTurnbull]

When using a 2D pocket operation, if the step-down value does not divide evenly into the total cut depth, Kiri:Moto calculates the correct number of equal passes but only generates N-1 of them, leaving the pocket short of the target depth.

Steps to Reproduce

1. Create a 2D pocket operation
2. Set cut depth to 5mm
3. Set step-down to 2.49mm
4. Z origin: top of stock
5. Stock offset: 0x0x0
6. Slice and inspect the generated G-code

Expected Behavior

5mm / 2.49mm = 2.008 → rounds up to 3 passes:

• Pass 1: Z = -1.667
• Pass 2: Z = -3.333
• Pass 3: Z = -5.000

Actual Behavior

Only 2 of 3 passes are generated:

• Pass 1: Z = -1.6766
• Pass 2: Z = -3.3433
• Pass 3: missing

The pocket is cut to -3.3433mm instead of the requested -5mm.

Analysis

It appears the total depth is divided by the correct number of passes (3), producing equal step sizes (~1.667mm), but only N-1 passes are executed. This looks like an off-by-one error in the pass generation loop.

Workaround

Use a step-down value that divides evenly into the total depth (e.g., 2.5mm for a 5mm cut).

[KevinTurnbull]

Root Cause Analysis

The final Z pass is silently dropped due to two interacting issues:

1. Floating-point drift in lerp() (src/geo/base.js)

The function accumulates from += per * dir in a loop. When step-down doesn't divide evenly into total depth, per is recalculated as delta / steps, and repeated addition causes the final value to overshoot to by a small epsilon.

2. Boundary degeneracy in op-area.js

shadowAt(z) is called with the final Z value, which due to float drift sits exactly on (or just past) the model's bottom face. At this boundary, the shadow returns empty/degenerate geometry. The outs.length === 0 check then triggers break outer, silently dropping the final pass.

The result: lerp correctly calculates N passes, but the Nth pass produces no output and gets discarded — the pocket is cut to only (N-1)/N of the requested depth.

Patch

diff --git a/src/geo/base.js b/src/geo/base.js
index 6cfe986d..bec182c4 100644
--- a/src/geo/base.js
+++ b/src/geo/base.js
@@ -36,6 +36,10 @@ function lerp(from, to, maxInc, incFrom) {
         from += per * dir;
         out.push(from);
     }
+    // snap last value to exact target to avoid floating point drift
+    if (out.length) {
+        out[out.length - 1] = to;
+    }
     return out;
 }

diff --git a/src/kiri/mode/cam/work/op-area.js b/src/kiri/mode/cam/work/op-area.js
index 03a4a9fe..06b7f0ff 100644
--- a/src/kiri/mode/cam/work/op-area.js
+++ b/src/kiri/mode/cam/work/op-area.js
@@ -175,7 +175,9 @@ class OpArea extends CamOp {
                 for (let z of zs) {
                     let slice = newLayer(z);
                     let layers = slice.output();
-                    let shadow = await shadowAt(z);
+                    // query shadow slightly above exact bottom to avoid boundary degeneracy
+                    let shadowZ = (z === zs[zs.length - 1] && zs.length > 1) ? z + 0.001 : z;
+                    let shadow = await shadowAt(shadowZ);
                     let tool_shadow = [
                         ...POLY.offset(shadow, [  ts_off ], { count: 1, z, ...offopt }),
                         ...POLY.offset(shadow, [ -ts_off ], { count: 1, z, ...offopt }),
@@ -255,7 +257,9 @@ class OpArea extends CamOp {
                 for (let z of zs) {
                     let slice = newLayer(z);
                     let layers = slice.output();
-                    let shadow = await shadowAt(z);
+                    // query shadow slightly above exact bottom to avoid boundary degeneracy
+                    let shadowZ = (z === zs[zs.length - 1] && zs.length > 1) ? z + 0.001 : z;
+                    let shadow = await shadowAt(shadowZ);
                     let outs = [];
                     if (tr_type === 'none') {

[KevinTurnbull]

Resolution Patch (Binary Search for Pocket Floor)

Z passes for pocket/rough operations are generated by lerp() (src/geo/base.js) and distributed evenly across the full workarea range (top_z to bottom_z), not the actual pocket depth. The pocket floor is determined implicitly: when shadowAt(z) returns geometry that produces no toolpath output, the loop breaks via break outer (op-area.js:206).

The problem is that the evenly-spaced Z passes almost never land exactly on the pocket floor. For example, with a model Z range of 19→0 and a 2mm step-down, passes land at Z=17.1, 15.2, 13.3, ... but the pocket floor is at Z=14. The pass at 15.2 is 1.2mm above the floor, and the next pass at 13.3 is below it — producing empty output and triggering the early exit. The pocket is cut 1.2mm too shallow.

A secondary issue: lerp() accumulates from += per * dir in a loop, causing floating-point drift. The final Z value can overshoot the target boundary by a small epsilon, which can cause shadowAt() to return degenerate geometry at exact model faces.

Fix (attached as patch)

Three changes:

1. lerp() float snap (base.js)

Snap the last array value to the exact target after accumulation. Prevents float drift from overshooting boundaries.

2. findPocketFloor() utility (op-area.js)

When the Z pass loop encounters empty output (no valid toolpath at the current depth), binary search between the last successful Z and the current failed Z to find the actual pocket floor — the deepest Z that still produces valid toolpath. Converges to within 0.001 units in ≤20 iterations.

3. Finishing pass in the clear loop (op-area.js)

When the pocket floor is found and differs from the last pass, emit a single finishing pass at that depth. The finishing / finishEmitted flags ensure exactly one pass is added, then the loop exits. The shadow query uses a +0.001 epsilon on the finishing pass to avoid boundary degeneracy.

Note: the trace mode has a similar shadowAt() boundary issue and gets the epsilon fix, but does not yet include the finishing pass logic. It likely has the same floor-skipping behavior.

kirimoto-pocket-depth-fix.patch

[stewartoallen]

claude? codex? other? I've used a similar process in other areas of the code. the only downside to this approach is that you don't get the Z cut exactly where you want it. 0.001 is often not enough to overcome the floating point precision issues in many meshes. 0.01 is more reliable. I've been holding off to do a more precise fix which uses and offset "slice" above the target Z and then re-adjusts the cut plane afterwards.

[KevinTurnbull]

My process involves a range of tools. In this case I'd say the error assessment and "finding the right spot" was claude, the patching was me rubberducking with Qwen 3.5.

In terms of the accuracy; I think a binary search is the right balance. Initially I had used a fixed offset from the shadow but realized that it was too dependent on what workspace coordinate system was in play.

[KevinTurnbull]

Oh the floating point precision issue is something I might be under-representing in the solution. Do a lot of models use low precision floats -- and does that wind up capping precision of the shadow?