chenlin/Mujoco_WASM
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Delete mentions of MuJoCo 2.0 in the docs.

Browse Source 
PiperOrigin-RevId: 578501679
Change-Id: Ie1fdd1d11d2e1e12b3f9f1e59bd4da705b3a7c7e
This commit is contained in:
Yuval Tassa
2023-11-01 06:43:32 -07:00
committed by Copybara-Service
parent 893c404230
commit e82cb9f420
4 changed files with 21 additions and 23 deletions
Download Patch File Download Diff File Expand all files Collapse all files
doc/XMLreference.rst
+9 -9
View File
@@ -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.