Looking for help in better understanding vertex ordering regarding to Houdini and USD export. The documentation for usdexport SOP seems to be in conflict from other bits I've been reading.

Here's what I think I know -

1. Houdini geometry uses a right-handed coordinate system and right-handed vertex ordering by default.
   
2. USD uses a right-handed coordinate system and right-handed vertex ordering by default.
   
3. Substance Painter uses right-handed coordinate system and right-handed vertex ordering by default.
   

The usdexport SOP documentation [www.sidefx.com], under the "Reverse Polygon Vertex Ordering" parameter section seems to be in direct conflict with the above as it states,

USD supports an orientation attribute on mesh primitives that indicates whether polygons have a left-handed or right-handed ordering, while SOP geometry is always left-handed ordering.

When exporting USD from Houdini and importing into Substance Painter, I need to have

Reverse Polygon Vertex Ordering

ticked or my normals are flipped in the wrong direction.

My guess would be that the usdexport SOP documentation is incorrect AND Substance Painter isn't interpreting the right-handed, Solaris exported USD correctly. That or one of the three solutions (Houdini, USD, SP) listed above are actually not all right-handed.

Any clearing of the air would be helpful and appreciated. Thank you.

The usdexport sop documentation is correct. SOP coordsys is left handed and vertex order is left handed. By default when importing SOP geometry to USD, the order is left unchanged and the orientation attribute is set to indicate the handedness. Checking the Reverse Ordering checkbox will reverse the orientation of the geometry on import and the handedness will be indicated as the canonical right handed. Most likely, substance painter is ignoring the orientation metadata and assuming the geometry is right handed.

Thank you for the clarification. I was struggling a bit yesterday and didn't fully grasp that a coordinate system (left vs right handed) was not the same thing as vertex winding order.

Compounding that with my huge mistake of using ChatGPT for the first time in an attempt to figure some of this stuff...

I ended up mapping out what I think is an accurate map of some of the target software I'm working with. For all of the targets, I'll need to reverse vertex ordering. Thank you for the reply.

krause_trk
For all of the targets, I'll need to reverse vertex ordering. Thank you for the reply.

You in theory shouldn't need to use reverse vertex ordering, since as mentioned it's recorded as a metadata on the mesh, so every DCC should be able to load your mesh properly regardless of how it's stored
If it doesn't it's most likely an oversight on particular DCC importer end, so then yes you may be forced to switch how it's stored, bit you should also submit bug for DCC that imports it wrong

tamte

krause_trk
For all of the targets, I'll need to reverse vertex ordering. Thank you for the reply.

You in theory shouldn't need to use reverse vertex ordering, since as mentioned it's recorded as a metadata on the mesh, so every DCC should be able to load your mesh properly regardless of how it's stored
If it doesn't it's most likely an oversight on particular DCC importer end, so then yes you may be forced to switch how it's stored, bit you should also submit bug for DCC that imports it wrong

I did see a "lefthanded" vs "righthanded" ordering tag in some test .usda files I was inspecting. You aren't wrong, other software should be able to interpret this.

Adobe Substance Painter had issues w/ interpreting vertex ordering (will submit a ticket).

Cinema4D requires that the normals be "Indexed Attributes" or else the normals just get dropped (other software does not seem to have this requirement).

Keyshot does not support cameras in USD (Keyshot it an outlier anyway for our industrial designers)
For the most part, neither Blender nor Cinema4D seem to be able to bring in any arbitrary primvar attributes...

I'm finding that USD isn't as Universal as I initially hoped it would be. It's a step in the right direction at least. Hopefully other software developers wake up a bit and make it more of a priority to implement.

Thank you for your replies.

krause_trk
Cinema4D requires that the normals be "Indexed Attributes" or else the normals just get dropped (other software does not seem to have this requirement).

I don't believe USD supports normals as indexed, they're always per vertex or per point. When I force them to be 'indexed' on the SOP import, it doesn't create normals and instead imports them as a primvar which causes it to be ignored for purposes of shading.

I don't know a lot, but I do know that to get normal tags to populate correctly, inside of Cinema4D (specifically), I need to configure my USD Export to include this -



Blender doesn't require this nor does Keyshot.

krause_trk
I don't know a lot, but I do know that to get normal tags to populate correctly, inside of Cinema4D (specifically), I need to configure my USD Export to include this -



Blender doesn't require this nor does Keyshot.

That's odd. Doing that breaks the normals attribute for Karma and HoudiniGL views.