A sketcher is the highest-touch part of any parametric CAD product and the component where engineering quality is most directly felt by users — usually without them being able to say why.
What you are actually building
Three layers, and teams routinely underestimate how much sits outside the maths:
| Layer | Responsibility | Share of effort |
|---|---|---|
| Solver | Find positions satisfying all constraints | ~30% |
| Constraint management | DOF analysis, conflict detection, diagnostics | ~35% |
| Interaction | Drawing, snapping, inference, dragging, visual feedback | ~35% |
The numerical solver is the smallest part. Teams budget for Newton iteration and are surprised by how much effort goes into telling the user why their sketch will not solve, and into making dragging feel natural. Those two determine whether the product is usable.
The solver core
Constraints become residual equations; you find the variable values driving all residuals to zero.
- Build the residual vector — one entry per constraint equation.
- Compute the Jacobian — partial derivatives of residuals with respect to variables. Analytic derivatives are worth the effort over numerical ones.
- Solve the linear system for the update step.
- Iterate until residuals fall below tolerance.
- Handle failure — detect divergence, singular Jacobians, and iteration limits.
Plain Newton diverges readily. Production solvers use damped Newton or Levenberg-Marquardt, which degrade gracefully toward gradient descent when the Jacobian is poorly conditioned.
Decomposition, and why it is not optional
Solving one large system for a 300-entity sketch is slow and numerically fragile. Real solvers decompose first:
- Build a graph with entities as nodes and constraints as edges.
- Identify rigid clusters — subsets fully determined internally.
- Solve each cluster independently, which is fast and well conditioned.
- Assemble clusters by solving the much smaller inter-cluster system.
Decomposition is what makes dragging feel live. Without it, a moderately complex sketch takes long enough per solve that the interaction becomes laggy — and users read that as the whole product being slow.
Diagnostics: the part that makes it usable
A solver returning only "solved" or "failed" is not shippable. Users need:
- Remaining degrees of freedom, ideally with the free entities highlighted.
- Fully constrained indication — the state most engineers work toward.
- Conflicting constraints named specifically, not a generic failure.
- Redundant constraints flagged as warnings, since consistent redundancy is common and harmless.
- Partial solutions — solve what can be solved rather than failing everything.
Conflict detection is genuinely hard. When a system is inconsistent, identifying a minimal conflicting subset requires more than noting that iteration failed — and it is the difference between a user fixing their sketch in seconds or abandoning it.
Interaction problems that are really solver problems
| User complaint | Actual cause | Fix |
|---|---|---|
| "Geometry jumps" | Converged to a different valid solution | Bias iteration toward current positions |
| "Dragging is laggy" | Full system solved per frame | Decomposition; solve only affected clusters |
| "It flipped inside out" | Orientation not preserved | Add orientation-preserving heuristics |
| "Won't tell me what's wrong" | No conflict analysis | Minimal conflicting subset detection |
| "Sometimes just fails" | Divergence near degeneracy | Damped methods; better initial guess |
The single highest-value implementation detail: always start iteration from the current geometry positions. Constraint systems usually have multiple valid solutions, and this one decision makes the solver find the one nearest to what the user already has — which eliminates most perceived weirdness at essentially no cost.
The interaction layer
Often underestimated because it is not mathematical:
- Snapping and inference — detecting that a user probably wants coincidence or tangency, and applying it automatically.
- Constraint visualisation — glyphs that are readable without cluttering the sketch.
- Live dragging — continuous solving with visual feedback.
- Undo that includes constraint state, not just geometry.
- Selection and editing of constraints, including removal of the conflicting one.
Practical recommendation
For most products: use PlaneGCS or an equivalent proven solver, and invest your engineering in the constraint management and interaction layers — which is where the product is actually differentiated and where most of the effort lies anyway.
Write your own solver only if you need behaviour existing ones cannot provide, or if licensing prevents their use. It is a well-defined problem, but the accumulated edge-case handling in a mature solver represents years you would be re-deriving.
Building a sketcher or parametric tool? Tell us what your users need to constrain. See our CAD engineering service and how constraint solvers work.