typing ¶

Intrinsic Tait-Bryan xyz sequence.

Intrinsic Tait-Bryan xzy sequence.

Intrinsic Tait-Bryan yxz sequence.

Intrinsic Tait-Bryan yzx sequence.

Intrinsic Tait-Bryan zxy sequence.

Intrinsic Tait-Bryan zyx sequence.

Intrinsic proper Euler xyx sequence.

Intrinsic proper Euler xzx sequence.

Intrinsic proper Euler yxy sequence.

Intrinsic proper Euler yzy sequence.

Intrinsic proper Euler zxz sequence.

Intrinsic proper Euler zyz sequence.

Extrinsic Tait-Bryan XYZ sequence

Extrinsic Tait-Bryan XZY sequence

Extrinsic Tait-Bryan YXZ sequence

Extrinsic Tait-Bryan YZX sequence

Extrinsic Tait-Bryan ZXY sequence

Extrinsic Tait-Bryan ZYX sequence

Extrinsic proper Euler XYX

Extrinsic proper Euler XZX

Extrinsic proper Euler YXY

Extrinsic proper Euler YZY

Extrinsic proper Euler ZXZ

Extrinsic proper Euler ZYZ

3 channels. base color / albedo [red, green, blue].

3 channels. bump map (surface normals).

1 channel. ambient occlusion.

1 channel. roughness.

1 channel. metallicity.

1 channel. opacity (alpha channel).

4 channels. RGB light emmision intensity, exposure weight in 4th channel.

3 channels. packed 3 channel [occlusion, roughness, metallic].

4 channels. packed 4 channel [red, green, blue, alpha].

Native OpenGL window. Requires X11 forwarding over SSH, but is ideal for local development.

Browser-based viewer built on mjviser. Requires the mujoco-mojo[reloaded] extra.

Browser-based viewer built directly on viser. Requires the mujoco-mojo[reloaded] extra.

Search for design parameters that minimize the objective score.

Search for design parameters that maximize the objective score.

Tree-structured Parzen Estimator. Optuna's default, and generally the best choice for noisy physics simulations.

Covariance Matrix Adaptation Evolution Strategy - a robust evolutionary algorithm for continuous parameters.

Uniform random sampling. A useful baseline for comparison.

Genetic algorithm suited to multi-objective optimization.

Built for 3+ objectives, but also works as a robust single-objective genetic algorithm.

Quasi-Monte Carlo sampling. Low-discrepancy sequences for even coverage of the design space.

Gaussian Process. Best for very expensive simulations where only a few dozen trials are affordable.

Exhaustive grid search over the entire space. Does not support a random seed.

Alphabetical by name.

By last-modified time.

Ascending.

Descending.

Plane which is infinite for collision detection purposes.

Height field geom.

Sphere geom.

A capsule, which is a cylinder capped with two half-spheres.

Ellipoid geom.

Cylinder geom.

Box geom.

Mesh geom.

Signed distance field (SDF, also referred to as signed distance function).

Semi-implicit with implicit joint damping (Euler).

For this method, D only includes derivatives of joint damping. Note that in this case D is diagonal and Mhat is symmetric, so LT L decomposition (a variant of Cholesky) can be used. This factorization is stored mjData.qLD. If the model has no joint damping or the eulerdamp disable-flag is set, implicit damping is disabled and the semi-implicit update (3) is used, rather than (6), avoiding the additional factorization of Mhat (additional because M is already factorized for the acceleration update (5)).

4th-order Runge-Kutta (RK4).

One advantage of our continuous-time formulation is that we can use higher order integrators such as Runge-Kutta or multistep methods. The only such integrator currently implemented is the fixed-step 4th-order Runge-Kutta method, though users can easily implement other integrators by calling mj_forward and integrating accelerations themselves. We have observed that for energy-conserving systems (example), RK4 is qualitatively better than the single-step methods, both in terms of stability and accuracy, even when the timestep is decreased by a factor of 4 (so the computational effort is identical). In the presence of large velocity- dependent forces, if the chosen single-step method integrates those forces implicitly, single-step methods can be significantly more stable than RK4.

Implicit-in-velocity (implicit).

