This change also requires user scripts to explicitly synchronize changes to physics state to the viewer. The Simulate class was reconfigured so that certain UI events are handled during this sync operation, outside of the render loop on the main thread. These correspond to operations that require access to the full mjModel/mjData.
To support other, more interactive operations (e.g. camera movements), a new mjvSceneState struct is introduced which captures only the portion of the physics state required for scene re-rendering. The mjvSceneState is updated from mjModel/mjData during the viewer sync operation, and is significantly cheaper than a full mj_copyModel and mj_copyData.
Fixes https://github.com/deepmind/mujoco/issues/796
PiperOrigin-RevId: 525723636
Change-Id: Id08d0210a2c067d5afe85e2bf104f276aeddd75e
Also missing struct fields to the Python bindings that were discovered as a result of the new `introspect` metadata.
PiperOrigin-RevId: 523947396
Change-Id: I367fd2dc8d5fd7e5712a45b70a5c50da51d152e4
Before this change, these functions can return before an internal call to `mj_forward`, which results in a race condition if the user script then tries to modify the physics state.
Fixes#783Fixes#790
PiperOrigin-RevId: 523214378
Change-Id: I8a4c6cef0f5d3ec781fd2c5cae3c20dd4b8be67f
This allows rendering from non-main threads as the context is not tied to a Cocoa window.
Fixes#742Fixes#798
PiperOrigin-RevId: 523144359
Change-Id: I98432debdd034814c313eda94e38c248c3c1f76c
Previously, it returned a view into the internal rgb array, which can be confusing to the user.
PiperOrigin-RevId: 517630186
Change-Id: Ibc1e86b6b6345269523bb4c82c37dd325961a8ec
- Find Python functions in the interpreter binary itself rather than trying to find libpython.dylib, because this doesn't exist when using Conda. (https://github.com/conda-forge/python-feedstock/issues/595#issuecomment-1311275470)
- Increase the stack size of both the Python main thread and the OS main thread to 16MiB, to match what Python normally uses on macOS. (https://github.com/python/cpython/blob/3.11/configure#L11038)
- Check whether dlfcn and pthread function calls actually succeeds. Emit error messages and exit on failure rather than continuing the program (which generally leads to segfaults).
- Fix pixelated shadow in the icon.
PiperOrigin-RevId: 517390522
Change-Id: Ib91679b4baa63bac5f6b5893e634712d72161ea5
It is quite possible that there are a few other fields still missing since we currently do not yet have automated testing of struct field existence.
Fixes#747.
PiperOrigin-RevId: 517189048
Change-Id: I7c1d95e700eaea05aaa3cde1fd05e1a259553117
The `launch_passive` function launches the GUI viewer in a non-blocking manner, allowing the Python script or REPL to continue execution. The viewer is automatically kept up to date with any subsequent modifications to mjModel and mjData.
Note that when run inside a REPL (including IPython), `launch_passive` is functionally identical to `launch_repl`.
On Linux and Windows, this is achieved by spawning a new thread and launching the GUI there.
On macOS, this is not possible as all Cocoa API calls must be made on the "macOS main thread", which is always the first thread launched in a process and carries the `com.apple.main-thread` dispatch queue. We also cannot simply trampoline from a Python script on the main thread into the user's script on a side thread because CPython's signal handler can only be installed on the "Python main thread". Putting the user's script in a side thread means that it cannot e.g. gracefully handle SIGINT by catching a KeyboardInterrupt exception. To work around this, we ship a custom Python launcher on macOS called `mjpython`. This launcher is a native binary that spawns a pthread and initialize the Python interpreter on that thread, thus allowing "Python main thread" and "macOS main thread" to represent two distinct threads. From Python's point of view, the "macOS main thread" is a secondary thread that runs a loop that continuously empties a Queue of (mjModel, mjData) and launches a viewer.
PiperOrigin-RevId: 517167868
Change-Id: Icac9d2126bbb4760d47e0b9300e0a979cffa4338
Also unify warning options across Clang and GCC and fix minor issues that was surfaced by this.
PiperOrigin-RevId: 508619655
Change-Id: I59b777bf2dfea4422485670e2427c7d3f5cf6405
Since the introduction of arena memory, these fields now have dynamic sizes that change between time steps depending on the number of active constraints. This breaks strict correspondence between joints and `efc_` rows.
Note that these fields can still be accessed directly as attributes on the `MjData` object.
PiperOrigin-RevId: 508342388
Change-Id: I610ae6ca462f6bb5cf8bc199a3436bed3d1a5371
The use of `np.empty` triggers an msan use-of-uninitialized-value error when upgraded.
PiperOrigin-RevId: 503975799
Change-Id: I337c8227c8c1e3bd415d7a798fc5e764c88c0875
1. Links to the programming chapter were broken after 69c74f850e. They're now fixed with a redirect in readthedocs.io, but this commit updates them to the latest URL.
2. Most docs links should point to "stable" instead of "latest", since most users will want the docs for the released version, not the upcoming version. The exceptions are the programming chapter, and instructions for building the Python bindings from source.
PiperOrigin-RevId: 502821526
Change-Id: If0a55ab2be4751ba0165bf644030464234083133
Also allow a `Callable[[], [MjModel, MjData]]` to be provided as an argument to `launch` instead of a fixed MjModel/MjData instance. This allows users to customise the behaviour of the Reload button.
Context: https://github.com/deepmind/mujoco/discussions/576#discussioncomment-4161429
PiperOrigin-RevId: 492296268
Change-Id: Ic4b797d2ea8a6967f7e3e7316f2184ea94a86d8b
Current users only get a cryptic "Illegal instruction" crash.
Context: https://github.com/deepmind/mujoco/issues/611
PiperOrigin-RevId: 491705647
Change-Id: I1285897a36e858300ee3d125957e90754be9a7f7
Nimrod Gileadi