Open any CAM brochure. There will be a section called collision detection or gouge avoidance, with a green checkmark next to it and a screenshot of a tool holder bumping into a fixture. Every CAM vendor — Mastercam, Fusion, NX, PowerMill, Mecsoft, FreeCAD’s Path workbench — promises that the toolpath will not gouge the part.

Now open FreeCAD’s bug tracker and search for issue #22178. Title: “CAM Inconsistent and inaccurate collision detection.” The report is from a working machinist, the issue is open, and the proposed fix — pull request #25753 — was rejected by maintainers. The reason given was simple and damning: it had no tests.

This is a community telling you, in writing, that one of the things their CAM software claims to do, it does not actually do. And the patch that tried to fix it could not be merged because nobody had a way to verify that the fix worked.

That is the gap this post is about. We are going to argue three things:

The state of the art in open-source CAM gouge detection is far weaker than the marketing pages suggest, and FreeCAD #22178 is the public evidence of it.
There is a clean way to do gouge detection that the existing CAM tools cannot do because of how they represent geometry — not because the algorithm is hard.
NeuroCAD’s SDF-native kernel is positioned to ship that clean approach, and — crucially — to ship the tests that the rejected FreeCAD PR was missing.

The CAM workbench in NeuroCAD is still a placeholder. We are not announcing a finished product. We are publishing the method and the test design, so that the FreeCAD CAM community, LinuxCNC users, and anyone who has been bitten by a silent gouge has something concrete to engage with.

What “gouge detection” actually means

A toolpath is a sequence of motions. The cutter — a ball-end mill, an end mill, a bull-nose, a fly-cutter — moves along the path and removes material. Gouge is the industry word for the cutter going somewhere it should not: into the finished surface of the part, into a fixture, into a clamp, into the table, or into itself on a tight inside corner.

A 3-axis gouge can come from many places: a stepover that is too aggressive, a holder that is too short, a tool that is too long and flexes, an inside corner that is sharper than the cutter radius. A 5-axis gouge adds a whole new family: the tool is now tilted, the holder swings through space, the rotary axes can flip, and the swept volume — the union of every position the cutter occupies as it moves — is no longer something you can draw on graph paper.

What every CAM package promises is: we will simulate the toolpath, sweep the cutter through space, and tell you if it ever enters the part or the fixture. What FreeCAD #22178 says is: no, you don’t. You miss things. Your collision detection is inconsistent, and when it does fire, it sometimes fires on phantom collisions that aren’t there.

Why?

Why gouge detection is hard in B-rep CAD

The dominant CAD representation today is B-rep — boundary representation. A part is a watertight skin made of trimmed surfaces, edges, and vertices. B-rep is excellent for clean geometry, but it has a famous weak spot: anything that requires reasoning about the interior of the solid is awkward, because B-rep only stores the boundary.

Gouge detection is exactly such a problem. To check whether the cutter has entered the part, you need to ask: is point P inside the solid, and by how much? In B-rep this is a ray-casting odd/even count or a winding-number computation. It works, but it is fragile near tangent contact, near sharp edges, and near degenerate trim curves. Each of these is a known source of false negatives in production CAM.

The second hard piece is the swept volume. As the cutter moves from position A to position B, it sweeps out a 3D region. For 3-axis linear motion of a ball-end mill, the swept volume is a capsule (a cylinder capped with two hemispheres). For 5-axis motion with simultaneous rotary and linear motion, the swept volume is a more complex algebraic surface — it is one of the hardest things to compute exactly in B-rep. Most CAM packages approximate it by sampling: take 50 cutter positions along the move, union the cutter shapes, hope the sampling is fine enough to catch the worst case. Sometimes it isn’t, and that is exactly the failure mode FreeCAD #22178 documents.

The third piece is the test problem. Even if you have a gouge detector, how do you prove it works? You need a benchmark — a part with a known gouge of known depth at a known location, machined by a known toolpath, and you need to assert: the detector finds this gouge. This is what PR #25753 did not have, and it is why the patch was rejected.

The SDF approach in one paragraph

NeuroCAD does not store geometry as a B-rep skin. It stores it as a signed distance field: every point in space carries a number — its signed distance to the nearest part surface. Negative inside, positive outside, zero on the surface. This is the same representation used in computer graphics for ray-marched scenes (Inigo Quilez, Distance functions for primitives) and in NeuroCAD it is the kernel-level representation, not a render-time gimmick.

In an SDF representation, gouge detection is structurally simple:

The part has an SDF: f_part(p). Negative inside, positive outside.
The swept volume of the toolpath has an SDF: f_sweep(p). Negative inside the swept region, positive outside.
A gouge exists wherever both are negative simultaneously: f_part(p) < 0 AND f_sweep(p) < 0.
The maximum gouge depth is max(p ∈ Ω) [-f_part(p) - f_sweep(p)] over the part interior.

That is the entire detector. No sampling along the move. No approximate union. No B-rep boolean that fails on tangent contact. Just two distance evaluations and a sign check. The hardest piece is constructing f_sweep for a 5-axis motion — and that is where the contribution of this work sits.

Swept tool volume as an SDF

For a 3-axis linear move from A to B with a ball-end mill of radius r, the swept volume is the Minkowski sum of the line segment A→B and a sphere of radius r. The SDF of a capsule is one of the standard primitives in the Quilez catalogue — six lines of code, exact, no approximation.