For this method, D includes derivatives of all forces except the constraint forces JTf(v). These are currently ignored since even though computing them is possible, it is complicated, and numerical tests show that including them does not confer much benefit. That said, analytical derivatives of constraint forces are planned for a future version. Additionally, we restrict D to have the same sparsity pattern as M, for computational efficiency. This restriction will exclude damping in tendons which connect bodies that are on different branches of the kinematic tree. Since D is not symmetric, we cannot use Cholesky factorization, but because D and M have the same sparsity pattern corresponding to the topology of the kinematic tree, reverse-order LU factorization of Mhat is guaranteed to have no fill-in. This factorization is stored mjData.qLU.

Fast implicit-in-velocity (implicitfast).

For this method, D includes derivatives of all forces used in the implicit method, with the exception of the centripetal and Coriolis forces c(v) computed by the RNE algorithm. Additionally, it is symmetrized D←(D+DT)/2. One reason for dropping the RNE derivatives is that they are the most expensive to compute. Second, these forces change rapidly only at high rotational velocities of complex pendula and spinning bodies, scenarios which are not common and already well-handled by the Runge-Kutta integrator (see below). Because the RNE derivatives are also the main source of asymmetry of D, by dropping them and symmetrizing, we can use the faster LTL rather than LU decomposition.

The integrators above preserve MuJoCo's continuous-time contract: forward dynamics compute the instantaneous acceleration, and integration is a separate stage which advances the state. This integrator gives up that separation, in the tradition of the velocity-stepping schemes: the constraint solve and the implicit update are one operation whose solution is the step itself, so integration is trivial and the additional factorization of Mhat performed by the integrators above (stored in mjData.qH or mjData.qLU) is not needed. The solver minimizes the same convex Gauss-principle objective, but in the effective metric Mhat = M + hD + h^2K * M, where D and K denote positive damping and stiffness matrices: the negated derivatives of the smooth forces, restricted to terms which keep Mhat positive definite. Constraint forces are therefore computed against the same effective inertia which performs the velocity update.

The constraint rows are treated implicitly in the same way: each row's solref spring-damper is evaluated at the end of the step and folded into the row's impedance and reference. Constraint rows are then stable for any solref at any timestep. A contact or limit row whose spring is stiffer than the timestep can resolve (timeconst * dampratio < h) would however rebound on impact, so under this integrator the refsafe flag replaces such rows by the resolved row: the stiffest zero-restitution spring for the timestep at the authored damping ratio. Rows with timeconst * dampratio >= h and equality rows are left as authored; with refsafe disabled, every row is honored and timeconst -> 0 approaches the rigid-constraint limit (the violation is removed in one step) rather than an instability. The row's effective impedance is capped at the maximum impedance mjMAXIMP, which keeps the constraint weights well-conditioned. The cost is extra damping of the constraint response, growing with h/timeconsth/timeconst; the specified damping ratio is recovered as h -> 0.

The h^2 * K term makes discrete the only integrator which is implicit in position: joint, tendon and flex stiffness and actuator position feedback are stable at timesteps far beyond the explicit stability limit h ~< 2 / omega_max, where omega_max is the highest natural frequency in the model. The terms entering D and K are: joint damping and stiffness, tendon damping and stiffness, actuator gains (clamped to the stabilizing sign), flex elasticity and damping, and the dissipative drag component of fluid forces. Terms which fit inside the sparsity pattern of M (the joint diagonals, the fluid drag blocks) join its tree-structured factorization with no fill-in and add no cost to the solve; the couplings introduced by tendon, actuator and flex terms are applied matrix-free inside the iterative solvers. This split determines solver support: CG is matrix-free and requires only products with Mhat, and Newton merges the metric directly into its Hessian, while the dual PGS and noslip solvers require an explicit factorization.

Under PGS, tendon and actuator terms are therefore excluded from the metric and their forces integrate explicitly, like the sparsity-pattern restriction of implicit above. Noslip post-processing under a primal solver splits the metric: the main solve runs in the full Mhat, while the post-pass consumes the factored part alone as an approximation. Flex terms, which are too stiff to integrate explicitly, raise an error. The Coriolis and centripetal derivatives are excluded — they cannot enter a positive-definite metric — so gyroscopically-dominated mechanisms are better served by implicit; standalone free bodies receive the same local gyroscopic treatment as implicitfast.

Under this integrator forward dynamics computes the discrete step map: mjData.qacc holds the velocity difference (v+ - v) / h rather than the continuous-time acceleration, so the same state yields a different qacc under a different timestep; as h -> 0 it converges to the continuous acceleration. Acceleration-stage sensors (accelerometer, force/torque) report this finite-difference acceleration, which is what a physical sensor averaging over one timestep measures. Inverse dynamics inverts the same relation, so the fwdinv consistency check remains meaningful and invdiscrete is implied. Because qacc is the step, derivatives of forward dynamics are derivatives of the discrete transition, with no discretization gap for gradient-based methods.

