This allows us to use GLFW without needing to introduce a link-time dependency on the library, which in turn enables us to get GLFW through Python.
PiperOrigin-RevId: 470100999
Change-Id: I27c84ad3310afdbebd582ab0033b6a963ba6307e
- `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: 470021901
Change-Id: I3faba0e5dcab2e29ee81096f5ff71ff66d99758c
- `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
Yuval Tassa