Maya usd plugin does not export primitive e.g. cube, cylinder

[chloe5608]

System Information (OS, Hardware, etc.)

MacOS

Package Versions

vfxpro99/usd-build-club

Build Flags

Steps to Reproduce

1. After install use plugin for maya 2017 properly, and load pxrUsd plugin.
2. Create a cube by clicking on the Polygons->Polygon Cube
3. Select cube and File->Export Selection...
4. Change file of type: pxrUsdExport with default Options (checked Export UV, Export ColorSets, ExportVisibility, Merge Transform and Shape Nodes) and change the file name with .usda as extension
5. Export.
6. Open the exported file in text editor. 1) The file is not identifying the cube as primitive. 2) the exported mesh is missing normal information.

[amooty]

Filed as internal issue #140786.

[spiffmon]

Hi Chloe, Maya's primitives aren't really intrinsically parameterized primitives, they are general meshes on which any number of modelling operations may have been performed by the time we are asked to export them, so I'm not sure how we could know when it was "safe" to export them as UsdGeom intrinsic prim types.

It does look like we aren't emitting normals, though, even when "Default Mesh Scheme" is set to "Poygonal Mesh" (we intentionally do not emit normals when exporting meshes as subdivs).

[chloe5608]

Thanks spiffmon!

One way I could think of to determine whether a primitive stays as primitive is to check the if the primitiveShape is directly connected to the primitive. i.e. polyCube1 should directly connects to pCubeShape1 if no other operations (such as polySplit) is performed on it. In this case, polyCube remains as primitive when export to Usd.

[spiffmon]

I think even that check is insufficient... I have "interactive creation" mode turned on, and when adding a "cube", I sweep out its cross section, and then get to independently determine how tall it will be. So it's a single primitive with no edits, but it's a general rectangular box. I'm not sure how kosher it would be to transform that, on output, to a Cube primitive with a non-uniform scale applied (assuming we can recognize from the Maya data that that's what is needed)?

Our thinking in providing the intrinsics was that they would be useful primarily in three areas: 1) For simple scenes and didactic purposes 2) For simulators that want to represent efficient volumes and colliders 3) Instancing lots and lots of simple shapes (e.g. with a PointInstancer)

[chloe5608]

I see, thanks for exlaination. As for emitting normals when exporting mesh, I get that when exporting mesh as subdiv, we do not want normals. However, if we want to export just polygonal mesh, I think in the most case we want normal? Should I file this separately since it's not related to the primitive anymore?

[spiffmon]

I just (re)discovered that this is operating as advertised - to get normals emitted, we currently not only require the subdivision scheme to be "Polygonal Mesh", but each mesh must have the USD_EmitNormals attribute authored on it (http://graphics.pixar.com/usd/docs/Maya-USD-Plugins.html#MayaUSDPlugins-MayaAttributesThatGuideUsdExport).

I think this is probably too cumbersome for non-subdiv-based pipelines (though we are trying to be subdiv evangelists :-) . I've started an internal discussion about this, but feel free to file another Issue it you'd like to add more context/argument!

[chloe5608]

I also noticed that when importing an empty primitive into maya such as:

usda 1.0

def Capsule "MyCapsule" { Vec3f[] extent = [(-1, -1, -1), (1, 1, 1)] custom Matrix4d xformOp:transform = ( (1, 0, 0, 0), (0, 1, 0, 0), (0, 0, 1, 0), (0, 0, 0, 1) ) uniform token[] xformOpOrder = ["xformOp:transform"] } Maya does not generate a mesh or a node on the outliner. If I understood it correctly, it should show a dummy node on the outline without mesh?

[spiffmon]

Hi Chloe, Although it hasn't gotten pushed to github yet, we just fixed the issue of normals not getting automatically exported for polygonal surfaces, so better behavior on that front is on the way.

I don't believe the importer is currently making any effort to handle any of the "intrinsic" prim schemas on import. It's not entirely clear what the best thing to do with them is (given the motivation I described earlier for including them in the first place), but please feel free to file a new issue that begin that discussion.

[sunyab]

This was addressed with commit c8c551cbe893f825505d8245cafdb5ef71fdf7cb, which has been merged into release 0.7.3.