Action-focused games push constraint solving harder than almost any other simulation workload. Common scenarios that define these titles are the same ones that expose solver limitations:

• High-impact ragdolls. A character takes a shotgun blast at close range, gets launched by an explosion, or ragdolls off a rooftop onto a moving vehicle. Joints need to hold together through extreme forces without visible separation at shoulders, hips, or elbows – and recover cleanly within a frame or two. When the solver falls short, players see limbs stretching apart or snapping back unnaturally. In solver terms, this is the joint separation under load problem – the solver must correct constraint violations quickly without introducing instability.

• Heavy objects on chains and constraint chains with wide mass ranges. A wrecking ball swinging through a destructible building. A massive boss creature whose heavy torso drives a chain of lightweight tail segments. A grappling hook pulling a character toward a heavy anchor point. In each case, the solver must propagate impulses through a constraint chain where bodies differ dramatically in mass. When it cannot, the chain stretches visibly, the tail lags behind the body, or the grapple feels elastic instead of taut. This is the mass ratio convergence problem – one of the hardest challenges for iterative solvers, where more iterations alone cannot cost-effectively close the gap.

• Mixed constraint stiffness in the same scene. A horror game where a creaking door swings loosely on a worn hinge while, in the next room, a mechanical press slams down with rigid precision. A single global stiffness setting cannot serve both. The solver needs to support per-constraint tuning so that soft interactive objects and rigid mechanical systems coexist without compromise. This is a constraint stiffness control problem – the solver must expose fine-grained tuning surfaces without requiring global parameter changes that affect everything else.

• Large-scale physics events. A building collapses and spawns hundreds of constrained fragments. A battle scene has dozens of active ragdolls and vehicles simultaneously. The solver must scale across available cores and absorb sudden spikes in constraint count without requiring manual thread management or per-scene partitioning from the engineering team. This is a CPU scaling problem – parallelizing constraint solving without introducing race conditions or excessive synchronization overhead.

These challenges are architectural – they depend on how the solver formulates constraints, how it corrects errors, and what tools it provides when iterative convergence alone is not enough. The rest of this post covers how Havok’s solver is built to handle each of them. To see how these solutions work within your own game, reach out to evaluate Havok Physics.

Havok Physics uses a velocity-based iterative solver built on sequential constraint processing, Jacobian-based formulation, and projected impulse clamping – an approach consistent with the Projected Gauss-Seidel (PGS) family of methods well-known in simulation literature. Its positional error correction uses tau and damping parameters proportional to dt² and dt respectively, an approach consistent with Baumgarte stabilization. These established techniques form the mathematical foundation of how Havok’s solver operates. This solver architecture is the foundation of constraint solving in both Havok SDK and Havok Physics for Unreal.

Every constraint in Havok Physics – whether it is a ragdoll shoulder, a door hinge, or a contact between a crate and the floor – must be converted into a form the solver can process. That form is a set of Jacobian rows, and understanding what they contain explains why the solver behaves the way it does under different conditions.

Two unconstrained rigid bodies have six degrees of relative freedom: three linear (they can move apart along X, Y, and Z) and three rotational (they can twist relative to each other around each axis). A constraint removes some of those freedoms. Each removed degree of freedom becomes one Jacobian row – a compact, linearized equation that tells the solver exactly how to enforce that restriction.

A Jacobian row encodes four things:

• The direction of restriction. Linear and angular components for each body that define which relative motion this row prevents. For a ball-and-socket joint, one row might encode “these two pivot points must not drift apart along the X axis.”
• Effective mass. A scalar derived from both bodies’ masses and inertia tensors that tells the solver how much impulse is needed to produce a unit velocity change along this row’s direction. This is where mass ratios directly affect solver behavior – when one body is dramatically heavier than the other, the effective mass for the row is dominated by the lighter body, which limits how much correction the solver can apply per iteration.
• Error correction term. The current positional violation along this direction, scaled by tau and damping (covered in the next section). This is the Baumgarte stabilization term that drives the solver to close position-level gaps, not just prevent new ones.
• Impulse bounds. The minimum and maximum impulse the solver is allowed to apply along this row. These bounds are what make the “projected” step in Projected Gauss-Seidel work – they enforce physical constraints on the solution. Contact rows have a lower bound of zero (they push bodies apart but never pull them together). Friction rows are bounded by the Coulomb friction cone (maximum friction force proportional to the normal contact force). Motor rows have configurable force limits.

