Alembic plugin: Optionally disable parent-xform-as-mesh behavior

[ablev-dwa]

Description of Change(s)

When reading an Alembic file, the generated USD Prim hierarchy is currently affected by the structure of the Alembic file itself. In cases where the Alembic hierarchy consists of an Xform with a single geometry or camera, like so:

/Xform xformNameA
    /Subd geomNameB

The generated USD Prim hierarchy looks like this:

/Mesh xformNameA

However, if the Alembic hierarchy has an Xform with two or more geometries or cameras:

/Xform xformNameA
    /Subd geomNameB
    /Subd geomNameC

The USD Prim hierarchy maintains the same structure as the Alembic hierarchy:

/Xform xformNameA
    /Mesh geomNameB
    /Mesh geomNameC

This is problematic in a pipeline that expects assets to maintain a consistent Prim hierarchy regardless of their contents.

This change adds a control, USD_ABC_XFORM_PRIM_COLLAPSE, set to true to maintain existing behavior, that when set to false will maintain the Xform -> Prim hierarchy in all cases.

[jtran56]

Filed as internal issue #161888.

[spiffmon]

Hi Alan! We're looking to accepting this PR shortly; one thing I'd like to point out, which is completely undocumented, is that TfGetEnvSetting() is protected by a std::mutex, so by adding a call to it in _ReadPrim(), we're potentially introducing contention if Alembic files are being opened simultaneously in multiple threads. (We should have made this same observation for the change that introduced USD_ABC_WRITE_UV_AS_ST_TEXCOORD2FARRAY, which we should fix).

What I'd suggest is adding a member flag to class _ReaderContext, which gets initialized in its ctor, then _ReadPrim() can just consult that flag.

Cheers,
--spiff

[spiffmon]

Please ignore my prior comment, Alan - I was looking at the wrong version of TfGetEnvSetting - what you have should be fine - no changes necessary!

Sorry about that!
--spiff