I haven’t built this into a debug class, but here’s what I’ve got so far. Almost posted as another thread but don’t want to pollute.
Visualizing constraints’ linear axes.
First, the cool visualization. After loading, tap for chaos.
Looking for feedback on this theory. I haven’t seen it presented this way, but I can’t say I’ve read all the documentation. Regarding the AxisMode of PhysicsConstraints, is there anything wrong with this way of thinking about it?
–
There are three vectors and one point that are user-specified on each of two bodies in a PhysicsConstraint. These axes are called Axis, perpAxis, and the (unnamed) normal to Axis and perpAxis. These form three orthogonal axes with their origin at the user-defined point called Pivot. One body is called A, or Parent, and the other is called B, or Child.
Each of these axes has a LINEAR component and an ANGULAR component, where LINEAR references position along the axis and ANGULAR references rotation around that axis. In this context, X, Y, and Z are references to Axis, PerpAxis, and the Normal, respectively.
A user can place fixed upper and lower limits on each of these axes. These limits constitute a box relative to box A’s axes within which body B’s Pivot is constrained.
Here is a visualization of this. In the playground, boxA is red and boxB is yellow. BoxB’s Pivot is purple and the linear constraints are visualized as a gray box. Gravity is set to zero and each body has the same mass. Tapping the screen imparts a force to boxB. Note how the purple Pivot says within the gray limits. When the yellow box reaches its limits, momentum is transferred to boxA (through the constraint) and boxA moves as a result.
All possible constraint combinations (see this post) are shown. This is the same demo as the first link, but with non-cube limits:
If you modify the code to attach the limits box to boxB instead of A, then it’s not seeming to constrain boxA. I think this substantiates the theory above.