Slow USD file loading with UE Connector and Rhino

Hello,

I’m publishing a relatively simple Rhino scene (50mb) to Omniverse. Then, using the Omniverse Unreal connector, I open the usd file in Unreal Engine 5.0.1. with the Omniverse connector installed and running.

The issue is that the scene takes a very long time to load in UE, every time I load the scene (3 to 7 minutes, and sometimes it just freezes). In Rhino and Create it loads super quick in comparison.

Also, if I use the USD Importer by Epic, it loads super quick (5 seconds) using the USD Stage Window, but it fails to load any materials, even though I choose as my render context “mdl”. I get this error for every shader:

“2_ARQ___v10C__RENDER_/Looks/Default’ bound to prim ‘/World/VN_290422_ARQ___v10C__RENDER_/Geometry/M___PAI/M___JARDINERA/Mesh_cc86448c54774f6ba16bb477af0fcc63’ as it contains no valid surface shader source for render context ‘unreal’”

So, when using the Omniverse connector materials load perfectly, but I get a huge performance hit in loading times and stability, and if I use the Epic’s USD plugin I can’t load materials correctly.

Maybe I’m missing something in the process?

Rhino Connector Version: 107.1.577

Omniverse UE Connector version info:
Omniverse Plugin Version: 104.3.208.41d98eef
MDL Plugin Version: 104.3.208.41d98eef
Omniverse Client Library Version: 1.17.4-mr375.2854+tc.4b1d4bd7
USD Version: 20.8
Build Date: Apr 26 2022

Epic USD Importer version: 1.0

Thank you

Thanks for the detailed report Julian. I am surprised that after the first load that you’re seeing such bad performance since we do a lot of caching. Would it be possible to get a repro stage from you so that we could investigate this further?

Note that I created an internal issue OM-50300 to track this.

Sure thing Lou, is there a way to send you a WeTransfer link with the repro stage?

Thank you

I took a quick look at what might be happening and I see two issues immediately that we’ll try to resolve in a future release:

  • As we are loading prims in the OmniverseStageActor we evaluate all of the existing prims to see if we need to remove any in the case that a variant has changed. This will probably need to be revamped so that we don’t constantly iterate our existing objects map…
  • In our USD Layer handling code I’m running into more than one place where we’re recursively traversing prims, and in this stage that will never work.

The stage has over 5000 prims, which should be fine, but in this case we’re seeing multiple pathological issues. Thanks again for bringing this to our attention and providing a quick repro.

Thanks Lou for all the info, it’s great to know it’s something that can be fixed in a (hopefully near!) future release.

In the meantime I’ll be doing more tests from different apps, I’ll let you know if I find anything else,

kind regards

Julian, I really appreciate your report and repro stage. We were able to change some of our tracking container types (think arrays to maps…) to greatly reduce the amount of time required to load and reload the stage in Unreal. Your repro stage now opens in 36 seconds the first time, and in 8 seconds in subsequent loads. Our next release will contain the fixes for this issue.

1 Like

Hi Lou,

That’s really great to hear, thank you so much for taking this into consideration. Looking forward to the next release!

kind regards