Move Dexsuite procedural cuboids out of the shared object library

[qianl-nv]

Summary

Remove dexsuite procedure object from registry to avoid agent usage.

Detailed description

• Keep Newton-only table/cube assets local to the Dexsuite lift example and construct them directly instead of registering them globally.
• This excludes them from the env gen agent visible asset catalog.

[greptile-apps]

Greptile Summary

The PR removes Dexsuite-specific procedural cuboids from the global asset registry so they are no longer exposed to environment-generation agents.

• Defines the table and manipuland lazily within the Dexsuite environment module.
• Migrates the Dexsuite factory and affected tests to construct those local asset classes directly.
• Updates workflow documentation to describe the assets as environment-local.

Confidence Score: 5/5

The PR appears safe to merge with all in-repository consumers migrated away from the removed registry entries.

The procedural assets retain their spawn properties and pose setup through the local Object subclasses, while searches found no remaining code or persisted configuration that requests the removed registry names.

Important Files Changed

Filename	Overview
isaaclab_arena_environments/dexsuite_lift_environment.py	Adds lazy, cached procedural table and cube classes and constructs them directly in the Dexsuite environment.
isaaclab_arena/assets/object_library.py	Removes the Dexsuite-only procedural cuboids and their global asset registrations.
isaaclab_arena/tests/test_dexsuite_kuka_lift_example.py	Replaces registry assertions and lookups with direct construction through the environment-local class factory.
isaaclab_arena/tests/test_physics_settle.py	Migrates the settle-test floor from the removed shared class to the local procedural table factory.
docs/pages/example_workflows/dexsuite_lift/step_1_environment_setup.rst	Updates the environment setup example to show the current factory API and environment-local cuboid construction.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  Before[Global AssetRegistry] --> Agent[Agent-visible asset catalog]
  Before --> Dexsuite[Dexsuite lift environment]
  Local[Environment-local procedural_asset_classes] --> Dexsuite
  Local -. not registered .-> Agent

Loading

_{Reviews (1): Last reviewed commit: "Document Dexsuite procedural assets as e..." | Re-trigger Greptile}

[arena-review-bot]

🟡 Is this the right home for these cuboids?

They aren't really dexsuite-specific — test_physics_settle reuses ProceduralTable as a plain floor, so a core test now has to reach into a specific environment module to get one. Would a neutral, un-registered home read better? (I see the package __init__ auto-imports every module here, so such a module would need adding to _NON_ENVIRONMENT_MODULES to stay off the pxr import path — the lazy factory is a fair workaround for that constraint either way, just wondering about placement.)

[arena-review-bot]

🔵 Snippet drifted from build()

The actual build() still passes teleop_device=None and keeps rl_policy_cfg=dexsuite_rl_cfg_entry, so this snippet no longer matches the file it documents. Worth re-syncing the two (or trimming the code the same way).

[arena-review-bot]

🤖 Isaac Lab-Arena Review Bot

Summary

Cleanly moves the Newton-only procedural table/cube out of the shared object library (−91 lines from core object_library.py) into an env-local lazy factory, so they no longer surface in the AssetRegistry / env-gen agent catalog. Good direction and a genuine simplification — the shared _ProceduralCuboid base going through Object's spawner_cfg path is nicer than the old per-class _generate_rigid_cfg overrides. Two small notes below; nothing blocking.

Design, Boundaries & Scope

One placement question (raised inline): test_physics_settle reuses ProceduralTable as a plain floor, which suggests these cuboids aren't truly dexsuite-specific — so a core test now imports from a specific environment module. The lazy factory itself is a fair workaround given the package __init__ auto-imports every module (a top-level module would need _NON_ENVIRONMENT_MODULES), so this is a question about where the shared primitives live, not the mechanism.

Findings

🟡 dexsuite_lift_environment.py — Are the generic cuboids in the right home, given another test reuses one? (inline)
🔵 docs/.../step_1_environment_setup.rst:72 — Doc snippet drifted from build() (teleop_device=None and the dexsuite_rl_cfg_entry variable are still in the real code). (inline)

Test Coverage

Adequate. Removing test_procedural_assets_registered is correct now that the classes are intentionally unregistered, and both construction paths remain covered by test_dexsuite_kuka_lift_task_matches_lift_mdp_flags and test_physics_settle. Test imports of procedural_asset_classes() are correctly deferred (inside functions, after sim init).

Verdict

Ship it — optionally address the two minor notes.