Weird spawn speed of instanceable usd
Hi, I recently converted my robot from urdf to instanceable usd. I double checked if the actual usd is instanceable and printed out the prim.IsInstanceable(). However, I tested the speed in source/standalone/tools/check_instanceable.py and got the following speed:
| Clone time | Setup time | Memory | |
|---|---|---|---|
| convex hull + instanceable + replicate physics | 1.5562s | 8.4059s | 2600MB |
| convex hull + instanceable | 1.6026s | 34.429s | 2669MB |
| convex hull + replicate physics | 1.3798s | 4.2639s | 2639MB |
| instanceable + replicate physics | 1.7873s | 10.474s | 3251MB |
| instanceable | 1.6936s | 39.44ss | 3339MB |
| replicate physics | 1.4311s | 6.7025s | 3339MB |
| -- | 1.5059s | 227.458s |
Ideally, instanceable should be faster and allocate smaller amount of memory right?
@Mayankm96
Thank you for the investigation. Would be great to provide some more details on the asset itself (number of links, meshes, materials, colliders, joints etc.)
Usually, yes. Instancing should make it faster to parse the scene and consume less memory. However, over time, we have heard from the Omniverse Kit team that they have started optimizing the USD stage implicitly, so some of the benefits of instancing may become less "visible." We tried this out on our end for different assets, and the numbers seem inconclusive (sometimes instancing took less time, sometimes more -- depending on how many meshes, visuals, or colliders are there).
I'll keep this issue open to get some more attention on whether we can just get rid of instancing at some point (if numbers are always promising). Until then, the general recommendation will be to do instancing when you can (and especially if the asset is complex).
Hi @supersglzc - Are you still seeking assistance with this issue? and have you tried it with latest Isaac Sim and Isaac Lab release?