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:
- Renamed recently introduced `mjvPerturb` member `reflocalpos` -> `refselpos` and corrected docstring.
- Added `mjvPerturb.localmass`: body spatial inertia at selection point.
- Removed `const` qualifier to `mjData` argument of `mjv_initPerturb()`, to facilitate spatial inertia computation.
- Improved `mj_Object{Velocity, Acceleration}` docstrings, clarifying that rotational velocities precede linear velocities.
- Removed redundant const qualifiers from non pointer arguments to `mju_dot` and `mju_writeNumBytes`.
PiperOrigin-RevId: 511002168
Change-Id: I27400f497947f330072d4abb7c9bf7e71e6c5d49
This PR added necessary annotations, following what we did for mjData
and mjModel for length of the given array.
This is useful because my parser used to generate Swift interface:
https://github.com/liuliu/swift-mujoco/blob/main/Sources/codegen/main.swift#L297
such that the access to underlying array is bound-checked.
Please let me know if this makes sense. After this change, I can
successfully generate all mj* struct interfaces in Swift without problem
(with notable exception of mjui): https://github.com/liuliu/swift-mujoco/tree/main/Sources
Alessio Quaglino