Repository navigation
Document how contact friction is combined when randomizing materials - #8976
blessedefe4real wants to merge 1 commit into
Conversation
randomize_rigid_body_material samples per-shape friction, but the friction applied at a contact also depends on the other shape and on how the solver combines the two. With Newton's MuJoCo Warp solver, shapes of equal mjc:priority use the larger of the two coefficients, so a terrain friction at or above the sampled range masks the randomization entirely. Describe the combine behavior for PhysX and MuJoCo Warp and point to the two ways of keeping the randomization effective: a lower terrain friction, or a higher MujocoCollisionCfg.priority on the asset. Fixes isaac-sim#8869
 [Low impact] The documentation-only change appears safe to merge. SummaryDocuments how contact friction depends on both shapes’ materials.
No actionable issues were found. No runtime tests or documentation build were run. Reviews (1) · Last reviewed commit: "Document how contact friction is combine..." · Reviewed by Greptile |
There was a problem hiding this comment.
Isaac Lab Review Bot
Needs attention: Style consistency (1). Other reviewed categories look good.
- PR description: The title and body accurately describe the 12-line docstring update and changelog skip, provide rationale and validation, and make no performance claims requiring evidence.
- Design and architecture: Architecture looks good.
- Scope and over-engineering: No over-engineering issues.
- API: API changes look good.
- Compatibility and deprecation: No breaking changes identified.
- Implementation: Implementation looks good.
- Style consistency: The terrain-friction sentence incorrectly covers every contact; restrict it to asset-terrain contacts so the documented behavior remains accurate.
- Test quality: Test quality looks good.
Minor fixes needed. Posted 1 inline finding.
Automated review; human maintainers own approval decisions.
| :attr:`~isaaclab_physx.sim.spawners.materials.PhysxRigidBodyMaterialCfg.friction_combine_mode`. | ||
| - **Newton with the MuJoCo Warp solver**: When both shapes have the same MuJoCo contact priority | ||
| (``mjc:priority``, which defaults to 0), the solver uses the larger of the two friction coefficients. | ||
| If the terrain friction is at or above the upper end of ``static_friction_range``, every contact uses |
There was a problem hiding this comment.
🟡 Warning · Style Consistency — Overbroad claim about affected contacts
High terrain friction only dominates asset-terrain contacts; asset-asset contacts still use the randomized values under the same max rule. Scope the sentence to contacts with the terrain so the documented behavior is accurate.
Description
#8869 reports that on Newton MJWarp, robot friction randomization has no effect in the default locomotion setup because the terrain friction (1.0) is above the sampled range, and asks for the difference to be documented.
The behavior is confirmed in Newton at the pinned commit (
newton/_src/solvers/mujoco/kernels.py,contact_params): for two geoms of equalmjc:prioritythe solver uses the element-wise maximum of their friction, matching MuJoCo's documented rule. Higher-priority geoms use their own friction.This documents in
randomize_rigid_body_materialhow contact friction is combined on PhysX/OVPhysX (material combine mode) and on Newton with MuJoCo Warp (max at equal priority), and the two ways to keep the randomization effective: a terrain friction below the sampled range, or a higherMujocoCollisionCfg.priorityon the asset's colliders.Fixes #8869
Type of change
Checklist
pre-commitchecks.skip, docstring-only change)CONTRIBUTORS.mdor my name already exists there