What aspects of USD are or will be supported?

With the new USD export feature, I have some questions on how well integrated the export API (in particular from python) will be with usd-core.

  1. What aspects of USD does it currently support (lets just say the export will work)? Is there a list of the supported aspects of the USD schema?

  2. USD includes animation, physics, robotics and human animated joints. Will rhino start to support that, or will the integrations like kangaroo start using USD to format the physics objects?

  3. w.r.t. more control on exports, does it (already, or plan to) support using cpython with usd-core to interact directly with the rhino scene.

For example, when I use the rhino script editor I can now use cpython (i love it!!) and with # requirements usd-core can make a usd stage, add a prim etc. Will this usd stage be created in Rhino, and vice-versa, with objects in Rhino being available to query in USD? For clarity, I mean is the plan that this will create a sphere in Rhino:

from pxr import Usd, UsdGeom
stage = Usd.Stage.CreateNew('HelloWorld.usda')
xformPrim = UsdGeom.Xform.Define(stage, '/hello')
spherePrim = UsdGeom.Sphere.Define(stage, '/hello/world')
stage.GetRootLayer().Save()

Another example that just came up for me. I am using the rhino pointcloud :

  point_array = System.Array[Rhino.Geometry.Point3d](points)
  pt_cloud = Rhino.Geometry.PointCloud(point_array)
  pt_cloud_id = sc.doc.Objects.AddPointCloud(pt_cloud)
  sc.doc.Views.Redraw()

When I Export as USD, how can I define that this pointcloud should be defined with GeomPoints?

Its very cool seeing USD supported!

There’s a new USD export feature?

Does it finally merge vertices unlike the old FBX export feature?

Does it support instances (blocks) or perhaps even parent objects under xforms per layer?

Is this why Nvidia are using Rhino logos in their Omniverse presentations? (There’s supposedly also an Omniverse connector?)

Isn’t it import only?

Nope - export as well. Works great - you can open exported USDZ models directly as AR models on iPhone - super handy!


-Jakob

1 Like

We haven’t written any SDK access specific to USD export yet. This will be based on user requests and will follow the same pattern that we have established in Rhino 8 for exporting to other file formats in RhinoCommon. This example shows DWG, but something similar could be written for USD.

1 Like

I would be very interested in USD because one of my biggest and most important clients is looking for a neutral exchange format.

But I can only find a USD export option in Rhino 8, no import. Also, I have the impression that all blocks are exploded and NURBS data is not saved without converting to meshes - my 400MB Rhino test file is grown to a 2GB USD.

It would be nice if USD could be what FBX never achieved - a rock solid exchange format. Please tell us more about what is planned.

I was just about to explain how USD is a mesh based file format made by Pixar, but then I saw this:

https://openusd.org/dev/api/class_usd_geom_nurbs_patch.html

So now I’m curious. Is it theoretically possible to save CAD models in USD?

(STEP is otherwise generally the neutral exchange format for CAD models…)

Unfortunately, STEP only supports NURBS and not meshes. FBX would have supported both, but was not fully utilized.
So, if USD would finally support NURBS, meshes, instances, materials and layers, everyone should be happy.

It still will require target DCCs to actually be able to import such geometry.

I have seen really only meshes be actually used in Blender, Maya, 3dsMax, Houdini and Cinema4D USD support.

1 Like

I know I might be boring on this topic :slight_smile: but generally the fact that USD supports / will support many types of geometries can make it worse.

The fact that someone allow to write 1000 types of data into their file format doesn’t mean everyone will be able to read it or write in it. That in fact leads to the fact that later nobody knows what can be in this file, makes it much more expensive to write import/export to it and so on.

I don’t think I agree. Sure, not every software will be able to handle every file format feature, especially more exotic ones, but that is fine as long as most of the software can use most of the features. At least its an open standard. Every software that implements USD will still be able to read and write to it. It doesn’t make sense that a software would support USD, but not implement a feature it could read or write. Why wouldn’t they implement that? Sure there might be an aspect that another software has written, that another wont be able to read, because it cant use it anyways, but then there is no point in the software reading it. It could still write the things to the file that it maybe specialises in.

I would argue that building import/export support for lots of different file formats is much more expensive to build and maintain than good support for 1 file format.

We are actually using the Rhino file format in our software, because it can handle a lot of different types of data and is an open standard. We will likely make the switch to USD once there is feature parity for the things we use in Rhino. So if I can export a USD and open it in Rhino and get the same things as now with a .3dm file, it makes more sense to only support USD.

I know what you mean, and this is the argumentation I hear all the time, but it depends on what you are working on, and for me personally this approach doesn’t work at all.

It really depends on how reliable your importer can be for your task.

If you can deal with the fact that only some features are supported here and there: sure. But there are many file formats that cannot be fully supported, because they are complicated and allow a lot of types of data to put into, which makes the problem that you lose your data taking it from software A to software B by losing e.g. 20% of it, which makes it not that useful anymore.