From e82cb9f420997ded5bf6d84910d7bb125e46f885 Mon Sep 17 00:00:00 2001 From: Yuval Tassa Date: Wed, 1 Nov 2023 06:43:32 -0700 Subject: [PATCH] Delete mentions of MuJoCo 2.0 in the docs. PiperOrigin-RevId: 578501679 Change-Id: Ie1fdd1d11d2e1e12b3f9f1e59bd4da705b3a7c7e --- doc/XMLreference.rst | 18 +++++++++--------- doc/modeling.rst | 22 ++++++++++------------ doc/programming/index.rst | 2 +- doc/programming/samples.rst | 2 +- 4 files changed, 21 insertions(+), 23 deletions(-) diff --git a/doc/XMLreference.rst b/doc/XMLreference.rst index d442aa9e..95220f79 100644 --- a/doc/XMLreference.rst +++ b/doc/XMLreference.rst @@ -1082,9 +1082,9 @@ file. color in GL_MODULATE mode. The texture data can be loaded from PNG files, with provisions for loading cube and skybox textures. Alternatively the data can be generated by the compiler as a procedural texture. Because different texture types require different parameters, only a subset of the attributes below are used for any given texture. -| MuJoCo 2.0 introduced a second file format for loading textures, in addition to PNG. If the file name extension is +| A second file format is supported for loading textures, in addition to PNG. If the file name extension is different from .png or .PNG, or if the ``content_type`` attribute is set to ``image/vnd.mujoco.texture``, then MuJoCo - assumes that the texture is in the new format. This is a custom binary file format, containing the following data: + assumes that the texture is in this format. This is a custom binary file format, containing the following data: .. code:: Text @@ -1397,7 +1397,7 @@ attribute of the :ref:`compiler ` element which controls the automatic appearance (including texture mapping) is controlled by the :at:`material` and :at:`rgba` attributes of the referencing geom, similarly to height fields. -Starting with MuJoCo 2.0, meshes can have explicit texture coordinates instead of relying on the automated texture +Meshes can have explicit texture coordinates instead of relying on the automated texture mapping mechanism. When provided, these explicit coordinates have priority. Note that texture coordinates can be specified with OBJ files and MSH files, as well as explicitly in the XML with the :at:`texcoord` attribute, but not via STL files. These mechanism cannot be mixed. So if you have an STL mesh, the only way to add texture coordinates to it is @@ -1431,17 +1431,17 @@ specified as OBJ or XML and an error message is returned. The size of the mesh is determined by the 3D coordinates of the vertex data in the mesh file, multiplied by the components of the :at:`scale` attribute below. Scaling is applied separately for each coordinate axis. Note that negative scaling values can be used to flip the mesh; this is a legitimate operation. The size parameters of the -referening geoms are ignored, similarly to height fields. As of MuJoCo 2.0 we also provide a mechanism to translate and -rotate the 3D coordinates, using the attributes refpos and refquat. +referening geoms are ignored, similarly to height fields. We also provide a mechanism to translate and +rotate the 3D coordinates, using the attributes :ref:`refpos` and :ref:`refquat`. -Another new feature in MuJoCo 2.0 is that a mesh can be defined without faces (a point cloud essentially). In that case +A mesh can also be defined without faces (a point cloud essentially). In that case the convex hull is constructed automatically, even if the compiler attribute convexhull is false. This makes it easy to construct simple shapes directly in the XML. For example, a pyramid can be created as: .. code-block:: xml - + Positioning and orienting is complicated by the fact that vertex data are often designed relative to coordinate frames @@ -4242,7 +4242,7 @@ Finally, the skin can be inflated by applying an offset to each vertex position Skins are one-sided for rendering purposes; this is because back-face culling is needed to avoid shading and aliasing artifacts. When the skin is a closed 3D shape this does not matter because the back sides cannot be seen. But if the skin is a 2D object, we have to specify both sides and offset them slightly to avoid artifacts. Note that the -composite objects introduced in MuJoCo 2.0 generate skins automatically. So one can save an XML model with a composite +composite objects generate skins automatically. So one can save an XML model with a composite object, and obtain an elaborate example of how a skin is specified in the XML. Similar to meshes, skins can be specified directly in the XML via attributes documented later, or loaded from a binary @@ -4641,7 +4641,7 @@ has multiple obstacle geoms they must be separated by sites - so as to avoid the tendon level. This example illustrates a multi-branch tendon acting as a finger extensor, with a counter-weight instead of an actuator: `tendon.xml <_static/tendon.xml>`__. -MuJoCo 2.0 introduced a second form of wrapping, where the tendon is constrained to pass through a geom rather than +A second form of wrapping is where the tendon is constrained to pass *through* a geom rather than wrap around it. This is enabled automatically when a sidesite is specified and its position is inside the volume of the obstacle geom. diff --git a/doc/modeling.rst b/doc/modeling.rst index 165a9cd3..31a6e4b4 100644 --- a/doc/modeling.rst +++ b/doc/modeling.rst @@ -453,7 +453,7 @@ solref, solimp If one of the two geoms has higher priority, its solref and solimp parameters are used. If both geoms have the same priority, the weighted average is used. The weights are proportional to the solmix attributes, i.e., weight1 = solmix1 / (solmix1 + solmix2) and similarly for weight2. There is one important exception to this weighted averaging - rule. If solref for either geom is non-positive, i.e., it relies on the new direct format introduced in MuJoCo 2.0, + rule. If solref for either geom is non-positive, i.e., it relies on the direct format, then the element-wise minimum is used regardless of solmix. This is because averaging solref parameters in different formats would be meaningless. @@ -792,7 +792,7 @@ can be either in degrees (the default) or radians, depending on the :ref:`compil Muscles ''''''' -MuJoCo 2.0 provides a set of tools for modeling biological muscles. Users who want to add muscles with minimum +We provide a set of tools for modeling biological muscles. Users who want to add muscles with minimum effort can do so with a single line of XML in the actuator section: .. code-block:: xml @@ -992,13 +992,13 @@ be 0. This effect can be approximated by scaling down the muscle force and also Tendon wrapping is also more limited in MuJoCo. We allow spheres and infinite cylinders as wrapping objects, and require two wrapping objects to be separated by a fixed site in the tendon path. This is to avoid the need for iterative -computations of tendon paths. As of MuJoCo 2.0 we also allow "side sites" to be placed inside the sphere or cylinder, +computations of tendon paths. We also allow "side sites" to be placed inside the sphere or cylinder, which causes an inverse wrap: the tendon path is constrained to pass through the object instead of going around it. This can replace torus wrapping objects used in OpenSim to keep the tendon path within a given area. Overall, tendon wrapping is the most challenging part of converting an OpenSim model to a MuJoCo model, and requires some manual work. On the bright side, there is a small number of high-quality OpenSim models in use, so once they are converted we are done. -Below we illustrate the four types of tendon wrapping available in MuJoCo 2.0. Note that the curved sections of the +Below we illustrate the four types of tendon wrapping available. Note that the curved sections of the wrapping tendons are rendered as straight, but the geometry pipeline works with the actual curves and computes their lengths and moments analytically: @@ -1058,8 +1058,7 @@ Intrinsics Composite objects ~~~~~~~~~~~~~~~~~ -Composite objects were introduced in MuJoCo 2.0, along with solver optimizations to speed up the simulation of such -objects. They are not new model elements. Instead, they are (large) collections of existing elements designed to +Composite objects are not new model elements. Instead, they are (large) collections of existing elements designed to simulate particle systems, ropes, cloth, and soft bodies. These collections are generated by the model compiler automatically. The user configures the automatic generator on a high level, using the new XML element :ref:`composite ` and its attributes and sub-elements, as described in the XML reference @@ -1081,7 +1080,7 @@ of these equality constraints can be adjusted by the user, thereby adjusting the composite objects. In addition to setting up the physics, the composite object generator creates suitable rendering. 2D and 3D objects -can be rendered as :ref:`skins ` which are also new in MuJoCo 2.0. The skin is generated +can be rendered as :ref:`skins `. The skin is generated automatically, and can be textured as well as subdivided using bi-cubic interpolation. The actual physics and in particular the collision detection are based on the element bodies and their geoms, while the skin is purely a visualization object. Yet in most situations we prefer to look at the skin representation. To facilitate this, the @@ -1089,13 +1088,12 @@ generator places all geoms, sites and tendons in group 3 whose visualization is a 2D grid for example, you will see a continuous flexible surface and not a collection of spheres connected with tendons. However when fine-tuning the model and trying to understand the physics behind it, it is useful to be able to render the spheres and tendons. To switch the rendering style, disable the rendering of skins and enable group 3 for -geoms and tendons (note that starting with MuJoCo 2.0 we have added a group property to sites, tendons and joints in -addition to geoms). +geoms and tendons. We have designed the composite object generator to have intuitive high-level controls as much as possible, but at the same time it exposes a large number of options that interact with each other and can profoundly affect the resulting physics. So at some point users should read the :ref:`reference documentation ` carefully. -As a quick start though, MuJoCo 2.0 comes with an example of each composite object type. Below we go over these +As a quick start though, MuJoCo comes with an example of each composite object type. Below we go over these examples and explain the less obvious aspects. In all examples we have a static scene which is included in the model, followed by a single composite object. The static scene has a mocap body (large capsule) that can be moved around with the mouse to probe the behavior of the system. The XML snippets below are just the definition of the composite object; @@ -1490,7 +1488,7 @@ mocap bodies around: The key thing to understand about mocap bodies is that the simulator treats them as being fixed. We are causing them to move from one simulation time step to the next by updating their position and orientation directly, but as far as the physics model is concerned their position and orientation are constant. So what happens if we make contact with a -regular dynamic body, as in the composite object examples provided with the MuJoCo 2.0 distribution (recall that in +regular dynamic body, as in the composite object examples provided with the MuJoCo distribution (recall that in those example we have a capsule probe which is a mocap body that we move with the mouse). A contact between two regular bodies will experience penetration as well as relative velocity, while contact with a mocap body is missing the relative velocity component because the simulator does not know that the mocap body itself is moving. So the @@ -1642,7 +1640,7 @@ the same yet the damping component of the force is integrated implicitly. Restitution ~~~~~~~~~~~ -MuJoCo 2.0 introduced a new mechanism for specifying :at:`solref` as explained in :ref:`Solver parameters `. +Another mechanism exists for specifying :at:`solref`, as explained in :ref:`Solver parameters `. When both numbers are non-positive, they are interpreted as (-stiffness, -damping) and scaled by the constraint impedance. To achieve perfect restitution for contacts and other constraints, set stiffness to some reasonably large value and damping to zero. Below is an example of a sphere bouncing on a plane with restitution coefficient of 1, so diff --git a/doc/programming/index.rst b/doc/programming/index.rst index 381d8754..11273f46 100644 --- a/doc/programming/index.rst +++ b/doc/programming/index.rst @@ -35,7 +35,7 @@ Thread to process Tasks asynchronously. To enable use in MuJoCo, create a ThreadPool and assign it to the thread_pool field in mjData. UI framework - The UI framework (new in MuJoCo 2.0) is written in C. UI elements are rendered in OpenGL. It has its own event + The UI framework is written in C. UI elements are rendered in OpenGL. It has its own event mechanism and abstract hooks for keyboard and mouse input. The code samples use it with GLFW, but it can also be used with other window libraries. diff --git a/doc/programming/samples.rst b/doc/programming/samples.rst index fb24c61b..75763808 100644 --- a/doc/programming/samples.rst +++ b/doc/programming/samples.rst @@ -108,7 +108,7 @@ illustration of the concepts in that guide. This code sample is a fully-featured interactive simulator. It opens an OpenGL window using the platform-independent GLFW library, and renders the simulation state in it. There is built-in help, simulation statistics, profiler, sensor data plots. The model file can be specified as a command-line argument, or loaded at runtime using drag-and-drop -functionality. As of MuJoCo 2.0, this code sample uses the native UI to render various controls, and provides an +functionality. This code sample uses the native UI to render various controls, and provides an illustration of how the new UI framework is intended to be used. Below is a screen-capture of ``simulate`` in action: .. youtube:: 0ORsj_E17B0