Unreal continues to crash as long as 3dsMax is opened

Omniverse Connections & Data Exchange Omniverse Connectors
1

System used Intel(R) Core™ i7-7700K CPU @ 4.20GHz, Ram 64,0 GB, NVIDIA GeForce RTX 3090, Windows 10 64bits, 3dsMax 2022, Create and Unreal 4,27,0

Unreal does not open the USD file since 3dsMax and Create are running simultaneously.

Before I added 3dsMax to the pipeline, unreal was working fine with Create.

Here is the USD FILE

Here is the error log

image
image750×1202 52.8 KB

1 Like
2

Francisco, thanks for taking the time to report this. I downloaded your USD file and I am unable to open it in Create or usdcat. Both simply crash when I try. I’m going to dig into usdcat and see if I can get more verbose info for you.

I wonder if the crash corrupted the file and it’s just invalid now.

3

Based on my report below @aluk says it might be something like this:

The last time I saw a case like this, the content indices/offsets inside the crate file were corrupted to the point where Crate could not reason about the file structure (not necessarily the stage hierarchy, but how to navigate the various Crate sections denoting metadata keys, attribute values, etc).

More info:

  • Create’s log says this then it crashes:
[Info] [omni.usd] OmniMaterial_TreeTest.usd opened successfully in 0.01 seconds
  • usdchecker reports some unresolvable dependencies (http materials and textures from Create’s material browser), but nothing else
  • usdedit “fails to open”
  • usddumpcrate is able to give me a bunch of info about tokens, strings, paths, specs, etc…
Usd crate software version 0.9.0
@OmniMaterial_TreeTest.usd@ file version 0.7.0
  172 specs, 172 paths, 140 tokens, 25 strings, 129 fields, 91 field sets
  Structural Sections:
              TOKENS             1495 bytes at offset 0x6250
             STRINGS              108 bytes at offset 0x6827
              FIELDS              817 bytes at offset 0x6893
           FIELDSETS              377 bytes at offset 0x6BC4
               PATHS              449 bytes at offset 0x6D3D
               SPECS              225 bytes at offset 0x6EFE
  • usdtree gives me this:
> /
>  |--World [def Xform]
>  |   |--Plane [def Mesh]
>  |   |--Looks [def Scope]
>  |   |   |--Gravel_River_Rock [def Material]
>  |   |   |   `--Shader [def Shader]
>  |   |   |--Leather_Black [def Material]
>  |   |   |   `--Shader [def Shader]
>  |   |   |--Mirror [def Material]
>  |   |   |   `--Shader [def Shader]
>  |   |   |--Metal_Seamed_Roof [def Material]
>  |   |   |   `--Shader [def Shader]
>  |   |   `--Metal_Door [def Material]
>  |   |       `--Shader [def Shader]
>  |   |--Cone [def Mesh]
>  |   |--Cone_01 [def Mesh]
>  |   |--Cone_02 [def Mesh]
>  |   |--Cube [def Cube]
>  |   |--Cone_03 [def Mesh]
>  |   |--Cone_04 [def Mesh]
>  |   `--Cone_05 [def Mesh]
>  `--Environment [def]
>      `--sky_kloofendal_48d_partly_cloudy_4k [def DomeLight]

Based on the stage hierarchy, this doesn’t look like more than experimentation (as opposed to serious customer work), but if you’re interested in recovering this stage, maybe post to usd-interest or a Github issue on Pixar’s repo to see if Pixar has any internal utilities or insight on how to potentially recover the file.

4

Yes, we are still testing the applications workflow with primitives and any other object that is in the create library, is not an important file, and that is what is most disturbing, it is a very simple scene, but I hope we can find what made the file corrupt in the near future.