- `anchor` determines the point of wrench application, in the frame of body2.
- `tfratio` scales applied torques relative to applied forces.
- Add visualisation of both anchor points to both weld and connect constraints.
- Add a test model showing how the new weld parameters behave.
PiperOrigin-RevId: 469228149
Change-Id: I836b0791f10fb624607a12ef3c687da991c21789
- `anchor` determines the point of wrench application, in the frame of body2.
- `tfratio` scales applied torques relative to applied forces.
- Add visualisation of both anchor points to both weld and connect constraints.
- Add a test model showing how the new weld parameters behave.
PiperOrigin-RevId: 469190483
Change-Id: I20f6da85b09cd2c4c0b5d29eb8003eabb524e55e
* If output file exists, ask user whether to overwrite
* Fix erroneous check for whether XML file was successfully saved
PiperOrigin-RevId: 468743682
Change-Id: I06058c498328d333792e4b40d65c3a99ca1842e4
- `distance` constraints were not very useful and increased the contact buffer within the constraint solver, violating a core design principle. Therefore they have been removed.
- The enum value `mjEQ_DISTANCE` is retained, but errors will be thrown in the parser and engine if these constraints are selected.
PiperOrigin-RevId: 467050101
Change-Id: Ie72a07e4fe338eea5107004a9fc0f5e47eb0c3b7
This is a very subtle leak caused interaction between longjmp and compiler optimisation. Specifically, at the point where the setjmp takes places, these pointers have never been reassigned from its nullptr initialization. Without the volatile keyword, the compiler is free to assume that these pointers remain nullptr when the setjmp returns, and therefore to pass nullptr directly to the mj_deleteModel and mj_deleteData calls in the subsequent catch block, without ever reading the actual pointer values.
PiperOrigin-RevId: 466649447
Change-Id: I51e82ec8b566deb144221e11a99d5124a8267de4
The memory handling in the asset loading logic in user_mesh.cc is currently flipped: it frees the asset content buffer when reading from VFS but not from the filesystem. This causes the VFS object to leave these functions in an invalid state, while leaking locally allocated buffers that hold contents read from the filesystem.
PiperOrigin-RevId: 466643390
Change-Id: I162221e019861f23fb61308facd63dbb0422e113
Currently, if these functions fail to allocate space for the buffer or stack, it will exit without freeing any of the memory successfully allocated so far.
PiperOrigin-RevId: 466271030
Change-Id: Id01c115ec976482ac5d28c373b5eb47d77f424be
The MSVC build on GH Actions doesn't detect overflows in mjData or mjModel sizes, so use a negative size instead to trigger an intentional failure in the test.
PiperOrigin-RevId: 465529615
Change-Id: Ic7f15eed782cdda11b29984b136ed4f625418cc8
- Add `azimuth` and `elevation` to `visual.global`.
- Add `mjv_defaultFreeCamera`.
- Use `mjv_defaultFreeCamera` in `simulate`.
PiperOrigin-RevId: 465505244
Change-Id: I61e60f14a990d4e2d220958adb75c325001978ee
Explicitly check that nmocap won't cause overflow when multiplied by 4, to give a nicer error message.
PiperOrigin-RevId: 465380712
Change-Id: I217e3759d55e9761b47db5efd892b8bc811ea8ae
While creating an mjData, any error triggers mj_deleteData. If buffer or stack is not NULL at that point, an uninitialized pointer will be freed.
PiperOrigin-RevId: 465378329
Change-Id: I9be0eef0648e05e3e5f1361da346a5046485cde7
nbody is already checked to be non-negative, but various pieces of code assume it's nonzero (because there's always a world body).
PiperOrigin-RevId: 465339241
Change-Id: I38ce3764074d03bf9a703aa490964c1eb83cc1da
Yuval Tassa