Support OvPhysX 0.6 while retaining public 0.5.11 compatibility - #7738
Support OvPhysX 0.6 while retaining public 0.5.11 compatibility#7738AntoineRichard wants to merge 5 commits into
Conversation
|
run-ci |
|
run-ci |
|
There was a problem hiding this comment.
Isaac Lab Review Bot
The release-aware reversed-joint correction, gravity-force basis handling, and OVStage schema registration are coherently integrated. One schema-registration regression should be fixed: failure to import OVStage now prevents the existing host USD schema registration path from running.
- Design and architecture: The OvPhysX release policy remains backend-local in
ovphysx_compat, while the shared generalized-force kernel supports backends whose forces already use the public joint basis. However, optional OVStage registration is currently coupled to host USD registration, so the independent registration paths are not properly isolated. - API: The generalized-force ordering kernel preserves behavior for callers supplying sign arrays, and the keyword-only
correct_joint_signsparameter retains the previous default. Public gravity-compensation shapes and return types remain unchanged, with changelog coverage for both affected packages. - Implementation: The version gate and dynamics-buffer paths preserve legacy 0.5.11 behavior while disabling redundant corrections for 0.6. In
_ensure_physx_schemas_registered, addingimport ovstageto the existing guarded import block causes any OVStage import failure to return beforePlug.Registry().RegisterPlugins(...); OVStage probing should be isolated so host schema registration still occurs.
Minor fixes needed. Posted 1 actionable finding inline.
Automated review; human maintainers own approval decisions.
| return | ||
| try: | ||
| import ovphysx # noqa: PLC0415 | ||
| import ovstage # noqa: PLC0415 |
There was a problem hiding this comment.
🟡 Warning · Implementation — OVStage import can skip host schema registration
import ovstage was added to the same try guarded by except ImportError: return, so an absent or renamed ovstage now makes _ensure_physx_schemas_registered return before Plug.Registry().RegisterPlugins(...), skipping the host USD registration of the wheel's codeless schemas that previously ran with only ovphysx and pxr installed, and leaving _physx_schemas_registered False. The OVStage API is already probed defensively with getattr; import it in its own guarded block so host registration remains unconditional.
There was a problem hiding this comment.
Fixed in c8f8b4e by guarding the optional OVStage import separately. Extended the existing schema-registration test to cover an unavailable OVStage import; it failed before the fix and now passes. All 36 lifecycle/compatibility cases pass on both 0.5.11 and 0.6.2.
| ``./isaaclab.sh -i 'ov[all]'``. | ||
|
|
||
| .. code-block:: bash | ||
| Internal OvPhysX 0.6.2 |
There was a problem hiding this comment.
maybe we leave this out from the docs
There was a problem hiding this comment.
we can just leave what's available for users
There was a problem hiding this comment.
Removed the internal-build section in c8f8b4e. Installation docs now cover only publicly available packages.
| tests skip with ``ovphysx wheel not installed`` and user code fails at import time. | ||
| uv sync --extra ov --extra test | ||
| uv run --no-sync \ | ||
| --index "$OVPHYSX_INDEX_URL" \ |
There was a problem hiding this comment.
I don't think we need to provide installation support for internal builds. we can just automatically switch to the code path that uses this if the code detects 0.6 is installed in the environment
There was a problem hiding this comment.
Removed the internal installation instructions in c8f8b4e. Public pins remain unchanged, and the existing runtime version detection automatically selects the 0.6 compatibility path when that version is installed.
|
run-ci |
|
run-ci |
marcodiiga
left a comment
There was a problem hiding this comment.
Reviewed c8f8b4e. The dynamics-sign and schema-registration changes look correct; one non-blocking installation-documentation issue is noted inline.
On ovphysx 0.5.11, 77 compatibility, lifecycle, and ordering tests passed, plus all eight reversed-joint dynamics cases on CPU and CUDA. The gravity assertions also detect the base implementation's sign error. Changed Python files and documentation examples passed syntax checks. CI is still running.
| .. code-block:: bash | ||
|
|
||
| ./isaaclab.sh -i 'ov[ovphysx]' | ||
| uv sync --extra ovphysx |
There was a problem hiding this comment.
[P2] Preserve installed extras when adding ovphysx
This is an exact sync: in an environment already synced with --extra test, it removes pytest, pytest-mock, and the other test-only dependencies. Packages belonging only to other unselected extras, such as isaacsim, are also removed. Please use uv sync --inexact --extra ovphysx so adding this backend preserves those dependencies, consistent with the tetrahedralization instructions. The dry run retains them with --inexact; see uv's sync behavior.
Description
Support OvPhysX 0.6 without changing the public 0.5.11 default or CI dependency sources. OvPhysX 0.6 already fixes reversed-joint Jacobians and mass matrices; applying Isaac Lab's legacy sign correction again produces incorrect dynamics. Gate that correction by the installed runtime's release line, including 0.6 development builds.
Gravity compensation forces already use the public joint basis in both tested versions. Remove their extra sign correction while retaining joint ordering. Register the wheel's physics schemas with OVStage's independent registry when that API exists, including when host USD already supplies the schemas.
Keep installation documentation limited to publicly available packages. The compatibility path is selected automatically when OvPhysX 0.6 is already installed; no internal-build installation support is added. Public package pins and CI workflows remain unchanged. The schema fix is adapted from
integration/ovphysx-nextand overlaps #7626.Type of change
Release backport
developValidation
1ac23b8fafa; CI is being rerun for the review follow-up.The internally tested OVRTX 0.5/OVStage renderer still differs from existing Cartpole RGB goldens (2.02% pixels versus 1.50% allowed). Unchanged
developcode with the same native stack reproduces it; the public renderer stack passes. Golden images and thresholds are unchanged.Checklist
uv run isaaclab -fCONTRIBUTORS.md