Different constraint types produce different numbers of Jacobian rows, corresponding to how many degrees of freedom they restrict:

Internally, Havok builds these rows from constraint atoms – modular building blocks that each handle a specific type of restriction. A hinge constraint, for example, is composed of three atoms: one defines the constraint space and pivot points, a second restricts the linear position of the pivots (3 rows), and a third restricts angular movement to the hinge axis (2 rows). Adding angular limits or motors adds further atoms and further rows. This modular atom structure is how Havok achieves per-constraint tuning – tau and damping factors, stabilization methods, and solving modes are configured at the atom level, which means they apply to specific Jacobian rows rather than to the constraint as a whole.

This Jacobian representation is computed automatically during collision detection for contacts and from constraint definitions for joints, then stored in solver data. The solver operates entirely in this linearized constraint space during iteration – it never needs to re-evaluate geometry or constraint definitions during the solve loop. Every constraint type, regardless of complexity, is reduced to the same uniform row format before solving begins.

This uniformity is what makes the solver’s iteration loop efficient and what enables the parallelization strategy described later in this post. It also means that the solver’s convergence characteristics – how iteration count, mass ratios, and constraint ordering affect stiffness – apply consistently across all constraint types. A ragdoll shoulder and a ground contact are processed by the same solving logic, differing only in their Jacobian row count, impulse bounds, and error correction terms.

The PGS method solves constraint equations by processing them one at a time, in sequence. For each constraint row, the solver computes the impulse needed to satisfy that constraint, clamps it to the feasible range (the “projected” step that correctly handles contacts and limits), and applies the impulse change to both bodies’ velocities.

Because each constraint uses the most recent velocity state updated by all previous constraints, PGS converges faster than parallel Jacobi approaches for the same iteration count – a meaningful advantage when iteration budgets are tight.

One complete pass through all constraints constitutes a single solver iteration. More iterations improve convergence. Havok exposes the iteration count as a world-level parameter and supports dynamic adjustment based on timestep.

• Well-conditioned systems(similar mass objects, few constraint chains) converge quickly.
• Ill-conditioned systems(large mass ratios, long chains like ragdolls or suspensions) converge slowly. The impulse a heavy body needs to transfer through lighter bodies is limited at each step by the lightest body’s effective mass.
• Constraint ordering Havok’s solver scheduling uses a priority system to ensure that high-priority constraints like ground contacts are solved last and “win out” over lower-priority internal constraints.

The practical implication: increasing global solver iterations improves stiffness but costs proportional CPU time across the entire scene. Havok’s constraint group system (covered below) provides a more targeted approach – additional iterations exactly where they matter, without increasing the global budget.

An iterative velocity solver does not directly correct positional errors. If two bodies are already penetrating, or a joint has separated slightly, the velocity solver alone prevents further violation but does not push bodies back into compliance. Over time, small errors accumulate.

Havok addresses this through positional error correction injected into the velocity constraint equations – an approach consistent with Baumgarte stabilization in simulation literature. The solver targets a corrective velocity proportional to the current positional error, gradually closing any position-level constraint violation.

Two parameters control this behavior:

Tau controls the fraction of positional error to correct per solver sub-step. Higher values correct faster; lower values correct more gradually. Tau is proportional to dt², reflecting the relationship between position correction and acceleration.

Damping controls the fraction of velocity error to correct per solver sub-step. Lower values allow bodies to sink into each other more before corrective impulses fully engage. Damping is proportional to dt, reflecting the linear relationship between velocity correction and impulse.

Together, these parameters define the constraint feel:

These values are configured globally via hknpWorldCinfo and can be overridden per-constraint through tau and damping factor fields on individual constraint atoms. The per-atom factors scale the global values, so a soft door hinge and a stiff vehicle axle can coexist in the same scene at the same solver budget.

For studios evaluating solver flexibility, this means constraint feel can be tuned per-joint without rebuilding assets or changing global settings.

An iterative solver with a fixed iteration budget cannot perfectly satisfy all constraints simultaneously. When tau and damping are high, each constraint aggressively corrects its own violation, but the correction for one constraint creates violations in neighbors. With insufficient iterations, this mutual interference causes visible jitter.

