What's the best way for loading in a usd scene with some quad faces ?

[Ltesfaye]

I was playing around with the terrain importer as a general USD loader, but I noticed that it only supported triangular faces rather than quad meshes. I am working with scenes that are a combination of quad and triangle faces.

I was wondering if I should use Isaac sim standalone USD loading approach or if there is a recommended way of doing this in orbit?

[Mayankm96]

For any asset, it is recommended to have its USD and use that since USD allows you to store a lot more information (physics schemas, visual schemas etc). This makes it a powerful format compared to other alternatives.

Regarding a mesh that has quads and triangle faces, I haven't worked with such a mesh before. Which format is the mesh in and were you able to make a USD for it?

[Ltesfaye]

I am currently working with a custom USD scene with a physics ground plane and a bunch of other assets with collider preset configured to them. I was able to load the scene using both the omni command way and the TerrainImporterCfg, but I noticed two issues. First, there is undocumented limitation of RayCasterCfg where it wouldn't do collision checks in the asset path I loaded in. To be more specific, the raycaster default checks for planes as child paths and, if one is found, sets that mesh as the collider geometry to load in. Second is the terrainLoader was unable to spawn quad faces. The default Isaac sim physics ground plane is a quad face plane and I that the terrain loader only handles triangles and not quads.

This can be seen in Line 258 of terrain_Importer: faces = np.asarray(mesh_prim.GetFaceVertexIndicesAttr().Get()).reshape(-1, 3)

I temporarily worked around this issue by merging my scene into one mesh and then pointing that as the raycaster path to load in with everything converted triangles. However, this is a very inefficient workflow that breaks all the texture and layer-specific physics properties of my scene.

I am implementing a new version to submit a pull request for an alternative approach of doing ray casters and would love to get your input on it:

1. Is there a reason why the current Raycaster method is better than just doing path-based filtering by looping the returns omni.physx.get_physx_scene_query_interface().raycast_all(...)?

   • I understand that this would add overhead due to each ray start point/ direction being looped and having to sort through the returns, but using a warping method would still be very fast.
   • Is this something that would scale with the RL environment cloning approach orbit is currently working with?

2. Assuming I build on top of the current RayCaster, add the multiple mesh and quad face support. Wouldn't this be highly redundant in terms of memory usage? Or, more plainly, would this cause an issue with the current approach?