Hi, LOPs scrub here.

Let's say I have some Alembic data that I want to write out as USD and then load into LOPs. This works fine. When I look at the scene graph after importing with a Sublayer LOP, I see Xform and Mesh primitives, with Meshes as the children of Xforms in a nice hierarchy, exactly like I'd expect.

However, if I want to edit those transforms, LOPs isn't reading the pivots correctly, even if I switch the pivot mode from the default "centroid" (this really should not be the default!). If I select the underlying mesh node and my Pivot Mode is "transform", the pivot is correct, however, the meshes don't have children, making the whole hierarchical nature of the transform useless. Why even have the Xform nodes in the scene graph, then?

If I instead load the ABC file directly into LOPs, the scene graph shows nothing but Mesh nodes, and the hierarchical transforms work. This is great, but why doesn't it work with USD files and Xform primitives?

Edit: I imported this USD I generated from the Alembic into Maya, and the transforms are screwed up here, too... the "Shape" nodes that were classified as "Meshes" have the correct transforms and pivots, but the nodes originally classified as "Xform" nodes are all located at the origin. So the issue is likely somewhere in the writing of the USD file from this source Alembic, but I can't figure out exactly where.

Okay... crawled some other threads here and apparently the only way to prevent the non-mesh-containing transforms from getting screwed is by setting an environment variable, USD_ABC_XFORM_PRIM_COLLAPSE=0.

I don't know why anyone thought mucking with exported hierarchies would be a good default setting to have, but I guess this is the solution.

This seems to catch some people out... perhaps SideFX can/should compile Solaris' USD with the default to not collapse?

If they did that, mixed pipelines could be in a ton of trouble... this is on USD, not Houdini's implementation of it. It's just such a weird decision to interfere with transforms like this by default.

toadstorm
If they did that, mixed pipelines could be in a ton of trouble... this is on USD, not Houdini's implementation of it. It's just such a weird decision to interfere with transforms like this by default.

I think there's a performance/memory cost associated with each prim in the hierarchy. Concatenating the mesh with it's parent transform saves saves that cost.

I think they default to USD_ABC_XFORM_PRIM_COLLAPSE=0 at my current studio so stuff matches name-wise with other packages.

toadstorm
If they did that, mixed pipelines could be in a ton of trouble... this is on USD, not Houdini's implementation of it. It's just such a weird decision to interfere with transforms like this by default.

Pipelines could still set this value to be whatever sense they need it to be; I was only suggesting a default flip for Houdini's build of USD - not a hardcoding, assuming that for typical lookdev and lighting processes, having a deterministic primpath is worth the overhead of memory and compute of the full hierarchy of prims. I wonder if the primary motivation for this is to aid realtime playback?

FWIW, I have no horse in this race; we don't use alembic for anything except for some more fringe workflows and some vendor I/O. If we did use Alembic as a core file type and pulled it into Solaris, we'd invariably set COLLAPSE to zero too. In fact, we might just do this defensively anyway.