Joint setup error due to collisions

Omniverse Isaac Sim
1

Environment

  • Isaac Sim 6.0.1 standalone (not the pip/PyPI package), Windows
  • OS: Windows 11 Pro for Workstations, 10.0.26200
  • GPU: NVIDIA RTX A4000 (16 GB VRAM)
  • Driver: 596.72
  • Asset imported via the CAD Converter from STEP (Instancing Style = None, Composition Style = None,
    Unit = Millimeters, Convert Physics Data = disabled)

I am rigging a two-finger industrial gripper imported from STEP through the CAD Converter, to be
mounted on a FANUC arm. The gripper hierarchy is organised as:

components
├── right_claw / right_fixed      (dynamic RigidBody — carriage sliding on the rail)
│   ├── right_forefinger, right_thumb
├── left_claw  / left_fixed, rotor/{finger_guide, left_forefinger, left_thumb}
└── base                          (kinematic RigidBody — static root of the chain)
    ├── bottom_panel  (~14 meshes)
    ├── guide_panel   (~110 meshes — contains the actual linear rail)
    └── cover         (~70 meshes)

Every moving part has RigidBodyAPI, and every Mesh below it has CollisionAPI. The CAD import
produces a very high mesh count (~600 collider meshes in total for the whole gripper), because each
screw, dowel and bracket comes in as its own Mesh prim.

I created a Prismatic joint between base (Body0) and right_fixed (Body1) and set
physics:collisionEnabled = True on the joint, because I want to measure the real end-stop
positions of the rail by driving the carriage slowly (Stiffness = 0, Damping = 1000,
Target Velocity = 0.01) until it physically hits the mechanical stop, and then reading the arrest
position in the Joint Inspector — rather than guessing the joint limits by hand.

Since the rail has non-convex geometry (grooves and mechanical stops), a Convex Hull collider would
smooth exactly the features that produce the stop, so I set the collider approximation to
SDF Mesh on base.

Problem

As soon as the simulation runs, PhysX floods the console with:

PhysX error: PxGpuDynamicsMemoryConfig::collisionStackSize buffer overflow detected,
please increase its size to at least 844606416 in the scene desc! Contacts have been dropped.

The requested sizes are consistently around 840 MB (839991680, 840034408, 840511640,
840615408, 844606416 across consecutive frames). Because the contacts are dropped, right_fixed
tunnels straight through the rail geometry instead of stopping against it, so the
collision-based limit measurement is impossible.

What I have tried

  1. Narrowed the SDF scope. Initially SDF Mesh was applied to all ~194 meshes under base.
    I reverted bottom_panel and cover back to Convex Hull (they are structural/cosmetic parts,
    not contact surfaces), keeping SDF only on guide_panel (~110 meshes). The overflow persisted.
    I am now narrowing SDF down to the single mesh that is the actual rail surface.

  2. Disabled GPU Dynamics on the Physics Scene to fall back to the CPU pipeline. This removes the
    GPU buffer error, but the application becomes unresponsive for several minutes, after which the
    gripper moves a few millimetres and then locks in a skewed position. It never reaches the
    end stop.

  3. Checked for a residual scale, since a wrong scale would throw off contact/rest offsets. The
    chain is clean: only the intended 0.001 (mm → m) at the root prim, (1,1,1) everywhere below.

  4. Removed a stray RigidBodyAPI that had ended up on the purely organisational components
    parent prim, which was nesting rigid bodies inside another rigid body. Fixing this did not change
    the buffer overflow.

  5. Verified all physics APIs with a custom inspector script: every moving body has RigidBody +
    Collider on all of its meshes, kinematic flags are as intended (base kinematic, right_fixed
    dynamic).

Questions

  • What is the correct way to raise collisionStackSize for a single-scene, single-robot setup in
    Isaac Sim 6.0.1? I can see gpu_collision_stack_size in the Python API, but is there a supported
    way to set it on the Physics Scene prim so it persists in the USD stage?
  • Is a ~840 MB collision stack request expected for a CAD-imported assembly of this mesh count, or
    is it a symptom of something structurally wrong in how I set up the colliders?
  • Is the collision-based end-stop measurement approach even advisable here, or should high mesh-count
    CAD assemblies always use explicitly authored joint limits from CAD dimensions instead?
  • For the CPU fallback: is the multi-minute freeze simply the expected cost of ~600 colliders with
    SDF among them, or does it point to a different problem?
3

Hi, thanks for your post. First, the headline: ~840 MB is not normal. The default gpuCollisionStackSize is 64 MiB, so the scene is asking for about 12.6× the default. That size isn’t driven by how many meshes exist in the stage — it’s driven by how many contact pairs are actively being generated in a step. A number that large almost always means geometry is deeply overlapping and producing an explosion of contacts, not that the assembly is merely large.

The detail that matters most in your testing: narrowing from 194 meshes to a single rail surface barely moved the number. If the cost were spread across the assembly, it would have dropped roughly proportionally. Since it didn’t, one pair is generating essentially all of it. The suspected causes, in order of likelihood:

  • The carriage and rail start interpenetrating. CAD assemblies are normally modelled in contact, and a mating face-to-face pair that overlaps even slightly at t=0 will generate a huge contact set as PhysX tries to depenetrate.

  • SDF resolution on a large mesh. SDF cost scales with the grid over the mesh’s bounding box; a long rail at a fine resolution gets expensive very quickly.

  • The 0.001 mm→m scale at the root. Scaled collider hierarchies are worth ruling out explicitly — if you can, bake the unit conversion into the geometry and set metersPerUnit rather than carrying a 0.001 scale above the colliders, then re-test.

Authored limits instead of collision end-stops is the way to go. Set physics:lowerLimit/physics:upperLimit on the PrismaticJoint to define the carriage travel. That gives you:

  • an exact, deterministic stop position (a mesh contact stop varies with contact offset and penetration);
  • no tunneling — the limit is a solver constraint, not a contact, so it can’t be missed at speed the way a contact can;
  • essentially zero cost, versus SDF contact generation every step.

Once travel is defined by the joint, you can usually drop collision on the rail entirely, or filter the carriage↔rail pair with UsdPhysics.FilteredPairsAPI, and the buffer problem should disappear with it. Keep collision only where you genuinely need contact response with the outside world.

4

Hi, we haven’t heard back since we shared detailed guidance on the collision stack overflow and the recommendation to use authored physics:lowerLimit/physics:upperLimit on the PrismaticJoint instead of collision-based end-stops. We’ll close this thread for now. If you’re still experiencing issues, please open a new topic and reference this one.