Softening via lower tau and damping spreads the correction across more steps. Each step applies a smaller impulse, so mutual interference is reduced. The result is smoother behavior at lower iteration counts, at the cost of some residual constraint error that is typically not visible.

When per-constraint atom scaling factors for tau and damping are both reduced significantly below 1, damping factors should remain higher than tau factors to avoid jittery behavior. This guidance applies specifically to the per-atom override multipliers rather than to the global solver values.

Because tau is proportional to dt² and damping is proportional to dt, changing the simulation timestep changes the effective stiffness of every constraint. A solver tuned to feel tight at 60 Hz will feel loose at 30 Hz and overly stiff at 120 Hz.

Havok provides an adaptive solver settings option (m_adjustSolverSettingsBasedOnTimestep) that automatically adjusts tau, damping, and solver iterations on the fly to maintain consistent constraint stiffness across variable timesteps. The reference point is defined by m_expectedDeltaTime, and the allowed iteration range can be bounded to keep CPU cost predictable.

For studios using fixed timesteps (recommended for determinism), this feature is not needed. For titles with variable frame rates or substepping, it maintains consistent simulation feel without manual parameter adjustment per frame.

Standard tau/damping error correction works well for contacts and simple constraints but can be insufficient for joint constraints under high stress. Ball-and-socket joints, hinges, limited hinges, and ragdoll constraints can exhibit visible pivot-point separation when bodies are subject to large forces or high angular velocities – the “rubber banding” effect visible at shoulders, hips, or elbows.

Havok provides stabilization atoms as an enhanced solving method for these cases. The stabilization atom (hknpSetupStabilizationAtom) pre-computes parameters that improve error recovery for the ball-and-socket constraint atom when its solving method is set to stabilized mode. This provides better results for configurations where standard positional error correction under-corrects.

The stabilized solving method is available on all constraints that use the ball-and-socket atom – covering ball-and-socket, hinge, limited hinge, and ragdoll constraints. It is enabled per-constraint, so it can be applied selectively to the joints where pivot drift is a visual quality concern.

Solver convergence is fundamentally limited by the condition number of the constraint system. The condition number worsens when constrained bodies have very different masses or inertia tensors – a thin, light forearm bone constrained to a massive torso body is a poorly conditioned system that the iterative solver struggles to resolve.

Havok provides utility functions that address this at the asset level, with no per-frame runtime cost:

• Inertia optimization adjusts body inertia tensors across a ragdoll skeleton so that each body’s inertia is within some factor of the summed inertias of its children. This makes the effective mass ratios across the constraint chain more uniform, directly improving solver convergence. The optimization makes inertias more “box-like” and helps balance the inertia hierarchy. Note that the optimization does not fully converge in a single call – each subsequent call will continue to refine the system inertia, so multiple passes can be applied at asset setup time if additional refinement is needed.
• Mass optimization redistributes mass between bodies in a ragdoll without changing the total system mass, ensuring stable mass ratios between constrained bodies.

The result: a constraint system that converges faster with fewer iterations, producing stiffer joints and less visible separation at the same solver budget. These are authoring-time fixes that pay off every frame without consuming any runtime CPU.

Not all constraints in a scene need the same solving fidelity. Ground contacts on a static floor converge easily. A digger with a heavy load in the bucket requires significantly more iterations.

Havok’s constraint group system allows studios to assign constraints to groups, each with an independent micro-step multiplier. Groups with a multiplier greater than 1 receive additional solver iterations each solver sub-step. The cost is proportional to the multiplier and isolated to the constraints in that group – the rest of the scene continues at the base iteration count.

This multiplier can be adjusted at runtime without penalty, enabling dynamic quality management. A ragdoll in the player’s immediate view could receive a higher multiplier than one at the edge of the screen. A vehicle being actively driven could receive more iterations than one parked in the background.

For studios evaluating solver cost management, this means the global iteration count can be set conservatively for the common case, with targeted overrides applied precisely where constraint quality demands it.

For constraint systems where iterative convergence is fundamentally too slow – particularly systems with large mass ratios or where exact constraint satisfaction is required – Havok provides a direct solver option.

The direct solver operates on a constraint group and solves all constraints in the group simultaneously rather than one at a time, eliminating the slow convergence problem that iterative solvers experience with large mass ratios. Where the iterative solver’s convergence is limited by the lightest body in a chain, the direct solver considers all constraints together and reduces errors at all joints simultaneously.

