Px1DConstraint

struct Px1DConstraint

A one-dimensional constraint that constrains the relative motion of two rigid bodies.

A constraint is expressed as a set of 1-dimensional constraint rows which define the required constraint on the objects’ velocities.

The constraint Jacobian J is specified by the parameters linear0, angular0, linear1, angular1 as follows

J = {linear0, angular0, -linear1, -angular1}

The velocity target of the constraint is specified by Px1DConstraint::velocityTarget and the geometric error of the constraint is specified by Px1DConstraint::geometricError.

The output of the constraint is a velocity state (sdot = ds/dt with s denoting the constraint state) expressed in the world frame:

sdot = {linearVelocity0, angularVelocity0, linearVelocity1, angularVelocity1}

with linearVelocity0 and angularVelocity0 denoting the linear and angular velocity of body0 of the constraint; and linearVelocity1 and angularVelocity1 denoting the linear and angular velocity of body1 of the constraint.

The constraint seeks an updated sdot that obeys a simple constraint rule:

J*sdot + BaumgarteTerm*geometricError/dt - velocityTarget = 0

where BaumgarteTerm is a multiplier in range (0, 1). The Baumgarte term is not exposed but is instead internally set according to a simple metric chosen to enhance numerical stability. If the PGS solver is employed then dt is taken from the scene timestep.

Another way of expressing the constraint rule is as follows:

linear0.dot(linearVelocity0) + angular0.dot(angularVelocity0) 
- linear1.dot(linearVelocity1) - angular1.dot(angularVelocity1)
+ BaumgarteTerm*geometricError/dt - velocityTarget = 0

The PhysX solver runs two phases: position iterations followed by velocity iterations. Position iterations derive the velocity that is used to integrate the transform of a rigid body. Velocity iterations on the other hand derive the final velocity of a rigid body. The constraint rule presented above only gets applied during position iterations, during velocity iterations the geometricError term is usually ignored and the applied constraint rule is:

J*sdot - velocityTarget = 0

The flag Px1DConstraintFlag::eKEEPBIAS can be used to have velocity iterations apply the same constraint rule as position iterations.

A 1d constraint may be either a restitution constraint or a hard constraint or a spring constraint.

Restitution constraints have two modes of operation, depending on the speed of the constraint. These two modes are: a) a bounce mode that employs a restitution value specified by RestitutionModifiers::restitution b) a non-bounce mode that employs zero restitution and ignores RestitutionModifiers::restitution. The constraint speed immediately before the solver begins is computed as follows: constraintPreSolverSpeed = J * sdotPreSolver with sdotPreSolver denoting the rigid body velocities recorded after applying external forces and torques to the rigid bodies but before the solver begins. If the bounce mode is active, the pre solver velocity is expected to flip direction and have restitution applied: bounceSpeed = -restitution * constraintPreSolverSpeed Restitution will kick in if the following conditions are met:

-constraintPreSolverSpeed exceeds the bounce threshold (RestitutionModifiers::velocityThreshold)
(bounceSpeed * Px1DConstraint::geometricError) <= 0 (bounceSpeed points in the opposite direction of the geometric error) If these hold, then the provided Px1DConstraint::geometricError and Px1DConstraint::velocityTarget parameter will get overriden internally. The former will get set to zero, the latter will get set to bounceSpeed. If restitution does not activate because the listed conditions are not met, then the target velocity will be taken from the value stored in velocityTarget and the geometric error will be taken from the value stored in geometricError. RestitutionModifiers::restitution may be greater than 1 and may be less than 0 ie it is not limited to 0 <= restitution <= 1.

Hard constraints attempt to find sdot that satisfies the constraint equation:

J*sdot + BaumgarteTerm*geometricError/dt - velocityTarget = 0

Spring constraints are quite different from restitution and hard constraints in that they attempt to compute and apply a spring force as follows:

F = stiffness * -geometricError + damping * (velocityTarget - J*sdot)

where F is the constraint force or acceleration and J*sdot is the instantaneous constraint speed. Springs are implemented with a fully implicit time-stepping scheme: that is, the force or acceleration is a function of the position and velocity after the solve. Note that F gets applied to the first rigid body and -F to the second rigid body.

All constraints support limits on the minimum or maximum impulse applied.

Public Members

PxVec3 linear0: linear component of velocity jacobian in world space

PxReal geometricError: geometric error of the constraint along this axis

PxVec3 angular0: angular component of velocity jacobian in world space

PxReal velocityTarget: velocity target for the constraint along this axis

PxVec3 linear1: linear component of velocity jacobian in world space

PxReal minImpulse: minimum impulse the solver may apply to enforce this constraint

PxVec3 angular1: angular component of velocity jacobian in world space

PxReal maxImpulse: maximum impulse the solver may apply to enforce this constraint

PxReal stiffness: spring parameter, for spring constraints

PxReal damping: damping parameter, for spring constraints

struct Px1DConstraint::[anonymous]::SpringModifiers spring

PxReal restitution: restitution parameter for determining additional “bounce”

PxReal velocityThreshold: minimum impact velocity for bounce

struct Px1DConstraint::[anonymous]::RestitutionModifiers bounce

union Px1DConstraint::[anonymous] mods

PxU16 flags: a set of Px1DConstraintFlags

PxU16 solveHint: constraint optimization hint, should be an element of PxConstraintSolveHint

PxU32 pad