What aspects of USD are or will be supported?

Rhino
,
1

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!

2

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?)

3

Isn’t it import only?

4

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

image
image1759Ă—953 97.9 KB

-Jakob

1 Like
7

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
8

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.

9

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…)

10

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.

11

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
12

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.

13

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.

14

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.

15

And what do you mean by that? Leave half of it out because the user couldn’t handle it?

If someone exports NURBS and their import program can’t use NURBS, then the interface shouldn’t support NURBS in general?

It goes without saying that you should think beforehand about what you are exporting and whether the recipient can use it. I hope we stay on a professional level. :wink:

16

USD supports a feature called “variants” which let you write different variations of the same geometry. This is something we haven’t implemented yet in our exporter, but it potentially would let us write both NURBS and mesh variations of a piece of geometry and let the application that reads the geometry choose which level of fidelity it can support.

4 Likes
17

Yes. Limiting file format to mesh only (cause NURBS still can be converted to a mesh) makes it possible to get 3d scene 100% correct much easier, because you can later import only meshes and still get the whole scene. Once you allow having various different geometry types - it’s not that easy anymore to support all of them in a correct way. That’s why mesh formats are superior in comparison to procedural geometry formats in terms of reliability.

But as @stevebaer explained (I didn’t knew that) - they have a feature to save the same 3d geometry as a mesh AND as something else separately. This feature may lead to much more reliable communication, cause if someone won’t support NURBS, then he could get still its mesh representation during import.

18

@w.radaczynski Interesting that you decide what is needed here. My customers primarily want NURBS, I will tell them. :wink:

@stevebaer Please allow the choice of NURBS + meshes if needed only. My scenes are very complex and saving data twice (NURBS + meshes of the NURBS) in the file would not be helpful.
For example, my scenes are train interiors based on NURBS with many blocks supplemented by a few purchased mesh objects to enrich the scene. The size is between 1…2GB.

19

@Micha is there an application that you are using that supposedly can read NURBS from USD?

1 Like
20

I will ask my client who ask me for USD.

21

There are no programs which can display NURBS in USDZ yet. Definitely not apple’s viewer. They can display quadmeshes with smooth shading though.

If you allowed a loaded to choose to display NURBS or mesh you wouldn’t want to have the material twice in the USDZ file also, so either need to use only basic shader materials (no PBR) or wait for the day a universal procedural materials shader is created.

22

Hello, is there a way to import usdz files into rhino 8?