The direct solver is particularly effective for:

• Long ragdoll chains where impulse propagation through many lightweight bodies is slow under iterative solving.
• Mechanical assemblies (cranes, chains, articulated machinery) where visible joint separation is unacceptable.

An accurate single constraint solver is also available for individual constraints (doors, windows, individual hinges) that need exact solutions, at a modest additional cost over the iterative solver. This solver is designed for isolated constraints – for multi-constraint systems such as chains, ragdolls, or vehicles, the constraint group direct solver is the appropriate tool.

Important limitations: the direct solver operates on linearized constraint equations, so large rotations within a single timestep can still introduce errors – smaller timesteps are needed for high-rotation scenarios. Motor atoms are optionally supported but can cause jitter when motors frequently switch between limited and unlimited modes.

For certain use cases constraints can be spread across both the direct solver and iterative solver to achieve the desired results.

As a physics extension, Havok provides optional positional constraint iterations (post-projection) that directly move body transforms to reduce joint separation after the velocity solve. Unlike velocity-based solving, post-projection changes positions without introducing velocities, which can eliminate visible joint gaps without causing the instabilities that large corrective impulses would produce.

Post-projection is generally called after the solve phase so that joint errors are reduced before bodies are rendered, though it can also be invoked at other stages of the simulation.

A notable variant is shock propagation, which propagates positional corrections hierarchically through the constraint chain. Shock propagation can eliminate joint separations more effectively and in fewer iterations than standard post-projection.

The trade-off is that post-projection operates independently of the contact system. Because positional correction moves body transforms directly without re-evaluating contacts, it can place bodies into penetrating states. This is a fundamental design trade-off: joint accuracy is prioritized over contact response. Studios should apply post-projection selectively – typically on ragdolls or constraint chains where visible joint separation is the primary quality concern – and validate that the corrected configurations do not introduce unacceptable penetration

Constraint solving has inherently sequential dependencies – solving one constraint updates body velocities that affect neighboring constraints. Naive parallelization causes race conditions or requires excessive synchronization.

Havok addresses this by partitioning bodies into spatial groups (cells), identifying constraint dependencies between those groups (links), and ordering constraints by priority (grids). Contact constraints are prioritized above joint constraints, and static-to-dynamic contacts receive the highest priority. Higher-priority groups are solved last, ensuring they “win out” over lower-priority constraints.

Each combination of link and priority level produces a solve task. Tasks that affect different groups of bodies can execute in parallel without data races, allowing the solver to scale automatically across available cores.

The spatial partitioning system exploits temporal coherence to maintain balanced workloads – newly added bodies are assigned to the nearest existing group. To avoid sudden imbalances, bodies should be added incrementally across multiple simulation steps where possible.

Studios do not need to manually partition work or manage solver threading. The system scales automatically to available cores, which simplifies integration and reduces the engineering surface area during optimization passes.

Havok’s solver settings form a layered system that allows studios to set sensible defaults and override them precisely where needed:

At the highest level, solver type presets (hknpWorldCinfo::setSolverType()) configure substeps, tau, and damping to tested defaults. Studios can also set lower-level parameters directly for finer control.

This hierarchy means physics teams do not need to over-budget the global iteration count to satisfy the most demanding constraints. The base settings handle the common case efficiently, while targeted group and per-constraint overrides address specific quality requirements at proportional cost.

The following scenarios form a practical test matrix for assessing solver quality during a Havok integration assessment. Each reveals specific solver characteristics and maps to concrete configuration levers.

For each scenario, the tuning process follows a consistent pattern: start with default settings, identify the specific constraint quality issue (separation, jitter, softness), then apply the most targeted fix available – per-constraint stabilization before group multipliers, group multipliers before global iteration increases.

The solver architecture described in this post – PGS iteration, Baumgarte error correction, the direct solver, stabilization atoms, inertia optimization, and automatic multithreaded scheduling – represents a coherent system designed for production-scale constraint solving. Each mechanism addresses a specific class of problem, and the layered configuration hierarchy provides precise control without requiring global compromises.

The scenarios outlined in this document can be used as reference points for how to construct your games’ use case with Havok Physics. A comprehensive implementation strategy is fundamental to getting the best possible performance and behavior in your game. The Havok team can support this process with an evaluation license and direct engineering guidance. Contact us to start an evaluation