Export with Catmull-Clark is nearly 3 times smaller

[Xaia]

Describe the bug Not sure what is happening here. I am exporting pretty dense mesh for Omniverse and version with Catmull-Clark on is nearly 3 times smaller than Polygonal Mesh. Any ideas?

Steps to reproduce Steps to reproduce the behavior:

1. Grab dense mesh from zbrush
2. Export with and without catmull-clark subdivsion method

Expected behavior I would expect the file size to be similar

Attachments

Specs (if applicable):

• Windows 10
• Maya 2022.3
• Maya USD 0.14

[swillisart]

Hey! So It is not possible to get them to the same size because of what polygonal data each of those options will translate into the file.

Enabling Catmull-Clark will always result in a smaller USD file. What happens and why is the exporter does not encode each meshes vertex-normals. In the workflow the mesh would be intended for subdivision (smoothed) so normals are not needed because using subdivision will calculate new averaged normals on-the-fly in the render.

In game engines with the constraints of polygonal limits meshes with encoded vertex-normals are ideal as it would be expensive to calculate them over and over for each mesh on load. So naturally they are written (Cached) into the file.

In offline raytracing renders they have more resources to work with and in that workflow the mesh would be designed to be subdivided and smoothed. They have either creases to control edge hardness / softness, fine displacement or simply are modeled so that the subdivisions are dynamically creating the desired result.

TDLR: Polygon surfaces intentionally contain more data for realtime engines and thus larger files.

[Xaia]

Hey! So It is not possible to get them to the same size because of what polygonal data each of those options will translate into the file.

Enabling Catmull-Clark will always result in a smaller USD file. What happens and why is the exporter does not encode each meshes vertex-normals. In the workflow the mesh would be intended for subdivision (smoothed) so normals are not needed because using subdivision will calculate new averaged normals on-the-fly in the render.

In game engines with the constraints of polygonal limits meshes with encoded vertex-normals are ideal as it would be expensive to calculate them over and over for each mesh on load. So naturally they are written (Cached) into the file.

In offline raytracing renders they have more resources to work with and in that workflow the mesh would be designed to be subdivided and smoothed. They have either creases to control edge hardness / softness, fine displacement or simply are modeled so that the subdivisions are dynamically creating the desired result.

TDLR: Polygon surfaces intentionally contain more data for realtime engines and thus larger files.

That explains everything. Thanks. Closing the issue.