Context

The GPU snap detection that landed in 4cb6ce703..2b429dc60 replaces object discovery. Raycast.ray_cast_by_proximity survives it and is still the only CPU path that turns a detected object into Vertex / Edge Center / Edge snaps: detect_snapping_points calls it for the object under the cursor, and in plan/section views once per visible element carrying cut or fill decorator data.

These three changes reduce the cost of that function and of Cad.intersect_edges_v2, which it calls once per edge. They are independent of how candidates are found, so they apply equally before and after the GPU work.

Changes

One commit each, each independently revertible:

1. Speed up Cad.intersect_edges_v2. Replace np.cross / np.linalg.norm / np.dot with explicit scalar arithmetic. On 3-element operands numpy spends far more time in its dispatch machinery (normalize_axis_tuple, moveaxis) than on the arithmetic itself. Float64 throughout, so results are unchanged. Also used by wall junctions in tool/model.py.

2. Hoist matrix_world out of the proximity loops. It was copied once per vertex and twice per edge, and cannot change while the loops run. Pure code motion: the copy is still taken, and the obj=None path used by the custom_bmesh callers is preserved.

3. Skip the line-line intersection for edges that cannot snap. Every point of an edge lies within half its length of its midpoint, whose distance to the ray the loop already computes for the Edge Center snap. By the triangle inequality no point can be nearer to the ray than midpoint_distance - edge_length / 2; once that lower bound reaches the snap threshold, intersect_edges_v2 cannot produce a hit. The predicate never rejects an edge that could snap, so snapping results are unchanged.

Measurements

Being explicit about what is and isn't measured:

• 3.8x on intersect_edges_v2 (68.95µs → 18.16µs) is a direct microbenchmark of the function and holds.
• End-to-end figures I collected earlier (per-event call count 52,113 → 1,869; ~370ms → ~70ms) were measured before the GPU rewrite, when ray_cast_by_proximity ran against every candidate object. They no longer describe the current architecture, so I am deliberately not claiming them here. What remains true regardless is that both changes strictly remove work while preserving behaviour.

Where I would expect them to still matter most is plan and section views: the cut/fill block in detect_snapping_points came through the rewrite unchanged and still iterates every visible mesh element with cache data, rebuilding a bmesh per object per mouse move.

Tests

• test/tool/test_cad.py — 6 characterization tests for intersect_edges_v2 (skew, crossing, parallel, collinear, 2D input, unnormalised directions), written against the previous implementation before the refactor, so it is verified behaviour-preserving rather than assumed to be.
• test/tool/test_raycast.py (new) — 5 tests for the early-out, including a randomised search over 3000 edges that samples 21 points along every rejected edge and asserts none lies within the threshold, with a guard so the test cannot pass vacuously.

test/tool/test_cad.py test/tool/test_raycast.py — 23 passed. black --line-length 120 clean.

Related

Supersedes #9004, which fixed the object-origin sort in ray_cast_and_get_closest_to_camera_snaps. The GPU rewrite left that function in the file but nothing calls it any more, so the heuristic it corrected is no longer on a live path. I'll close #9004.

🤖 Generated with Claude Code

Real work comparison

Pre fix

After fix