Sometimes make the solver faster and more robust.

Better model of the physical reality.

Dense jacobian.

Sparse jacobian.

Resolves to dense when the number of degrees of freedom is up to 60, and sparse over 60.

Projected Gauss-Seidel method.

This is the most common algorithm used in physics simulators, and used to be the default in MuJoCo, until we developed the Newton method which appears to be better in every way. PGS uses the dual formulation. Unlike gradient-based methods which improve the solution along oblique directions, Gauss-Seidel works on one scalar component at a time, and sets it to its optimal value given the current values of all other components. One sweep of PGS has the computational complexity of one matrix-vector multiplication (although the constants are larger). It has first-order convergence but nevertheless makes rapid progress in a few iterations.

Conjugate gradient method.

This algorithm uses the non-linear conjugate gradient method with the Polak-Ribiere-Plus formula. Line-search is exact, using Newton's method in one dimension, with analytical second derivatives.

Newton's method.

This algorithm implements the exact Newton method, with analytical second-order derivatives and Cholesky factorization of the Hessian. The line-search is the same as in the CG method. It is the default solver.

Enable the feature.

Disable the feature.

No automatic inference is performed. In that case each body must have explicitly defined mass and inertia with the inertial element, or else a compile error will be generated.

The mass and inertia of each body will be inferred from the geoms attached to it, overriding any values specified with the inertial element.

Masses and inertias are inferred automatically only when the inertial element is missing in the body definition.

Disables this functionality.

Applies to actuators whose gaintype or biastype is set to muscle

Applies to actuators whose gaintype or biastype is set to either muscle or user.

Applies to all actuators.

No internal state

act_dot = ctrl

act_dot = (ctrl - act) / dynprm[0]

Like filter but with exact integration

act_dot = position error; see pid

DC motor electrical dynamics, see dcmotor

act_dot = mju_muscleDynamics(...)

act_dot = mjcb_act_dyn(...)

gain_term = gainprm[0]

gain_term = gain_prm[0] + gain_prm[1] * length + gain_prm[2] * velocity

gain_term = mju_muscleGain(...)

DC motor gain (K or K/R), see dcmotor.

gain_term = gainprm[0] (ki), applied to act (the integrated position error), for the pid actuator.

gain_term = gainprm[0] (kp), applied to the geodesic orientation error log(q^-1 q_target), for SO(3) transmissions.

gain_term = mjcb_act_gain(...)

bias_term = 0

bias_term = biasprm[0] + biasprm[1]length + biasprm[2]velocity

bias_term = mju_muscleBias(...)

DC motor bias: back-EMF, cogging, LuGre friction, see dcmotor.

bias_term = biasprm[1]log(q^-1 q_target) + biasprm[2]omega, the geodesic analog of the affine bias for SO(3) transmissions.

bias_term = mjcb_act_bias(...)

Use the mesh's convex hull to compute volume and inertia, assuming uniform density.

Compute volume and inertia exactly, even for non-convex meshes. This algorithm requires a well-oriented, watertight mesh and will error otherwise.

Use the legacy algorithm, leads to volume overcounting for non-convex meshes. Though currently the default to avoid breakages, it is not recommended.

Assume mass is concentrated on the surface of the mesh. Use the mesh's surface to compute the inertia, assuming uniform surface density.

Maps a 2D image to a 3D object using texture coordinates (a.k.a UV coordinates). However, UV coordinates are only available for meshes.

Has the effect of shrink-wrapping a texture cube over an object. Apart from the adjustment provided by the texuniform attribute of material, the process is automatic.

Very similar to cube mapping, and in fact the texture data is specified in exactly the same way. The only difference is that the visualizer uses the first such texture defined in the model to render a skybox.

Color space will be determined from the image file itself. If no color space is defined in the file, then linear is assumed.

Linear color space.

SRGB color space.

No builtin texture.

Generates a color gradient from rgb1 to rgb2. The interpolation in color space is done through a sigmoid function. For cube and skybox textures the gradient is along the +Y axis, i.e., from top to bottom for skybox rendering.

Generates a 2-by-2 checker pattern with alternating colors given by rgb1 and rgb2. This is suitable for rendering ground planes and also for marking objects with rotational symmetries. Note that 2d textures can be scaled so as to repeat the pattern as many times as necessary. For cube and skybox textures, the checker pattern is painted on each side of the cube.

