UsdImagingMeshAdapter::GetTopology crashes on some meshes with UsdGeomSubset

As mentioned by @zanazakaryaie in #329 (https://github.com/PixarAnimationStudios/USD/issues/329#issuecomment-997849502) if you call UsdImagingMeshAdapter::GetTopology on meshes that use UsdGeomSubset, it crashes when attempting to convert them to HdGeomSubset. Many (but not all) of the USDZ files provided by Apple in their ARKit examples have this problem. Some of the crashing ones:

https://developer.apple.com/augmented-reality/quick-look/models/vintagerobot2k/toy_robot_vintage.usdz https://developer.apple.com/augmented-reality/quick-look/models/biplane/toy_biplane.usdz

I also hit this same problem when trying to use these examples to test my triangulation code.

Filed as internal issue #USD-7149

We're closing since we haven't been able to reproduce this issue, but if you run into it again (especially after 22.08), please re-open with new repro steps!

Thanks!

Hi! I'm using 24.05 and still run into this issue.

• USDZ file: https://developer.apple.com/augmented-reality/quick-look/models/drummertoy/toy_drummer_idle.usdz

• Mesh prim:

• Steps to reproduce:

   auto stage = pxr::UsdStage::Open("toy_drummer_idle.usdz");

   std::string meshPathString = "/toy_drummer_idle/toy_drummer_rig/toy_drummer_skinned_mesh/toy_drummer/polySurface186";
   pxr::SdfPath meshPath(meshPathString);
   pxr::UsdPrim meshPrim = stage->GetPrimAtPath(meshPath);
   std::cout << meshPrim.GetName() << std::endl;

   auto adapter = pxr::UsdImagingMeshAdapter{};
   auto topology = adapter.GetTopology(meshPrim, meshPrim.GetPrimPath(), pxr::UsdTimeCode::Default());

Output:

Exception thrown at 0x00007FFAB3E7152F (usd_sdf.dll) in ftl_usd_converter.exe: 0xC0000005: Access violation reading location 0x0000000000000EF0.

Hi John,

The adapters in the pxr/usdImaging/usdImaging directory are really meant to be used in conjunction with either UsdImagingDelegate or UsdImagingStageSceneIndex. The issue you're running into is that the GetTopology() call will try to update the geom subsets with a resolved material path, and references the per-stage material binding cache, which is a nullptr due to your nonstandard use of the adapter.

Can you let me know what you're trying to do with this code?

Thanks! Tom

Hi Tom, thanks for your answer.

I'm interested in the ComputeTriangleIndices and ComputeTriangulatedFaceVaryingPrimvar methods belonging to the HdMeshUtil class. Since the HdMeshUtil constructor requires a HdMeshTopology pointer, I'm using adapter.GetTopology(meshPrim, meshPrim.GetPrimPath(), pxr::UsdTimeCode::Default()); to get it and construct my HdMeshUtil object.

Would you suggest another approach?

Hi Tom, thanks for your answer.

I'm interested in the ComputeTriangleIndices and ComputeTriangulatedFaceVaryingPrimvar methods belonging to the HdMeshUtil class. Since the HdMeshUtil constructor requires a HdMeshTopology pointer, I'm using adapter.GetTopology(meshPrim, meshPrim.GetPrimPath(), pxr::UsdTimeCode::Default()); to get it and construct my HdMeshUtil object.

Would you suggest another approach?

You can use the "HDMeshUtil" class from NVidia GameWorks repository: https://github.com/NVIDIAGameWorks/dxvk-remix/blob/9a746c25bbc8b86a7ee94ce75738d6187b2a975c/src/lssusd/hd/usd_mesh_util.cpp

Thanks for the great resource, rickomax! Additionally, the code for constructing an HdMeshTopology is pretty straightforward to copy & paste: https://github.com/PixarAnimationStudios/OpenUSD/blob/release/pxr/usdImaging/usdImaging/meshAdapter.cpp#L384 ... and our topology schema is stable enough that I don't expect that to cause problems down the road. You could either omit the subset computation entirely, or replace the GetMaterialUsdPath with SdfPath::EmptyPath() or something. _Get/_GetPtr are just wrappers for UsdPrim::GetAttribute().

I'm going to close this issue, since this issue isn't a real defect in the software used as intended, but feel free to continue discussion here or on the AOUSD forums, and also feel free to file an issue asking for a generic (or USD-specific) interface to our mesh processing utilities, which I'm sure many folks would appreciate!