Creating a Fabric prim with the same path as a previously destroyed prim causes a crash. Previously this was avoided by including the object id and pool id in the name, but on extension reload the pool id is initialized to 0 and new paths may conflict with old paths.
Now a contextId is randomly generated and ensures that Fabric prim paths are unique even across extension reloads.
There are probably more robust and safer ways to do this than glm::linearRand<int64_t>(0, 100000), like using a timestamp, but since extension reloads are uncommon and I didn't want to overcomplicate this.
With the fix applied the extension no longer crashes when disabled and re-enabled:
Creating a Fabric prim with the same path as a previously destroyed prim causes a crash. Previously this was avoided by including the object id and pool id in the name, but on extension reload the pool id is initialized to 0 and new paths may conflict with old paths.
Now a contextId is randomly generated and ensures that Fabric prim paths are unique even across extension reloads.
There are probably more robust and safer ways to do this than
glm::linearRand<int64_t>(0, 100000)
, like using a timestamp, but since extension reloads are uncommon and I didn't want to overcomplicate this.With the fix applied the extension no longer crashes when disabled and re-enabled:
https://github.com/CesiumGS/cesium-omniverse/assets/915398/401010f7-7285-4b35-a1c3-784af21f21fb