Delete mentions of MuJoCo 2.0 in the docs.
PiperOrigin-RevId: 578501679 Change-Id: Ie1fdd1d11d2e1e12b3f9f1e59bd4da705b3a7c7e
This commit is contained in:
Yuval Tassa
committed by
Copybara-Service
Copybara-Service
parent
893c404230
commit
e82cb9f420
@@ -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 <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<asset-mesh-refpos>` and :ref:`refquat<asset-mesh-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
|
||||
|
||||
<asset>
|
||||
<mesh name="pyramid" vertex="0 0 0 1 0 0 0 1 0 0 0 1"/>
|
||||
<mesh name="tetrahedron" vertex="0 0 0 1 0 0 0 1 0 0 0 1"/>
|
||||
</asset>
|
||||
|
||||
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.
|
||||
|
||||
|
||||
+10
-12
@@ -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 <body-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 <asset-skin>` which are also new in MuJoCo 2.0. The skin is generated
|
||||
can be rendered as :ref:`skins <asset-skin>`. 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 <body-composite>` 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 <CSolver>`.
|
||||
Another mechanism exists for specifying :at:`solref`, as explained in :ref:`Solver parameters <CSolver>`.
|
||||
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
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user