Issue Writing out .USDA Files for Meshes Generated in Connector

Hello,

I’m currently developing an Omniverse connector for some external geometry files. As a result of a bug in my code (and my subsequent efforts to debug it) I have noticed that whenever I try to use create to export to the USDA file type (so that I can pinpoint any errors in the geometry by comparing it to the data source) it seems to just export as another USD binary file that is unreadable in a text editor. The current USD file and the attempted USDA file are the same size so something is clearly wrong - the ASCII version should be much larger.

I figured this might be a result of my USD being broken in some way - unable to convert because I had imported some data to it incorrectly. This led me to installing a clean version of all Omniverse utilities and the Omniverse connect sample on another PC. When trying to export the cube in the connect sample on a new computer, the same error occurred.

I then tried using a USD file from the Pixar kitchen scene and it converted to ASCII just fine.

All that said, can anyone corroborate the issue I’m having here? Any ideas would be greatly appreciated. My current assumption with the information given above is that something might be missing in the connect sample - some inclusion in the generation of a USD file that is necessary for conversion to USDA.

Any advice is welcomed, thank you!

@LMTraina99 - I am sorry that you are having issues with Omniverse. Just so i am clear:

  1. have an asset (.usd)
  2. load this asset into Create (at this point it looks ok?)
  3. In Create → Save as to .usda file.
  • Result is a file that is not ASCII?
  • Are you saving this file to some place on your hard drive?

Can you upload the .usd file and the created .usda file?

Also:
Is this a Windows or Linux system

Hi @mirice,

I appreciate the quick response! The situation is curious and I was hoping you could shed some light on why the nucleus server behaves the way it does.

The three steps you stated are correct. Though the point you listed below about being on my hard drive gave me a working ASCII file. I am on a windows system and I was trying to save as a USDA file on my local Omniverse server.

In our past experiences the ASCII file was of course a few times larger than the binary, but when saving to the server the file is roughly the same size (~+1kb). The resulting ‘ASCII’ file is also still completely visible and functional within Omniverse Create while accessing it from my server. But if I copy this USDA file to a local drive and then try opening it in create it will give the ‘failed to open stage’ error.

i.e. when saving a USD as a USDA to a local Omniverse Nucleus server, it just creates another binary USD (or something very close to it). But when I save a USD as a USDA to local hard drive directly it works as intended.

I can’t upload the models I’m working on but I can upload an example geometry generated from my connector. The example here is just a sphere without texture coordinates imported from our software. I’ve included the USD and USDA from my Nucleus server.

sphere_no_uv.usd (7.3 KB)
sphere_no_uv.usda (7.3 KB)

To reiterate: the second file will open from the server but not from any other location if copied, it also isn’t readable in ASCII. Saving the first file as a USDA to a location that isn’t on the server appears to circumvent these issues.

Is this a limitation of Create’s interaction with the Nucleus server? It makes sense that you wouldn’t want to waste storage space live editing the ASCII version but I’d like to know if there’s any other reason.

Again I really appreciate your quick response, thank you!

@LMTraina99 -

Create 2021.1.1 cannot save a .usd file to a .usda (ascii format) on a Nucleus server. To get a .usda file you need to “save as” to a location outside of Nucleus (such as your hard drive)

Going forward, Create and Nucleus will have the ability to save a .usda file in the format expected within Nucleus. Currently for our live sync/share capabilities we require all Nucleus files to be .usd for this functionality to work. Future releases will allow live sync/share with .usd, .usda and other formats. Thus you will get this native format that you were expecting.

But with the above caveat of having to save to your hard drive, you should be able to proceed with looking at the contents of what your connector is actually creating in .usda ascii format.

1 Like

Understood!

Thank you for your help!

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.