The sketcher is the part of a CAD product users touch most, and the part whose quality is decided almost entirely by code they never see. When a sketch snaps cleanly into place, that is a constraint solver. When it flips inside out, that is the same solver making a defensible choice you did not want.

What the solver is actually asked

A sketch is a set of geometric entities with unknown positions, plus a set of conditions those positions must satisfy. The solver's job is to find values that satisfy all conditions simultaneously.

ConstraintMathematicallyRemoves DOF
Coincident pointsTwo positions equal2
Distance between pointsEuclidean distance = d1
Horizontal lineEndpoint y values equal1
Perpendicular linesDirection dot product = 01
Tangent line and circlePoint-to-centre distance = radius1
Equal lengthTwo lengths equal1

A point in 2D has two degrees of freedom. A line segment has four. Add up the DOF of all entities, subtract the constraints, and the remainder tells you whether the sketch is under-constrained, fully constrained, or over-constrained.

Why it is not simply solving equations

The system is non-linear

Distance and tangency constraints involve squares and square roots. There is no direct solution — you iterate from an initial guess, typically with a Newton-Raphson scheme on the residual vector.

There are multiple valid answers

Constrain a point to be 50mm from another and it can sit anywhere on a circle. Add a second distance and you generally get two intersection points, both entirely valid.

This is why sketches jump. The solver converged to a mathematically correct solution that was not the one you had in mind. The mitigation is not better maths but better bias: start iteration from the current geometry so the nearest solution is found, and preserve orientation and ordering where possible.

The Jacobian goes singular

Near degenerate configurations — a triangle collapsing to a line, two constraints becoming parallel — the derivative matrix loses rank and Newton iteration diverges. Robust solvers detect ill-conditioning and fall back to damped or least-squares methods rather than producing nonsense.

Users create contradictions

They will constrain a line to be both horizontal and vertical. A solver that merely fails to converge is useless; it must identify which constraints conflict so the user can remove one.

Decomposition: the technique that makes it fast

Solving one large non-linear system for a 200-entity sketch is slow and fragile. Production solvers decompose first.

  1. Build a constraint graph with entities as nodes and constraints as edges.
  2. Find rigid clusters — subsets that are fully determined internally and can be solved on their own.
  3. Solve each cluster independently, which is fast and well conditioned.
  4. Assemble clusters by solving the much smaller system relating them.

Decomposition turns one badly conditioned 400-variable problem into fifty well-behaved small ones. It is the difference between a sketcher that feels instant and one that stutters.

Diagnostics are half the product

A solver that only returns "solved" or "failed" is not usable. Users need to know what state their sketch is in:

  • Remaining degrees of freedom — and ideally which entities can still move.
  • Fully constrained indication, since that is the state most engineers aim for.
  • Conflicting constraint identification — naming the specific constraints in a contradiction.
  • Redundant constraint detection — consistent but unnecessary, which should warn rather than error.
  • Drag-time behaviour — the solver runs continuously while a user drags, so it must be fast enough to feel live.

Most "sketcher UX problems" are solver problems. Jumping geometry, unexplained failures, sluggish dragging, and unhelpful error messages all originate below the interface. Improving the UI cannot fix them — which is why sketcher quality is decided by an architectural choice made early.

If you are building one

  • Consider existing libraries first. PlaneGCS (from FreeCAD) and SolveSpace's solver are proven and openly licensed. Writing your own is justified when you need behaviour they cannot provide.
  • Design diagnostics from the start. Retrofitting DOF analysis and conflict detection into a bare Newton solver is painful.
  • Bias toward the current configuration in every iteration. This single decision removes most user-visible weirdness.
  • Budget for degeneracy handling — the collapsing and near-singular cases are where the engineering effort actually goes.
  • Test with real sketches, including deliberately over-constrained and contradictory ones.

Where this fits in a product

The constraint solver sits above the geometry layer and below the interface. It does not need a full B-Rep kernel — a 2D sketcher can work on curves alone — which means a parametric 2D tool is a substantially smaller undertaking than a 3D modeller. For many industry-specific CAD products, that is exactly the right scope.

Building a sketcher or parametric tool? Tell us what your users need to constrain. See our CAD kernel service and what a CAD kernel is.

Frequently asked questions

Because the solver found a different valid solution than the one you expected. Constraint systems usually have multiple solutions — a distance constraint can be satisfied on either side. Good solvers bias toward the configuration nearest the current geometry, but with under-constrained sketches jumps still occur.
That you have specified more constraints than degrees of freedom, and at least some conflict or duplicate each other. It is not always an error — redundant but consistent constraints are common — but the solver must detect and report which ones are genuinely contradictory.
Newton-based iteration is the numerical core, but a usable solver is much more: decomposition into independently solvable clusters, degree-of-freedom analysis, diagnostics for conflicting constraints, and initial-guess strategies that keep it converging to the solution the user expects.