Fix typos and minor corrections in MuJoCo documentation and comments.
PiperOrigin-RevId: 875163889 Change-Id: Ic604d6235bf9cb999058f191e3ee41e47ec1a567
This commit is contained in:
Yuval Tassa
committed by
Copybara-Service
Copybara-Service
parent
940cab2508
commit
0c66585e39
@@ -18,7 +18,7 @@ MuJoCo defines a large number of types:
|
||||
Note that the API does not use these enum types directly. Instead it uses ints, and the documentation/comments state
|
||||
that certain ints correspond to certain enum types. This is because we want the API to be compiler-independent, and
|
||||
the C standard does not dictate how many bytes must be used to represent an enum type. Nevertheless, for improved
|
||||
readiblity, we recommend using these types when calling API functions which take them as arguments.
|
||||
readability, we recommend using these types when calling API functions which take them as arguments.
|
||||
|
||||
- :ref:`C struct types<tyStructure>`. These can be classified as:
|
||||
|
||||
@@ -806,7 +806,7 @@ Struct types
|
||||
------------
|
||||
|
||||
The three central struct types for physics simulation are :ref:`mjModel`, :ref:`mjOption` (embedded in :ref:`mjModel`)
|
||||
and :ref:`mjData`. An introductory discussion of these strucures can be found in the :ref:`Overview<ModelAndData>`.
|
||||
and :ref:`mjData`. An introductory discussion of these structures can be found in the :ref:`Overview<ModelAndData>`.
|
||||
|
||||
|
||||
.. _mjModel:
|
||||
@@ -1708,7 +1708,7 @@ mjfOpenResource
|
||||
|
||||
typedef int (*mjfOpenResource)(mjResource* resource);
|
||||
|
||||
This callback is for opeing a resource; returns zero on failure.
|
||||
This callback is for opening a resource; returns zero on failure.
|
||||
|
||||
.. _mjfReadResource:
|
||||
|
||||
|
||||
@@ -1005,7 +1005,7 @@ compilation.
|
||||
This attribute specifies the maximum number of contacts that will be generated at runtime. If the number of active
|
||||
contacts is about to exceed this value, the extra contacts are discarded and a warning is generated. This is a
|
||||
deprecated legacy attribute which prior to version 2.3.0 affected memory allocation. It is kept for backwards
|
||||
compatibillity and debugging purposes.
|
||||
compatibility and debugging purposes.
|
||||
|
||||
.. _size-nstack:
|
||||
|
||||
@@ -1992,7 +1992,7 @@ attribute and :el:`layer` child elements is an error.
|
||||
- opacity (alpha channel)
|
||||
* - :at:`emissive`
|
||||
- 4
|
||||
- RGB light emmision intensity, exposure weight in 4th channel
|
||||
- RGB light emission intensity, exposure weight in 4th channel
|
||||
* - :at:`orm`
|
||||
- 3
|
||||
- packed 3 channel [occlusion, roughness, metallic]
|
||||
@@ -3676,7 +3676,7 @@ saving the XML:
|
||||
|
||||
**direct** allows the user to specify the point and element data of the flexcomp directly in the XML. Note that
|
||||
flexcomp will still generate moving bodies automatically, as well as automate other settings; so it still provides
|
||||
convenience compared to specifing the corresponding flex directly.
|
||||
convenience compared to specifying the corresponding flex directly.
|
||||
|
||||
.. _body-flexcomp-count:
|
||||
|
||||
@@ -3869,7 +3869,7 @@ multiple times is allowed.
|
||||
.. _flexcomp-pin-id:
|
||||
|
||||
:at:`id`: :at-val:`int(n), required`
|
||||
Zero-based ids of points to pin. When the points are automatically-generaged, the user needs to understand their
|
||||
Zero-based ids of points to pin. When the points are automatically-generated, the user needs to understand their
|
||||
layout in order to decide which points to pin. This can be done by first creating a flexcomp without any pins,
|
||||
loading it in the simulator, and showing the body labels.
|
||||
|
||||
@@ -4455,7 +4455,7 @@ be clear from the above specification.
|
||||
.. _deformable-skin-face:
|
||||
|
||||
:at:`face`: :at-val:`int(3*nface), optional`
|
||||
Trinagular skin faces. Each face is a triple of vertex indices, which are integers between zero and nvert-1.
|
||||
Triangular skin faces. Each face is a triple of vertex indices, which are integers between zero and nvert-1.
|
||||
|
||||
.. _deformable-skin-inflate:
|
||||
|
||||
@@ -6608,7 +6608,7 @@ points (spheres) and the surface normals (arrows).
|
||||
regardless of the ray origin. If this data type is included along with either :at-val:`dist` or :at-val:`point`,
|
||||
normals will be visualized as arrows at the intersection points.
|
||||
- :at-val:`depth`: **real(1)**: The distance of the hit point from the camera plane, -1 if no surface was hit. Note
|
||||
that this depth sematic corresponds to depth images in the computer graphics sense.
|
||||
that this depth semantic corresponds to depth images in the computer graphics sense.
|
||||
|
||||
.. _sensor-rangefinder-name:
|
||||
|
||||
@@ -7864,7 +7864,7 @@ See :ref:`collision-sensors` for more details about sensors of this type.
|
||||
.. _sensor-distance-cutoff:
|
||||
|
||||
:at:`cutoff`
|
||||
See :ref:`collision-sensors` for the sematics of this attribute, which is different than for other sensor categories.
|
||||
See :ref:`collision-sensors` for the semantics of this attribute, which is different than for other sensor categories.
|
||||
If no collision is detected, the distance sensor returns the :at:`cutoff` value, so in this case
|
||||
:at:`cutoff` acts as a maximum clipping value, in addition to the special semantics.
|
||||
|
||||
@@ -7919,7 +7919,7 @@ See :ref:`collision-sensors` for more details about sensors of this type.
|
||||
.. _sensor-normal-cutoff:
|
||||
|
||||
:at:`cutoff`
|
||||
See :ref:`collision-sensors` for the sematics of this attribute, which is different than for other sensor categories.
|
||||
See :ref:`collision-sensors` for the semantics of this attribute, which is different than for other sensor categories.
|
||||
If no collision is detected, the :ref:`normal<sensor-normal>` sensor returns (0, 0, 0), otherwise it returns a
|
||||
normalized direction vector. For this sensor, :at:`cutoff` does not lead to any clamping.
|
||||
|
||||
@@ -7975,7 +7975,7 @@ See :ref:`collision-sensors` for more details about sensors of this type.
|
||||
.. _sensor-fromto-cutoff:
|
||||
|
||||
:at:`cutoff`
|
||||
See :ref:`collision-sensors` for the sematics of this attribute, which is different than for other sensor categories.
|
||||
See :ref:`collision-sensors` for the semantics of this attribute, which is different than for other sensor categories.
|
||||
If no collision is detected, the :ref:`fromto<sensor-fromto>` sensor returns 6 zeros.
|
||||
For this sensor, :at:`cutoff` does not lead to any clamping.
|
||||
|
||||
|
||||
+2
-2
@@ -1095,7 +1095,7 @@ General
|
||||
forces on the joint are treated as applied by actuators. See attribute documentation for more details. The example
|
||||
model
|
||||
`refsite.xml <https://github.com/google-deepmind/mujoco/blob/main/test/engine/testdata/actuation/refsite.xml>`__,
|
||||
which demostrates Cartesian actuation of an arm, has been updated to use this attribute.
|
||||
which demonstrates Cartesian actuation of an arm, has been updated to use this attribute.
|
||||
3. Added support for gmsh format 2.2 , tetrahedral mesh, as generated by e.g. `fTetwild <https://github.com/wildmeshing/fTetWild>`__.
|
||||
|
||||
4. Added :ref:`mju_euler2Quat` for converting an Euler-angle sequence to quaternion.
|
||||
@@ -2620,7 +2620,7 @@ UI
|
||||
11. Figure selection type changed from ``int`` to ``float``.
|
||||
#. Figures now show data coordinates, when selection and highlight are enabled.
|
||||
#. Changed ``mjMAXUIMULTI`` to 35, ``mjMAXUITEXT`` to 300, ``mjMAXUIRECT`` to 25.
|
||||
#. Added collapsable sub-sections, implemented as separators with state: ``mjSEPCLOSED`` collapsed, ``mjSEPCLOSED+1``
|
||||
#. Added collapsible sub-sections, implemented as separators with state: ``mjSEPCLOSED`` collapsed, ``mjSEPCLOSED+1``
|
||||
expanded.
|
||||
#. Added ``mjITEM_RADIOLINE`` item type.
|
||||
#. Added function ``mjui_addToSection`` to simplify UI section construction.
|
||||
|
||||
@@ -72,7 +72,7 @@ body coordinates are
|
||||
g_{V, i} = \quad &- 8 \beta \pi r_{eq}^3 \omega_i \\
|
||||
\end{aligned}
|
||||
|
||||
One can also affect these forces by specifing a non-zero :ref:`wind<option-wind>`, which is a 3D vector subtracted
|
||||
One can also affect these forces by specifying a non-zero :ref:`wind<option-wind>`, which is a 3D vector subtracted
|
||||
from the body linear velocity in the fluid dynamics computation.
|
||||
|
||||
.. _flEllipsoid:
|
||||
@@ -357,7 +357,7 @@ of symmetry because under this assumption the kinetic energy greatly simplifies
|
||||
|
||||
.. math::
|
||||
2 \mathcal{T} = m_{A, x} v_x^2 + m_{A, y} v_y^2 + m_{A, z} v_z^2 +
|
||||
I_{A, x} \omega_x^2 + I_ {A, y} \omega_y^2 + I_{A, y} \omega_z^2
|
||||
I_{A, x} \omega_x^2 + I_ {A, y} \omega_y^2 + I_{A, z} \omega_z^2
|
||||
|
||||
|
||||
For convenience we introduce the added-mass vector :math:`\mathbf{m}_A = \{m_{A, x}, m_{A, y}, m_{A, z}\}` and added-moment of
|
||||
@@ -429,7 +429,7 @@ bagheri2016`. See screen capture of the
|
||||
We derive a formula for :math:`\mathbf{f}_\text{D}` based on two surfaces :math:`A^\text{proj}_\mathbf{v}` and
|
||||
:math:`A_\text{max}`. The first, :math:`A^\text{proj}_\mathbf{v}`, is the cylindrical projection of the body onto a
|
||||
plane normal to the velocity :math:`\mathbf{v}`. The second is the maximum projected surface
|
||||
:math:`A_\text{max} = 4 \pi r_{max} r_{min}`.
|
||||
:math:`A_\text{max} = \pi r_{max} r_{mid}`.
|
||||
|
||||
.. math::
|
||||
\mathbf{f}_\text{D} = - \rho~ \big[ C_{D, \text{blunt}} ~ A^\text{proj}_\mathbf{v} ~ +
|
||||
@@ -541,7 +541,7 @@ onto the surface. The lift force per unit length can be computed with the Kutta
|
||||
:math:`\mathbf{f}_K / L = \rho \Gamma_\text{K} \times \mathbf{v}`.
|
||||
|
||||
In order to extend the lift force equation to three-dimensional motions, we consider the normal
|
||||
:math:`\mathbf{n}_{s, \mathbf{v}} = \{\frac{r_y r_z}{r_x}v_x, \frac{r_z r_x}{r_y}v_y, \frac{r_x r_x}{r_z}v_z\}`
|
||||
:math:`\mathbf{n}_{s, \mathbf{v}} = \{\frac{r_y r_z}{r_x}v_x, \frac{r_z r_x}{r_y}v_y, \frac{r_x r_y}{r_z}v_z\}`
|
||||
to the cross-section of the body which generates the body's projection :math:`A^\text{proj}_\mathbf{v}` onto a plane
|
||||
normal to the velocity given in the :ref:`lemma<flProjection>` above and the corresponding unit vector
|
||||
:math:`\hat{\mathbf{n}}_{s, \mathbf{v}}`.
|
||||
|
||||
@@ -531,7 +531,7 @@ All three single-step integrators in MuJoCo use the update :eq:`eq_implicit_upda
|
||||
Semi-implicit with implicit joint damping (``Euler``)
|
||||
For this method, :math:`D` only includes derivatives of joint damping. Note that in this case :math:`D` is diagonal
|
||||
and :math:`\widehat{M}` is symmetric, so :math:`L^TL` decomposition (a variant of Cholesky) can be used. This
|
||||
factorization is stored ``mjData.qLD``. If the model has no joint damping or the
|
||||
factorization is stored in ``mjData.qH``. If the model has no joint damping or the
|
||||
:ref:`eulerdamp<option-flag-eulerdamp>` disable-flag is set, implicit damping is disabled and the semi-implicit
|
||||
update :eq:`eq_semimplicit` is used, rather than :eq:`eq_implicit_update`, avoiding the additional factorization of
|
||||
:math:`\widehat{M}` (*additional* because :math:`M` is already factorized for the acceleration update
|
||||
@@ -579,11 +579,11 @@ Fast implicit-in-velocity (``implicitfast``)
|
||||
step is "just right", but that range is model-dependent.
|
||||
|
||||
:ref:`integrator<option-integrator>`
|
||||
Summary: The recommended integrator is ``implicitfast`` which usually has the best tradeoff of stabillity and
|
||||
Summary: The recommended integrator is ``implicitfast`` which usually has the best tradeoff of stability and
|
||||
performance.
|
||||
|
||||
**Euler**:
|
||||
Use ``Euler`` for compatibillity with older models.
|
||||
Use ``Euler`` for compatibility with older models.
|
||||
**implicitfast**:
|
||||
The ``implicitfast`` integrator has similar computational cost to ``Euler``, yet provides
|
||||
increased stability, and is therefore a strict improvement. It is the recommended integrator for most models.
|
||||
@@ -839,14 +839,14 @@ as defined later. The ``condim`` parameter determines the contact type, and has
|
||||
|
||||
``condim = 3`` : 3 for elliptic, 4 for pyramidal
|
||||
This is a regular frictional contact, which can generate normal force as well as a tangential friction force opposing
|
||||
slip. An interpertation of this number is the slope of a surface above which a flat object will begin to slip
|
||||
slip. An interpretation of this number is the slope of a surface above which a flat object will begin to slip
|
||||
under gravity.
|
||||
|
||||
``condim = 4`` : 4 for elliptic, 6 for pyramidal
|
||||
In addition to normal and tangential force, this contact can generate torsional friction torque opposing rotation
|
||||
around the contact normal, corresponding to a torque generated by a contacting surface patch. This is useful for
|
||||
modeling soft fingers, and can substantially improve the stability of simulated grasping. Torsional friction
|
||||
coefficients have **units of length** which can be interperted as the diameter of the surface contact patch.
|
||||
coefficients have **units of length** which can be interpreted as the diameter of the surface contact patch.
|
||||
|
||||
``condim = 6`` : 6 for elliptic, 10 for pyramidal
|
||||
This contact can oppose motion in all relative degrees of freedom between the two geoms. In particular it adds
|
||||
|
||||
@@ -571,7 +571,7 @@ typedef enum mjtTextureRole_ { // role of texture map in rendering
|
||||
mjTEXROLE_ROUGHNESS, // roughness
|
||||
mjTEXROLE_METALLIC, // metallic
|
||||
mjTEXROLE_NORMAL, // normal (bump) map
|
||||
mjTEXROLE_OPACITY, // transperancy
|
||||
mjTEXROLE_OPACITY, // opacity
|
||||
mjTEXROLE_EMISSIVE, // light emission
|
||||
mjTEXROLE_RGBA, // base color, opacity
|
||||
mjTEXROLE_ORM, // occlusion, roughness, metallic
|
||||
|
||||
+8
-8
@@ -495,7 +495,7 @@ are as follows:
|
||||
in mjData.contact actually has all 5 of them, even if condim is less than 6 and not all coefficients are used. In
|
||||
contrast, geoms have only 3 friction coefficients: tangential (same for both axes), torsional, rolling (same for both
|
||||
axes). Each of these 3D vectors of friction coefficients is expanded into a 5D vector of friction coefficients by
|
||||
replicating the tangetial and rolling components. See the :ref:`Contact<coContact>` section in the Computation
|
||||
replicating the tangential and rolling components. See the :ref:`Contact<coContact>` section in the Computation
|
||||
chapter for an intuitive description of the semantics of tangential, torsional and rolling coefficients.
|
||||
|
||||
The contact friction coefficients are then computed according to the following rule: if one of the two geoms has
|
||||
@@ -1113,7 +1113,7 @@ Here we describe the XML attributes common to all sensor types, so as to avoid r
|
||||
:at:`noise`: :at-val:`real, "0"`
|
||||
The standard deviation of the noise model of this sensor. In versions prior to 3.1.4, this would lead to noise being
|
||||
added to the sensors. In release 3.1.4 this feature was removed, see :doc:`3.1.4 changelog <changelog>` for a
|
||||
detailed justification. As of subsequent versions, this attrbute serves as a convenient location for saving standard
|
||||
detailed justification. As of subsequent versions, this attribute serves as a convenient location for saving standard
|
||||
deviation information for later use.
|
||||
|
||||
.. _sensor-cutoff:
|
||||
@@ -1454,7 +1454,7 @@ that applies to all edges of a given flex, which permits large time steps, or a
|
||||
where each element is in a constant stress state, which is equivalent to piecewise linear finite elements and achieves
|
||||
improved realism and accuracy. The edge-based model could be seen as a "lumped" stiffness model, where the correct
|
||||
coupling of deformation modes (e.g. shear and volumetric) is averaged in a single quantity. The continuum model enables
|
||||
instead to specify shear and volumetic stiffnesses separately using the `Poisson's ratio
|
||||
instead to specify shear and volumetric stiffnesses separately using the `Poisson's ratio
|
||||
<https://en.wikipedia.org/wiki/Poisson%27s_ratio>`__ of the material. For more details, see the `Saint Venant-Kirchhoff
|
||||
<https://en.wikipedia.org/wiki/Hyperelastic_material#Saint_Venant%E2%80%93Kirchhoff_model>`__ hyperelastic model.
|
||||
|
||||
@@ -1631,7 +1631,7 @@ perfectly (and much better than a spring-damper would) because the constraints a
|
||||
large forces without destabilizing the simulation. But if the hand is forced to make contact with the table for example
|
||||
(right plot) it cannot simultaneously respect the contact constraint and track the mocap body. This is because the
|
||||
mocap body is free to go through the table. So which constraint wins? That depends on the softness of the weld
|
||||
constraint realtive to the contact constraint. The corresponding :at:`solref` and :at:`solimp` parameters need to be
|
||||
constraint relative to the contact constraint. The corresponding :at:`solref` and :at:`solimp` parameters need to be
|
||||
adjusted so as to achieve the desired trade-off. See the Modular Prosthetic Limb (MPL) hand model available on the
|
||||
MuJoCo Forum for an example; the plots below are generated with that model.
|
||||
|
||||
@@ -1735,7 +1735,7 @@ dedicated section :ref:`therein<MjxPerformance>`.
|
||||
|
||||
- Reduce the number of checked collisions using the
|
||||
:ref:`contype<body-geom-contype>` / :ref:`conaffinity<body-geom-conaffinity>` mechanism described in the
|
||||
:ref:`Collison detection<Collision>` section.
|
||||
:ref:`Collision detection<Collision>` section.
|
||||
- Modify collision geometries, replacing expensive collision tests (e.g. mesh-mesh) with cheaper primitive-primitive
|
||||
collisions. As a rule of thumb, collisions which have custom pair functions in the collision table at the top of
|
||||
`engine_collision_driver.c <https://github.com/google-deepmind/mujoco/blob/main/src/engine/engine_collision_driver.c>`__
|
||||
@@ -1766,7 +1766,7 @@ better visualize and understand the contact configuration and resulting forces.
|
||||
**Slip-preventing contact forces are outside the friction cone**
|
||||
This implies that the physics cannot prevent slip, even in principle. This occurs when:
|
||||
|
||||
a. *The normal force is too small.* Ensure that the maximum force that can be applied by the gripper mutiplied by
|
||||
a. *The normal force is too small.* Ensure that the maximum force that can be applied by the gripper multiplied by
|
||||
the sliding friction coefficient is significantly greater than the weight of the object.
|
||||
b. *The sliding friction coefficient is too low.* Increase the sliding :ref:`friction<body-geom-friction>`
|
||||
coefficient.
|
||||
@@ -1774,7 +1774,7 @@ better visualize and understand the contact configuration and resulting forces.
|
||||
4 or 6 and choose appropriate friction coefficients.
|
||||
**condim 4** enables torsional friction, preventing rotation around the normal.
|
||||
**condim 6** also enables rolling friction, preventing rotation around the tangential directions.
|
||||
See the :ref:`Contact<coContact>` section for details and the specifc semantics of these coefficients.
|
||||
See the :ref:`Contact<coContact>` section for details and the specific semantics of these coefficients.
|
||||
|
||||
**The geometry does not support the required forces or torques**
|
||||
This is a common real-world problem, solved by improved design of grippers and handles.
|
||||
@@ -1790,7 +1790,7 @@ better visualize and understand the contact configuration and resulting forces.
|
||||
High-frequency, low-amplitude vibrations are also a real-world problem in many industrial settings, but unlike in
|
||||
simulation, in the real world they are audible. Such vibration is often caused by controllers with very
|
||||
high gains and sometimes by stick-slip feedback from contacts or joints, resonating with the eigen-modes of the
|
||||
mechanism. The easist way to diagnose such vibration is to visualize contact forces in
|
||||
mechanism. The easiest way to diagnose such vibration is to visualize contact forces in
|
||||
:ref:`simulate<saSimulate>`. The solution is usually to reduce the :ref:`timestep<option-timestep>` and/or add
|
||||
some :ref:`armature<body-joint-armature>` to the relevant joints. Another reason for vibration is feedback from
|
||||
explicit damping. Use the implicit or implicitfast integrators, as documented in the
|
||||
|
||||
@@ -160,7 +160,7 @@ or :ref:`attach a frame or an mjSpec to a body<mjs_attach>`:
|
||||
|
||||
Note that in the above examples, the parent and child models have different values for ``compiler.degree``,
|
||||
corresponding to the :ref:`compiler/angle<compiler-angle>` attribute, specifying the units in which angles are
|
||||
interperted. Compiler flags are carried over during attachment, so the child model will be compiled using the child
|
||||
interpreted. Compiler flags are carried over during attachment, so the child model will be compiled using the child
|
||||
flags, while the parent will be compiled using the parent flags.
|
||||
|
||||
Note also that once a child is attached by reference to a parent, the child cannot be compiled on its own.
|
||||
|
||||
@@ -210,7 +210,7 @@ data file into a playable movie file:
|
||||
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
|
||||
invisible window, using OSMesa, or using EGL. The latter two options are only available on Linux and are invoked by
|
||||
defining the symbols MJ_OSMESA or MJ_EGL when compiling record.cc. The functions ``initOpenGL`` and ``closeOpenGL``
|
||||
create and close the OpenGL context in three different ways depending on which of the above symbols is defined.
|
||||
|
||||
|
||||
@@ -267,7 +267,7 @@ The *physics state* (:ref:`mjSTATE_PHYSICS<mjtState>`) contains the main quantit
|
||||
stepping. These are ``mjData.{qpos, qvel, act, history}``:
|
||||
|
||||
Position: ``qpos``
|
||||
The configuration in generalized coodinates, denoted in the :ref:`Numerical Integration<geIntegration>` section as
|
||||
The configuration in generalized coordinates, denoted in the :ref:`Numerical Integration<geIntegration>` section as
|
||||
:math:`q`.
|
||||
|
||||
Velocity: ``qvel``
|
||||
@@ -322,7 +322,7 @@ Control: ``ctrl``
|
||||
Controls are defined by the :ref:`actuator<actuator>` section of the XML. ``mjData.ctrl`` values either produce
|
||||
generalized forces directly (stateless actuators), or affect the actuator activations in ``mjData.act``, which then
|
||||
produce forces. Note that while all actuators produce forces, the semantics of ``ctrl`` and ``act`` depend on the
|
||||
specifc parameters of the :ref:`actuation model<geActuation>`.
|
||||
specific parameters of the :ref:`actuation model<geActuation>`.
|
||||
|
||||
Auxiliary Controls: ``qfrc_applied`` and ``xfrc_applied``
|
||||
| ``mjData.qfrc_applied`` are directly applied generalized forces.
|
||||
|
||||
@@ -435,7 +435,7 @@ window buffer size changes whenever the user resizes or maximizes the window. Th
|
||||
fixed viewport size. In the code sample :ref:`simulate.cc <saSimulate>` we use a callback which is triggered whenever
|
||||
the window size changes, while in :ref:`basic.cc <saBasic>` we simply check the window size every time we render. On
|
||||
certain scaled displays (only on OSX it seems) the window size and framebuffer size can be different. So if you are
|
||||
getting the size with GLFW functions, use glfwGetFramebuferSize rather than glfwGetWindowSize. On the other hand,
|
||||
getting the size with GLFW functions, use glfwGetFramebufferSize rather than glfwGetWindowSize. On the other hand,
|
||||
mouse coordinates are returned by the operating system in window rather than framebuffer units; thus the mouse
|
||||
interaction functions discussed earlier should use glfwGetWindowSize to obtain the window height needed to normalize
|
||||
the mouse displacement data.
|
||||
|
||||
+1
-1
@@ -922,7 +922,7 @@ custom cameras and lights. The constructor arguments of a ``USDExporter`` instan
|
||||
- ``model``: An MjModel instance. The USD exporter reads relevant information from the model including details about
|
||||
cameras, lights, textures, and object geometries.
|
||||
|
||||
- ``max_geom``: Maximum number of geoms in a scene, required when instatiating the internal .
|
||||
- ``max_geom``: Maximum number of geoms in a scene, required when instantiating the internal .
|
||||
`mjvScene <https://mujoco.readthedocs.io/en/stable/APIreference/APItypes.html#mjvscene>`__.
|
||||
|
||||
- ``output_directory``: Name of the directory under which the exported USD file and all relevant
|
||||
|
||||
@@ -161,7 +161,7 @@ typedef enum mjtTextureRole_ { // role of texture map in rendering
|
||||
mjTEXROLE_ROUGHNESS, // roughness
|
||||
mjTEXROLE_METALLIC, // metallic
|
||||
mjTEXROLE_NORMAL, // normal (bump) map
|
||||
mjTEXROLE_OPACITY, // transperancy
|
||||
mjTEXROLE_OPACITY, // opacity
|
||||
mjTEXROLE_EMISSIVE, // light emission
|
||||
mjTEXROLE_RGBA, // base color, opacity
|
||||
mjTEXROLE_ORM, // occlusion, roughness, metallic
|
||||
|
||||
@@ -1502,21 +1502,21 @@ void mj_makeImpedance(const mjModel* m, mjData* d) {
|
||||
KBIP[4*(i+j)] = 0;
|
||||
}
|
||||
|
||||
// standard: K = 1 / (dmax^2 * timeconst^2 * dampratio^2)
|
||||
// standard: K = 1 / (d_width^2 * timeconst^2 * dampratio^2)
|
||||
else if (ref[0] > 0)
|
||||
KBIP[4*(i+j)] = 1 / mju_max(mjMINVAL, solimp[1]*solimp[1] * ref[0]*ref[0] * ref[1]*ref[1]);
|
||||
|
||||
// direct: K = -solref[0] / dmax^2
|
||||
// direct: K = -solref[0] / d_width^2
|
||||
else {
|
||||
KBIP[4*(i+j)] = -ref[0] / mju_max(mjMINVAL, solimp[1]*solimp[1]);
|
||||
}
|
||||
|
||||
// standard: B = 2 / (dmax*timeconst)
|
||||
// standard: B = 2 / (d_width*timeconst)
|
||||
if (ref[1] > 0) {
|
||||
KBIP[4*(i+j)+1] = 2 / mju_max(mjMINVAL, solimp[1]*ref[0]);
|
||||
}
|
||||
|
||||
// direct: B = -solref[1] / dmax
|
||||
// direct: B = -solref[1] / d_width
|
||||
else {
|
||||
KBIP[4*(i+j)+1] = -ref[1] / mju_max(mjMINVAL, solimp[1]);
|
||||
}
|
||||
|
||||
Reference in New Issue
Block a user