Fills the entire texture with rgb1, except for the bottom face of cube and skybox textures which is filled with rgb2.

No marks.

Edges of all texture images are marked.

A cross is marked in the middle of each image.

Randomly chosen pixels are marked.

Compiler will set the sleep policy as follows:

• A tree which is affected by actuators is not allowed to sleep (overridable).
• Trees which are connected by tendons which have non-zero stiffness and damping are not allowed to sleep (overridable).
• Trees which are connected by tendons which connect more than two trees are not allowed to sleep (not overridable).
• flexes are not allowed to sleep (not overridable).
• All other trees are allowed to sleep (overridable).

Constitute user overrides of the automatic compiler policy.

Constitute user overrides of the automatic compiler policy.

Can only be specified by the user and means "initialize this tree as asleep". This policy is implemented in mj_resetData and mj_makeData and only applies to the default configuration. If a keyframe changes the configuration of (or assigns nonzero velocity to) a sleeping tree, it will be woken up. This policy is useful for very large models where waiting for the automatic sleeping mechanism to kick in can be expensive. Trees initialized as sleeping can be placed in unstable configurations like deep penetration or in mid-air, but will only move when woken up. Also note that this policy can fail. For example if a tree marked as sleep="init" is in contact with a tree not marked as such (i.e., they are in the same island) then it is impossible to put the tree to sleep; such models will lead to a compilation error.

Disables the optimization for this body.

Does not (always) disable the optimization for this body.

Free "joint" with three translational degrees of freedom followed by three rotational degrees of freedom. In other words it makes the body floating. The rotation is represented as a unit quaternion. This joint type is only allowed in bodies that are children of the world body. No other joints can be defined in the body if a free joint is defined. Unlike the remaining joint types, free joints do not have a position within the body frame. Instead the joint position is assumed to coincide with the center of the body frame. Thus at runtime the position and orientation data of the free joint correspond to the global position and orientation of the body frame. Free joints cannot have limits.

A ball joint with three rotational degrees of freedom. The rotation is represented as a unit quaternion. The quaternion (1,0,0,0) corresponds to the initial configuration in which the model is defined. Any other quaternion is interpreted as a 3D rotation relative to this initial configuration. The rotation is around the point defined by the pos attribute. If a body has a ball joint, it cannot have other rotational joints (ball or hinge). Combining ball joints with slide joints in the same body is allowed.

A sliding or prismatic joint with one translational degree of freedom. Such joints are defined by a position and a sliding direction. For simulation purposes only the direction is needed; the joint position is used for rendering purposes.

A hinge joint with one rotational degree of freedom. The rotation takes place around a specified axis through a specified position. This is the most common type of joint and is therefore the default. Most models contain only hinge and free joints.

Joint limits are disabled.

Joint limits are enabled.

Joint limits will be enabled if range is defined (if autolimits is set in compiler).

Tendon limits are disabled.

Tendon limits are enabled.

Tendon limits will be enabled if range is defined (if autolimits is set in compiler).

Control input clamping is disabled.

Control input to this actuator is automatically clamped to ctrlrange at runtime.

If autolimits is set in compiler, control clamping will automatically be set to true if ctrlrange is defined without explicitly setting this attribute to "true".

Actuator force clamping is disabled.

Actuator force clamping is enabled.

If autolimits is set in compiler, actuator force clamping will be enabled if actuatorfrcrange/forcerange is defined.

Activation clamping is disabled.

Activation clamping is enabled.

If autolimits is set in compiler, activation clamping will automatically be set to true if actrange is defined without explicitly setting this attribute to "true".

No alignment will occur between the body frame and free joint.

Body frame and free joint will automatically be aligned with inertial frame.

Compiler's alignfree global attribute will be respected.

I have no clue.

Activates the geom-level fluid interaction model based on an ellipsoidal approximation of the geom shape. When active, the model based on body inertia sizes is disabled for the body in which the geom is defined. See section on ellipsoid-based fluid interaction model for details.

The position and orientation specified are fixed relative to the body where the camera/light is defined.

The camera/light position is at a constant offset from the body in world coordinates, while the camera/light orientation is constant in world coordinates. These constants are determined by applying forward kinematics in qpos0 and treating the camera/light as fixed. Tracking can be used for example to position a camera/light above a body, point it down so it sees the body, and have it always remain above the body no matter how the body translates and rotates.