For a 5-axis move where the tool tip goes from A to B and the tool axis rotates from ω_A to ω_B, the swept volume is the union over t ∈ [0,1] of cylinders at position lerp(A,B,t) with axis slerp(ω_A,ω_B,t). This is no longer a closed-form SDF, but it has a clean interval-arithmetic envelope — and the envelope is itself an SDF, by construction conservative (it says “definitely safe” or “needs deeper check”). When the envelope reports possible gouge, the detector subdivides the parameter interval and recurses. This is a standard technique in interval geometry; the novelty here is using SDF as the intermediate representation throughout.

For swarf cutting — where the side of the cutter rides the surface and the tool axis is constrained to a ruled surface — the swept volume reduces to a generalized cylinder along a ruled surface, and the SDF is again expressible as a Minkowski sum: ruled surface plus disk perpendicular to the local axis.

In all three cases the answer is: the swept volume is an SDF, the part is an SDF, and gouge detection is one Boolean.

The test that was missing

FreeCAD PR #25753 was rejected for not having tests. Here is the test design we are publishing:

Reference part: a curved hemisphere with a deliberate inside corner of radius 0.5 mm.
Reference toolpath: a 3-axis ball-end finishing pass with cutter radius 1.0 mm. This will gouge the inside corner — the cutter is too big.
Assertion: the detector reports a gouge at the inside corner with depth ≥ 0.49 mm (cutter radius minus corner radius, minus tolerance) and reports zero gouges everywhere else.
Differential test: the same setup with a 0.4 mm cutter — assertion flips, detector reports zero gouges.
5-axis test: a swarf path on a ruled developable, posted with deliberate axis singularity at C=0; detector must not flag a phantom gouge from the singularity itself.

This is not a hard test to write. It is the test FreeCAD needed and did not have. We are publishing it so that any CAM developer — not just NeuroCAD’s — can use it as a regression baseline.

What we are not claiming

CAM is a placeholder. NeuroCAD does not ship a CAM workbench today. The Path-equivalent module is empty.
The post-processor matrix is not built. We have not yet written posts for LinuxCNC / Fanuc / Heidenhain / Siemens 840D.
Constant-scallop, adaptive clearing, drilling cycles — none of these strategies have shipped implementations yet. They have test specifications in the corpus waiting for implementation.

What we are claiming is that the gouge-detection method described above is correct, that the test design is sound, and that — when the CAM workbench lands — it will ship with the test that PR #25753 lacked. This is a pre-implementation publication of method and test corpus. The point is to engage the CAM community now, while there is still time to converge on a shared benchmark, rather than after we ship in isolation.

Why we publish this now

FreeCAD #22178 has been open since 2024. PR #25753 stalled. The community is aware of the gap. Three groups are positioned to close it: FreeCAD itself, a commercial CAM vendor under a marketing motivation, and us. We are publishing the method openly because we want the FreeCAD CAM team to be able to use it directly — the SDF approach is not patented, the test design is not proprietary, and the entire point is that gouge detection should not be a competitive moat. It should be table stakes.

If FreeCAD ships an SDF-based gouge detector before our CAM workbench is finished, that is a win, not a loss. The kernel work in NeuroCAD’s SDF stack is open, and the SDF primitives we describe (capsule, ruled surface, Minkowski sum) are already implemented in the kernel.

What comes next for NeuroCAD CAM

The order we are planning:

Land the gouge-detection test and the SDF swept-volume verification as runnable contract tests against the SDF kernel, even before the CAM workbench has a UI.
Add the post-processor matrix for LinuxCNC first (open-source target, RS274/NGC interpreter is the cleanest reference).
Build the GUI Path equivalent on top of the verified kernel.
Submit results to a CAM venue — the LinuxCNC community list and the FreeCAD #22178 thread are the first two reading audiences.

The bigger point

CAM is a domain where silent failures cost real money — a missed gouge means a scrapped part, a broken tool, sometimes a damaged spindle. The fact that the leading open-source CAM has a publicly documented, unfixed gouge bug, and the fact that the proposed fix could not land for lack of tests, is not a software-engineering footnote. It is a structural problem with how the field benchmarks itself.

NeuroCAD’s contribution is narrow and specific: a representation in which the detector is short, exact, and testable; and a public test design that any CAM tool can adopt. We are not solving CAM. We are removing one excuse for not solving CAM.

References

[1] FreeCAD. CAM Inconsistent and inaccurate collision detection. Issue #22178, FreeCAD GitHub. https://github.com/FreeCAD/FreeCAD/issues/22178 [2] FreeCAD. Multi-axis collision detection. Pull Request #25753 (rejected for lacking tests). https://github.com/FreeCAD/FreeCAD/pull/25753 [3] Quilez, I. Distance functions for primitives. https://iquilezles.org/articles/distfunctions/ [4] LinuxCNC. RS274/NGC G-code reference. https://linuxcnc.org/docs/html/gcode.html [5] Hart, J. C. Sphere tracing: a geometric method for the antialiased ray tracing of implicit surfaces. The Visual Computer, 12(10):527–545, 1996.

Status

NeuroCAD ships the Capsule SDF primitive (covering the 3-axis ball-end swept move) and the field-composition machinery used to express Minkowski sums (cutter ⊕ path segment). The CAM workbench module is a placeholder — no UI, no operations. The 3-axis gouge-detection contract test, the SDF swept-volume Boolean closure test, the 5-axis swarf swept-volume SDF, the RTCP/TCPC post-processor invariance test, the LinuxCNC RS274/NGC conformance test, and the post-processor matrix for Fanuc / Heidenhain / Siemens 840D are all proposed. Anything not marked shipped should be treated as plan, not product. The gouge-detection method described in this post is a publishable contribution toward FreeCAD #22178; it is not a finished CAM workbench.

Toolpath Gouges: Every CAM Vendor Claims to Detect Them. FreeCAD's Bug Tracker Says Otherwise.