The proper approach to writing a dedicated 3D importer/exporter for Create?

Omniverse General Discussion
1

I will be kicking myself once I hear of the answer to my naive questions so please bear with me. I sort of sense the answer before asking these questions. However, the answer is not entirely obvious to me after reading tons and tons of docs, example source, kit-examples, etc.

I am fairly new to Omniverse development and hence I’m a bit green under the gills to discern the proper approach to this quest.

My basic question: what is the correct approach to writing custom 3D import/export converters for ‘Omniverse Create’ along the lines of the Assimp/FBX/glTF/CAD converters which are hooked in directly to Kit as DLL modules with a Python integration interface?

  1. “An Overview of Universal Scene Description (USD) for Building Virtual Worlds [S52054]” alludes to custom OBJ/etc import/export converter modules for the ILM USD SDK but I’m 100% sure that they have nothing to do with Omniverse and what I’m talking about in this message.

  2. There doesn’t appear to be any example implementations of these kit-API-based converters so they may be proprietary to NVIDIA?

  3. I’m jumping ahead of myself but I’m guessing that the data is streamed directly to/from the core scene graph via the Omniverse API and not any back-end USD files? Is this method fast enough (C++ based??) to handle very large files?

  4. Given that Omniverse has very strong USD support, could one of these custom plug-ins be developed (for integration into the Menus like 3MF or the import/export dialog box) but use a USD file as a back-end means to interface to Omniverse rather than a hard coded API connection? In other words, the converter would convert its native format to/from USD and then call a Kit-based API to load/save the file to the Omniverse Create USD-based scene graph.

  5. I don’t want to develop a connection to an external app but rather to code up an integrated converter, either via the help of an intermediate USD file or a direct connection via a scene-graph-level API.

2

Hi @user122750. Some great questions that I’m sure others will be interested in.

Most of our importer/exporters are implemented as USD FileFormat plugins. I don’t think we have the source code for any of the NVIDIA ones available, but you can find a rudimentary example here for OBJ: USD/extras/usd/examples/usdObj at release · PixarAnimationStudios/USD · GitHub

FileFormat plugins are great because they can translate from the source format to USD on the fly when you reference them into a Stage or you can use them to convert. Once the plugin is registered, you can use a tool like usdcat to convert back and forth or call the underlying API that usdcat uses to do the same in some other app. Yes, it’s valid to develop a FileFormat plugin instead of a Connector.

So, how do you get started?

  1. Currently, for you plugin to work in Omniverse, you’ll need to build it against nv_usd. We only make this available to partners at the moment. Send me a private message for more info about this.
  2. You could start building you plugin using a vanilla build of USD and testing in usdview. Once that’s working, we could talk about getting it built for nv_usd which shouldn’t be too much work.
  3. You could start prototyping with a Python USD script. This wouldn’t be a FileFormat plugin, but a lot of the translation logic would apply to your C++ implementation.

I think I covered all of your questions, but let me know if I missed anything.

1 Like