similar to "track" but the constant spatial offset is defined relative to the center of mass of the kinematic subtree starting at the body in which the camera/light is defined. This can be used to keep an entire mechanism in view. Note that the subtree center of mass for the world body is the center of mass of the entire model. So if a camera/light is defined in the world body in mode "trackcom", it will track the entire model.

The camera/light position is fixed in the body frame, while the camera/light orientation is adjusted so that it always points towards the targeted body (which is specified with the target attribute below). This can be used for example to model an eye that fixates a moving object; the object will be the target, and the camera/light/eye will be defined in the body corresponding to the head.

The same as "targetbody" but the camera/light is oriented towards the center of mass of the subtree starting at the target body.

Supported by default native renderer

Supported by default native renderer

Not supported by default native renderer

Not supported by default native renderer

Three translational dofs per vertex. This is the most expressive but also the most expensive option.

A single radial translational dof per vertex. Note that unlike in the "full" case, the radial parametrization requires a free joint at the flex's parent in order for free body motion to be possible. This type of parametrization is appropriate for shapes that are relatively spherical.

Two orthogonal translational dofs (X and Y) per vertex. This restricts the motion of the vertices to planes parallel to the parent body's X-Y plane.

Three translational dofs at each corner of the bounding box of the flex, for a total of 24 dofs for the entire flex, independent of the number of vertices. The positions of the vertices are updated using trilinear interpolation over the bounding box.

Three translational dofs per corner, edge, face, and volume of the bounding box of the flex, for a total of 81 dofs for the entire flex, independent of the number of vertices. The positions of the vertices are updated using quadratic interpolation over the bounding box. While this option requires more degrees of freedom than trilinear flexes, it enables curved deformation modes, while the only modes achievable for trilinear flexes are strech/compression and shear. To understand the difference between the two parametrizations, see a trilinear cube and a quadratic cube.

grid generates a rectangular grid of points in 1D, 2D or 3D as specified by dim. The number of points in each dimension is determined by count while the grid spacing in each dimension is determined by spacing. Make sure the spacing is sufficiently large relative to radius to avoid permanent contacts. In 2D and 3D the grid is automatically triangulated, and corresponding flex elements are created (triangles or tetrahedra). In 1D the elements are capsules connecting consecutive pairs of points.

box generates a 3D box object, however flex bodies are only generated on the outer shell. Each flex body has a radial slider joint allowing it to move in and out from the center of the box. The parent body would normally be a floating body. The box surface is triangulated, and each flex element is a tetrahedron connecting the center of the box with one triangle face. count and spacing determine the count and spacing of the flex bodies, similar to the grid type in 3D. Note that the resulting flex has the same topology as the box generated by composite.

cylinder is the same as box, except the points are projected on the surface of a cylinder.

ellipsoid is the same as box, except the points are projected on the surface of an ellipsoid.

disc is the same as box, except the points are projected on the surface of a disc. It is only compatible with dim=2.

circle is the same as grid, except the points are sampled along a circle so that the first and last points are the same. The radius of the circle is computed such that each segment has the requested spacing. It is only compatible with dim=1.

mesh loads the flexcomp points and elements (i.e. triangles) from a mesh file, in the same file formats as mesh assets, excluding the legacy .msh format. A mesh asset is not actually added to the model. Instead the vertex and face data from the mesh file are used to populate the point and element data of the flexcomp. dim is automatically set to 2. Recall that a mesh asset in MuJoCo can be used as a rigid geom attached to a single body. In contrast, the flex generated here corresponds to a soft mesh with the same initial shape, where each vertex is a separate moving body (unless pinned).

gmsh is similar to mesh, but it loads a GMSH file in format 4.1 and format 2.2 (ascii or binary). The file extension can be anything; the parser recognizes the format by examining the file header. This is a very rich file format, allowing all kinds of elements with different dimensionality and topology. MuJoCo only supports GMSH element types 1, 2, 4 which happen to correspond to our 1D, 2D and 3D flexes and assumes that the nodes are specified in a single block. Only the Nodes and Elements sections of the GMHS file are processed, and used to populate the point and element data of the flexcomp. The parser will generate an error if the GMSH file contains meshes that are not supported by MuJoCo. dim is automatically set to the dimensionality specified in the GMSH file. Presently this is the only mechanism to load a large tetrahedral mesh in MuJoCo and generate a corresponding soft entity. If such a mesh is available in a different file format, use the freely available GMSH software to convert it to GMSH in one of the supported versions.

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.

None.

Bending only.

Stretching only.

