Skip to content

Fix worldspace export baking ancestor transforms twice - #4699

Merged
antonkhelou merged 1 commit into
Autodesk:devfrom
paulgolter:pgolter/fix-worldspace-with-export-roots
Aug 19, 2026
Merged

Fix worldspace export baking ancestor transforms twice#4699
antonkhelou merged 1 commit into
Autodesk:devfrom
paulgolter:pgolter/fix-worldspace-with-export-roots

Conversation

@paulgolter

Copy link
Copy Markdown
Contributor

Problem

Exporting with -worldspace produces wrong transforms when the selected
objects have ancestors that are also exported. This happens in two common
setups:

  • -exportSelected with -exportRoots pointing at an ancestor of the
    selection.
  • -exportSelected with a node deep in a hierarchy (its parents are
    always exported with their transforms).

In both cases the ancestor transforms end up in the file twice. They are
written on the ancestor prims, and they are also baked into the xform ops
of every selected prim. When the file is composed, the objects move twice
as far, scale twice, and so on.

image

Repro

# group1 at translate (5, 0, 0), pCube1 under it at translate (0, 2, 0)
cmds.select("pCube1")
cmds.mayaUSDExport(file=path, selection=True, worldspace=True)

The cube lands at world position (10, 2, 0) instead of (5, 2, 0).

Cause

needsWorldspaceTransform in transformWriter.cpp enables the ancestor
bake for every transform found in the export selection (dagPaths). That
is only correct when the selected node becomes a root prim of the file.
The existing worldspace tests only cover exports without a selection,
where dagPaths happens to hold the export roots, so the problem never
showed up there.

Fix

Bake the ancestor chain only into prims that become top-level prims of
the exported file. A prim is top-level when its Maya parent maps to no
prim in the export, either because the node sits under the Maya world
root or because the export roots exclude its parent.

This matches what the existing selNone worldspace tests in
testUsdExportRoots.py already assert: the bake lands on the export
root itself, and prims below it keep their local transforms.

As a side effect, transforms above a non-top-level export root are now
captured on the export root prim instead of being double-applied below
it.

Tests

Two new cases in testUsdExportRoots.py:

  • testExportRoot_rootMid_selCube_worldspace — export root above the
    selection. Fails without the fix (double transform), passes with it.
  • testExportRoot_rootCube_selCube_worldspace — the selected node is
    itself the export root. Guards that the bake stays where it is needed.

All existing testUsdExportRoots and testUsdExportRootsAndRootPrim
cases pass unchanged.


🤖 Generated with Claude Code

The worldspace flag baked the Maya ancestor chain into every selected
object. When those ancestors are also exported as prims - via exportRoots
or as parents of a deep selection - their transforms ended up in the file
twice: once on the ancestor prims and once baked into the selection.

Only bake the ancestor chain into prims that become top-level prims of
the exported file, i.e. prims with no exported parent above them. This
matches the behavior the existing exportRoots worldspace tests assert,
where the bake lands on the export root itself.

Added two tests covering worldspace with a selection: one where the
export root is an ancestor of the selection (previously double
transformed) and one where the selected node is itself the export root
(bake must stay).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

@pierrebai-adsk pierrebai-adsk left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good job!

@pierrebai-adsk pierrebai-adsk added the bug Something isn't working label Aug 14, 2026
@barbalt barbalt added the ready-for-merge Development process is finished, PR is ready for merge label Aug 14, 2026
@antonkhelou
antonkhelou merged commit 1e26db0 into Autodesk:dev Aug 19, 2026
13 checks passed
@seando-adsk seando-adsk added the import-export Related to Import and/or Export label Aug 19, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working import-export Related to Import and/or Export ready-for-merge Development process is finished, PR is ready for merge

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants