NOT SOLVED YET :
the solution i found , not works if the previus asset has scale transformations too.
I will make another post flagging this error , with better info and explanation.
If you check on the toogle "local transform" , it fix the problem

Short Summary

Stage Manager becomes unusable if assets already have transforms. This makes it impossible to use Stage Manager reliably in layout and set dressing, breaking the most common USD workflows. The problem has existed since 20.5 and is still present today.

Detailed Explanation
Why this matters

Solaris is designed to be a complete USD workflow, from asset creation to final render. But right now, the Stage Manager — which should be the central node for layout and set dressing — only works once. As soon as you try to reuse it downstream on assets with pre-existing transforms, pivots and transforms break.

This is a show-stopper for production pipelines. Both small and large studios hesitate to adopt Solaris as their base pipeline because of this limitation. Without a reliable Stage Manager, teams are forced into awkward workarounds (dressing in SOPs with point imports, or building in-house tools) instead of using Solaris as intended.

Steps to reproduce (3 simple cases)

Case 1

Create a test rubbertoy in Solaris.

Apply scale/rotation/translation.

Add Stage Manager → move or duplicate → transforms break.

Edit LOP works correctly in the same situation.

Case 2

Create rubbertoy.

Add Stage Manager → move/duplicate/rotate.

Add another Stage Manager → pivots/positions become corrupted again.

Edit LOP still behaves correctly.

Case 3 (real production scenario)

Layout department publishes blocking with Stage Manager (placing assets, variants, transforms).

Set dressing department loads that opinion and tries to refine or duplicate assets.

Stage Manager fails — transforms break because layout already added transforms.

Result: impossible to refine layout with Stage Manager in set dressing.

Why fixing this is critical

Stage Manager should be the main tool for layout and set dressing in Solaris.

Without it, Solaris cannot be used as a full USD pipeline.

Forcing workarounds discourages adoption: some studios move dressing to SOPs, others avoid Solaris altogether and stick with Maya.

Fixing Stage Manager would unlock Solaris as a robust USD pipeline tool, not just a lookdev and rendering playground.


Attachments

.hip file demonstrating the bug

Video showing the issue step by step



Do you also encounter this issue in production? I’d love to hear your experiences — the more visibility this gets, the higher the chance of a fix.

Thanks!!!!
best regards!!