Bending and stretching.

Flex elements cannot collide with each other.

Narrow phase only (i.e. all pairs are checked). This is a diagnostic tool and is never a good idea in practice.

Bounding volume hierarchies (strategy for midphase collision pruning).

Sweep-and-prune (strategy for midphase collision pruning).

Select sap in 1D and 2D, and bvh in 3D. Which strategy performs better depends on the specifics of the model. The automatic setting is just a simple rule which we have found to perform well in general.

Attach to a body in the inertial frame.

Attach to a body in the regular frame of the body (usually centered at the joint with the parent body).

Attach to a geom.

Attach to a site.

Attach to a camera.

Returns the first num contacts that satisfy the matching criterion, in the order that they appear in mjData.contact. Note that while this is the fastest option, it is also potentially non-deterministic: future changes to collision detection code may cause the identity and order of matching contacts to change.

Returns num contacts with the smallest penetration depth, ascending order.

Returns num contacts with the largest force norm, descending order.

This reduction criterion returns one new "synthetic" contact, located at the force-weighted centroid of all matched contacts. The frame of the contact is the global frame, so normal and tangent directions lose their natural semantic. The force and torque are computed such that a wrench applied at the computed position will have the same net effect as all the matching contacts combined. Note that this reduction criterion always returns exactly one contact.

float: This field serves two purposes. First, it indicates whether a contact was found in this slot, 0 means not found while a positive number means found. Second, the positive value equals the number of matching contacts. So if num = 3 contacts were requested but only 2 were matched, the found fields will equal (2, 2, 0); if 6 were matched they will equal (6, 6, 6).

Vec3: The contact force, in the contact frame.

Vec3: The contact torque, in the contact frame.

float: The penetration distance.

float: The contact position, in the global frame.

Vec3: The contact normal direction, in the global frame.

Vec3: The first tangent direction, in the global frame. In order to complete the full 3x3 contact frame, use tangent2 = cross(normal, tangent).

Unit-length 3D vector.

Unit quaternion. These need to be declared because when MuJoCo adds noise, it must respect the vector normalization.

Generic array (or scalar) of real values to which noise can be added independently.

Position stage.

Velocity stage.

Acceleration stage.

Texture file is a PNG texture.

Texture file is a Khronos Texture.

The control directly sets applied motor voltage

The PID controller uses the control as a reference setpoint relative to the joint position.

The PID controller uses the control as a reference setpoint relative to the joint velocity.

The control is a torque feedforward, like with pid/input.

The actuator will work as a passive device.

The control block is an exponential-map vector (3 controls, in radians).

The control block is a quaternion (4 controls, w-first). The commanded quaternion is normalized by the servo, and the control block resets to the identity quaternion. Requires dyntype "none".

RGB image.

Depth image (distance from camera plane).

Distance image (distance from camera origin).

Surface normal image.

Segmentation image.

The distance from the ray origin to the nearest geom surface, -1 if no surface was hit. If this data type is included, rays will be visualized as lines.

Normalized direction of the ray, or (0, 0, 0) if no surface was hit.

The point from which the ray emanates (global frame). For sites and perspective cameras, this is the site/camera xpos. However for orthographic cameras, ray origins are spatially distributed along the image plane.

The point where the ray intersects the nearest geom surface in the global frame, or (0, 0, 0) if no surface was hit. If this data type is included, intersection points will be visualized as spheres.

The geom surface normal at the point where the ray intersects it, in the global frame, or (0, 0, 0) if no surface was hit. Note that normals always point towards the outside of the geom surface, regardless of the ray origin. If this data type is included along with either dist or point, normals will be visualized as arrows at the intersection points.

The distance of the hit point from the camera plane, -1 if no surface was hit. Note that this depth semantic corresponds to depth images in the computer graphics sense.

Zero-order hold (piecewise constant).

Piecewise linear interpolation.

Cubic spline interpolation (Catmull-Rom).

No equality constraint is applied.

Edge constraints are enforced.

Averaged constraint is used, see flexvert.

A constraint is added to enforce that the invariants of the strain tensor do not change; this is only equality constraint type supported for trilinear and quadratic dofs elements and here.

Returned value is from a broadphase test (bounding sphere to bounding sphere).

Returned value is from a convex hull to convex hull test.

Returned value is from a vertex to face test.

Returned value is from a face to face test.

Parent values take precedence. When a conflict is detected, a warning is emitted but the parent value is not modified. This is the default and preserves the pre-existing attachment behavior.