Fix typos. fixes #2139
PiperOrigin-RevId: 691429879 Change-Id: I929b7a387ec41f68b8d85fe20de83083216da36a
This commit is contained in:
committed by
Copybara-Service
parent
7c2b2d353c
commit
32df8a515a
@@ -312,7 +312,7 @@ gradient descent iterations is set using :ref:`sdf_iterations<option-sdf_iterati
|
||||
|
||||
While *exact* SDFs---encoding the precise signed distance to the surface---are preferred, collisions are possible with
|
||||
any function whose value vanishes at the surface and grows monotonically away from it, with a negative sign in the
|
||||
interior. For such functions, it is still possible to find collisons, albeit with a possibly
|
||||
interior. For such functions, it is still possible to find collisions, albeit with a possibly
|
||||
increased number of starting points.
|
||||
|
||||
The ``sdf_distance`` method is called by the compiler to produce a visual mesh for rendering using the marching cubes
|
||||
@@ -331,7 +331,7 @@ For the sdf plugin, the following methods need to be specified
|
||||
required because mesh creation occurs during model compilation before the plugin object has been instantiated.
|
||||
|
||||
``sdf_gradient``:
|
||||
Computes the gradient in local coodinates of the SDF at the query point.
|
||||
Computes the gradient in local coordinates of the SDF at the query point.
|
||||
|
||||
``sdf_aabb``:
|
||||
Computes the axis-aligned bounding box in local coordinates. This volume is voxelized uniformly before the call to
|
||||
@@ -392,7 +392,7 @@ Resource providers work via callbacks:
|
||||
resource name. For example, the resource name ``http://www.example.com/myasset.obj`` would have
|
||||
``http://www.example.com/`` as its directory.
|
||||
- :ref:`mjfResourceModified<mjfResourceModified>`: This callback is optional and is used to check if an existing
|
||||
opened resource has been modifed from its orginal source.
|
||||
opened resource has been modified from its original source.
|
||||
|
||||
.. _exProviderUsage:
|
||||
|
||||
|
||||
@@ -143,7 +143,7 @@ links below, to make this documentation self-contained.
|
||||
|
||||
`mujoco.h <https://github.com/google-deepmind/mujoco/blob/main/include/mujoco/mujoco.h>`__
|
||||
This is the main header file and must be included in all programs using MuJoCo. It defines all API functions and
|
||||
global variables, and includes the all other header files except mjxmacro.h.
|
||||
global variables, and includes all other header files except mjxmacro.h.
|
||||
`mjmodel.h <https://github.com/google-deepmind/mujoco/blob/main/include/mujoco/mjmodel.h>`__
|
||||
Defines the C structure :ref:`mjModel` which is the runtime representation of the
|
||||
model being simulated. It also defines a number of primitive types and other structures needed to define mjModel.
|
||||
|
||||
@@ -18,7 +18,7 @@ Overview
|
||||
~~~~~~~~
|
||||
|
||||
The new API augments the traditional workflow of creating and editing models using XML files, breaking up the *parse* and
|
||||
*compile* steps. As summarized in the the :ref:`Overview chapter<Instance>`, the traditional workflow is:
|
||||
*compile* steps. As summarized in the :ref:`Overview chapter<Instance>`, the traditional workflow is:
|
||||
|
||||
1. Create an XML model description file (MJCF or URDF) and associated assets. |br|
|
||||
2. Call :ref:`mj_loadXML`, obtain an :ref:`mjModel` instance.
|
||||
@@ -29,7 +29,7 @@ The new workflow is:
|
||||
:ref:`mjSpec`.
|
||||
2. Edit the mutable :ref:`mjSpec` datastructure adding, changing and removing elements.
|
||||
3. Compile the :ref:`mjSpec` at any point, obtaining an updated :ref:`mjModel` instance. After compilation, the
|
||||
:ref:`mjSpec` remains editable, so steps 2 and 3 are interchangable.
|
||||
:ref:`mjSpec` remains editable, so steps 2 and 3 are interchangeable.
|
||||
|
||||
|
||||
.. _meUsage:
|
||||
|
||||
@@ -61,8 +61,8 @@ Where the command line arguments are
|
||||
- The ``ctrlnoise`` argument prevents models from settling into a static state where, due to warmstarts, one can
|
||||
measure artificially faster simulation.
|
||||
- When ``npoolthread > 1`` is specified, an engine-internal :ref:`mjThreadPool` is created with the specified number of
|
||||
threads, to speed up simulation of large scenes. Note that while it is possible to to use both ``nthread`` and
|
||||
``npoolthread``, the scenarios for which one would want these different type of multithreading are usually mutually
|
||||
threads, to speed up simulation of large scenes. Note that while it is possible to use both ``nthread`` and
|
||||
``npoolthread``, the scenarios for which one would want these different types of multithreading are usually mutually
|
||||
exclusive.
|
||||
- For more repeatable performance statistics, run the tool with the ``performance``
|
||||
`governor <https://www.kernel.org/doc/Documentation/cpu-freq/governors.txt>`__ on Linux, or the
|
||||
@@ -203,7 +203,7 @@ data file into a playable movie file:
|
||||
ffmpeg -f rawvideo -pixel_format rgb24 -video_size 2560x1440
|
||||
-framerate 60 -i rgb.out -vf "vflip,format=yuv420p" video.mp4
|
||||
|
||||
Note that the offscreen rendering resolution of the model and ffmpeg's video_size must be the identical.
|
||||
Note that the offscreen rendering resolution of the model and ffmpeg's video_size must be identical.
|
||||
|
||||
This sample can be compiled in three ways which differ in how the OpenGL context is created: using GLFW with an
|
||||
invisible window, using OSMesa, or using EGL. The latter two options are only available on Linux and are envoked by
|
||||
|
||||
@@ -151,7 +151,7 @@ The low-level mjvGLCamera is what determines the actual rendering. There are two
|
||||
for each eye. Each has position, forward and up directions. Forward corresponds to the negative Z axis of the camera
|
||||
frame, while up corresponds to the positive Y axis. There is also a frustum in the sense of OpenGL, except we store the
|
||||
average of the left and right frustum edges and then during rendering compute the actual edges from the viewport aspect
|
||||
ratio assuming 1:1 pixel aspect ratio. The distance between the two camera positions corresponds to the inter-pupilary
|
||||
ratio assuming 1:1 pixel aspect ratio. The distance between the two camera positions corresponds to the inter-pupillary
|
||||
distance (ipd). When the low-level camera parameters are computed automatically from an abstract camera, the ipd as well
|
||||
as vertical field of view (fovy) are taken from ``mjModel.vis.global.ipd``/``fovy`` for free and tracking cameras, and
|
||||
from the camera-specific ``mjModel.cam_ipd/fovy`` for cameras defined in the model. When stereoscopic mode is not
|
||||
|
||||
Reference in New Issue
Block a user