Strange Collider for Elongated Capsule

I think the strange collider in my robot configuration is causing a lot of instability during training. I speculate it is because of the strange collider that has been assigned to the capsule. To resolve such instability without changing the collider, I have to increase time steps per second into a unreasonable amount to be any efficient.

Perhaps I could increase the collider’s geometry complexity of the capsule, but I don’t think they has any effect on it

Perhaps I could change the capsule type to mesh type. but I am not sure how to do it. What will be a good solution for it?

You can also observe such strange collider if you create a capsule, then give radius of 0.01 an height of 1

Hi @octipus - Have you referred to this doc?

I see this line here,

“PhysX supports exact representations for Cube, Capsule, and Sphere shapes, so no approximations are required.”

But referencing the image provided. I don’t see the representations are exact.

Hmm this seems to be a bug in the USD debug visualization code, we will fix it for next release.
However the collider is correct in simulation, if you enable PhysX debug visualization (Window->Simulation->Debug), there you can enable PhysX debug visualization and colliders visualization. This is whats inside PhysX SDK:

Sorry about the trouble,

1 Like

I have a related issue with capsules: The orientation seems to differ between the Isaac Sim collision guides (green) and the actual collision shapes (purple). The rotation frame seems to be misaligned, so a 90 deg rotation in Y corresponds to different rotations. Any ideas what causes this?

Thanks in advance :)


This looks like another bug introduced in the recent debug vis changes, could you please share the usd file with me, we will fix it.

Hi Ales,
unfortunately, I cannot share the file, but you should be able to reproduce the error quite easily. Just add a capsule as a collision shape and rotate it around x or y. I don’t know if it makes a difference, but I am using two usd files, one for instancable meshes.

Thanks, I was able to reproduce this, there seems to be incorrect relative transform computation for some reason, will debug and fix this. Thanks for reporting!


This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.