This module has been deprecated for many months and its replacement is jax.ffi.
PiperOrigin-RevId: 808567797
Change-Id: I5b4f4eee5e65ccd86e597c5761e68c36292b6209
Also:
- update the namespace to `toolbox` (instead of `filament`)
- Add copyright notices to all files
PiperOrigin-RevId: 808474353
Change-Id: Id1fe86c5d183c8e91bec8509b6c0830b5fe84c1c
This is done by detecting the hanging nodes and compute the function at those location by interpolating the corresponding coarse vertices.
PiperOrigin-RevId: 807700228
Change-Id: I27dcb85361ca445c2099dd07b280cae5c92d3131
This means that two adjacent nodes can only have at most one level of refinement difference.
Note: This is a small breaking change for mjWarp since the order of the children was flipped.
PiperOrigin-RevId: 806299445
Change-Id: Ia326a31c7a8162ae02d70c868d87779198e805be
The octree construction is now performed using a breadth-first search with a `std::deque` to manage tasks. A new `OctreeTask` struct encapsulates the state for each node to be processed, and a helper function `Subdivide` is introduced for subdividing the Octree nodes.
Also reduce the number of (center, size) to (min, max) conversion for the bounding box representation in order to avoid duplicated vertices in the Octree due to floating point errors.
PiperOrigin-RevId: 806214441
Change-Id: Iff9015ebe4705522db743c478cef5acf1a7312b7
Previously, it was assumed that attaching was the last operation performed on the mjSpec, so keyframes resulted in the incorrect size. In order to prevent information loss, we now only allow the resize function to expand the keyframe array, since attach should never remove a degree of freedom.
PiperOrigin-RevId: 804917828
Change-Id: Icfacd207ced1c6aac600d514f8d9065ceff2d347
This ensures that Python bindings build also uses GLFW 3.4, similar to C/C++
MuJoCo.
The hashes are from https://pypi.org/project/glfw/2.9.0/#files.
PiperOrigin-RevId: 802536702
Change-Id: Ie9cfc17a5f9146fe6731681115f7aaa98fcb323e
The previous instructions use a pre-built binary from MuJoCo and do not cover
the use-case of building C/C++ and Python bindings from the same codebase.
PiperOrigin-RevId: 802060401
Change-Id: I6d0b9c7c2269ff596ac706b716ff6c95b42c5d99
This makes it possible to build open-source MuJoCo with Wayland support out of
the box.
Currently, it is necessary to run cmake with -DGLFW_USE_WAYLAND=ON and ensure
cmake can find the "ECM" package somehow (a dependency of the 3.3.6 version of
GLFW), for which there is no automated fetching setup. As this is no longer a
dependency of GLFW it seems to make more sense to update GLFW to make out of the
box builds on Wayland.
PiperOrigin-RevId: 800456607
Change-Id: Iffdf1d65319bfb134e580faceb63ac3bed7b9c84
Baruch Tabanpour