For each contact point, we used to first compute the vertex weights on a triangle and then add a contact point per vertex using the flex interpolation (trilinear or quadratic), obtaining the total weight by multiplying the vertex weight and the basis function value at that vertex. After this change, each contact point is added directly by evaluating the basis function directly a the point.
PiperOrigin-RevId: 834218909
Change-Id: Ic0fdb03fc0ef5478798c293df99204fd33116fd1
This ensures that at e.g. the barycenter of the triangle each vertex has weight 1/3, as one would expect with barycentric coordinates, rather than 1/sqrt(3). This makes it consistent to the finite element interpolation used in the passive elastic forces.
PiperOrigin-RevId: 823458736
Change-Id: Ia5c02cba186a80612de38402f791695c33e991ab
This is a more general API in preparation of a higher interpolation order
PiperOrigin-RevId: 820174741
Change-Id: I81bd52ab44e0485d72579e21d1c8a48a1b35ec3f
These flexes use only 24 DOFs (3 per vertex of the bounding box), while colliding with the full high resolution mesh.
On an 8x8x8 cube, the performance using DOFs at all vertices is
```
Simulation time : 18.74 s
Steps per second : 533
Realtime factor : 0.53 x
Time per step : 1874.4 µs
Contacts per step : 114.88
Constraints per step : 3322.51
Degrees of freedom : 1536
```
With the new implementation, it is the following:
```
Simulation time : 1.82 s
Steps per second : 5507
Realtime factor : 5.51 x
Time per step : 181.6 µs
Contacts per step : 38.84
Constraints per step : 155.36
Degrees of freedom : 24
```
PiperOrigin-RevId: 721008829
Change-Id: I833df027527db578d86667cc4b24295bcf6f7d22
- `qLDiagSqrtInv` is only required for the dual solvers. It is now computed as-needed rather than unconditionally.
- `mj_solveM2` now requires a new input array `sqrtInvD` which contains the square root of the inverse diagonal D (formerly saved in `qLDiagSqrtInv`).
PiperOrigin-RevId: 710805133
Change-Id: I0622d6a8da3882916824e9c10bad9223c122c321
The introduction of site specification to connects and welds in 3.2.3 conditionally changed the semantics of `mjData.eq_obj1id` and `mjData.eq_obj2id`. These changes were not properly propagated in several places leading to incorrect computations of constraint inertia, readings of affected force/torque sensors and runtime enabling/disabling of such constraints.
PiperOrigin-RevId: 690670420
Change-Id: I55ee8a013cbee8457f8d6c7f33c2981aedafbab6
When counting nl and nc, the nnz is optionally also counted when in sparse mode. However, the functions mj_nl and mj_nc unconditionally counts nnz into a temporary accumulator, then only afterwards check whether the output nnz pointer is NULL.
When not in sparse mode, ten_J_rownnz does not get initialized by mj_tendon, however mj_nl and mj_nc are accumulating potentially spurious data from ten_J_rownnz into the temporary accumulator. While the spurious result eventually gets discarded, UBsan nevertheless detects an integer overflow in the temporary accumulator.
PiperOrigin-RevId: 662443910
Change-Id: I78a9a088d4db7f16be779c7d669167d6fb3e4401
This CL does not change the default build behavior of MuJoCo. To use single-precision floating-point, build MuJoCo with `-DmjUSESINGLE`.
PiperOrigin-RevId: 644782648
Change-Id: Ie815df9916798ca8054306437b39a33f84ce9e08
These functions names and argument ordering are more consistent with the rest of the API.
PiperOrigin-RevId: 643788290
Change-Id: I783eda8021b80b82098e23ed95669b102bb82508
Yuval Tassa