[Question] Modifying prims scale on every reset

[h4ri98]

Question is very similar to #2524 in my case I have a manager based RL environment and I am not deleting/adding any objects on reset, but rescaling some of the meshes I already have. As per the discussion in the linked issue, the solution seems to be using the Isaacsim core World api to start and stop simulation before rescaling the meshes.
[Error] [omni.physx.tensors.plugin] Simulation view object is invalidated and cannot be used again to call setDofActuationForces

I was getting a similar error as mentioned above when I tried to rescale without using world start and stop. After adding the below lines in my events function, I am not getting any errors but the training does not begin. I am using skrl to train and made some custom changes to the reach environment provided.

world = World(env.sim)

if(env.sim.is_playing()):  
    world.stop()
  *** Some processing to modify scale of certain prims in the scene ***
world.start()

As of now, these are the options I am aware of as a workaround

• Use deformable objects if the rescaling is for primitive meshes like cylinder, cuboid (Found this in a forum discussion, but I haven't figured out how to do this)
• Spawn the same meshes at multiple scales before the training begins and just use the desired scale one and set the positions of remaining meshes to be some random pose which is out of the desired space. (This has serious limitations for my current use case because of resolution I want the scaling in)

It would be very helpful if you could provide an example of how to use the world api to do this or suggest any better alternative methods. Thanks!

[RandomOakForest]

Thank you for posting this. Here's an example and summary of things to consider for rescaling meshes without adding/deleting objects, using the World API properly:

Rescaling Meshes - Using World API

from omni.isaac.core import World
from pxr import UsdGeom

def rescale_meshes(prim_paths, new_scales):
    # Get the current world instance
    world = World.instance()
    
    # Pause physics before modifications
    if world.is_playing():
        world.stop()
    
    # Process scaling operations
    stage = world.stage
    for prim_path, new_scale in zip(prim_paths, new_scales):
        prim = stage.GetPrimAtPath(prim_path)
        if prim.IsValid():
            xform = UsdGeom.Xformable(prim)
            xform.ClearXformOpOrder()
            scale_op = xform.AddScaleOp()
            scale_op.Set(new_scale)
    
    # Restart physics after modifications
    world.start()
    world.reset()  # Critical for physics state update

# Usage in RL environment reset:
def on_reset(self):
    prim_paths = ["/World/Object1", "/World/Object2"]
    new_scales = [(1.5, 1.5, 1.5), (0.8, 0.8, 0.8)]
    rescale_meshes(prim_paths, new_scales)
    # ... rest of reset logic

Key Implementation Notes:

1. Use Existing World Instance: World.instance() retrieves the active simulation context instead of creating a new one ¹²
2. Clear Transform Operations: xform.ClearXformOpOrder() prevents transform conflicts when rescaling ³⁴
3. Mandatory Physics Reset: world.reset() after scaling updates the physics handles (prevents "invalidated simulation view" errors) ⁵¹
4. Batched Operations: Process all rescaling in a single stop-start cycle for efficiency

Alternative Methods Considered:

1. Deformable Objects (Not Recommended):
   • Requires complex setup with PhysxSchema and material properties ⁶
   • Better suited for soft-body simulations than static rescaling
   • Higher performance overhead
2. Pre-spawned Objects (Scenario-dependent):
   • Limitations: Memory-intensive for high-resolution scaling

# Initialize objects at multiple scales
scaled_objects = {
    0.5: world.scene.add(DynamicCuboid(scale=(0.5, 0.5, 0.5)),
    1.0: world.scene.add(DynamicCuboid(scale=(1.0, 1.0, 1.0)),
    2.0: world.scene.add(DynamicCuboid(scale=(2.0, 2.0, 2.0))
}

# At reset: Hide unused scales
def set_scale(scale_factor):
    for scale, obj in scaled_objects.items():
        obj.visible = (scale == scale_factor)

Critical Best Practices:

1. Never Modify During Simulation: Always verify world.is_playing() and stop physics before scene modifications ⁵¹
2. Use USD Xform Operations: Direct scale property modification causes physics collisions ³
3. Post-reset Initialization: Call world.reset() after scaling to reinitialize physics handles ¹²
4. TensorAPI Considerations: If using PhysxSchema, update contact offsets after scaling:

physx_collision_api = PhysxSchema.PhysxCollisionAPI.Get(prim)
physx_collision_api.GetContactOffsetAttr().Set(new_contact_offset)

This implementation resolves the "invalidated simulation view" error by properly managing the simulation state during rescaling operations. The World API approach provides real-time scaling capability without memory overhead of pre-spawned objects ⁵¹².

References

Footnotes

1. https://docs.isaacsim.omniverse.nvidia.com/4.5.0/py/source/extensions/isaacsim.core.api/docs/index.html ↩ ↩² ↩³ ↩⁴ ↩⁵

2. https://docs.omniverse.nvidia.com/isaacsim/latest/core_api_tutorials/tutorial_core_hello_world.html ↩ ↩² ↩³

3. https://docs.omniverse.nvidia.com/isaacsim/latest/how_to_guides/environment_setup.html ↩ ↩²

4. https://docs.isaacsim.omniverse.nvidia.com/latest/python_scripting/environment_setup.html ↩

5. https://github.com/isaac-sim/IsaacLab/issues/2524. ↩ ↩² ↩³

6. https://forums.developer.nvidia.com/t/discrepancy-between-deformable-and-visual-meshes-in-python-standalone-application/320193 ↩

[h4ri98]

Thank you for the response. I just tried this out and my training was still not starting. I tried to use the debugging option in VScode to get some more details and this is what I found. I had a breakpoint at world.stop(), and tried to step over to the next line. The execution gets stuck here with no error messages and it never completes the world.stop() call. I am not sure if I am doing anything wrong here. I am fetching the existing instance of world like you had suggested.

[h4ri98]

@RandomOakForest , any updates on how to use the world instance properly would be really helpful. Thanks!

[RandomOakForest]

That's interesting. I'll move this to our Discussions for the team to follow up.