Jacobo Sanchez de la Villa

vijinr@sidefx.com
21.0.474

First of all, thank you so much for your work, the support you provide is incredible!! Congratulations.

I’m the one who has been reporting the issues related to the “crash while re-parenting/copying multiple prims.”
I’ve been checking version H 21.0.474, and those errors are now fixed.


IMPORTANT:

However, there is still a strange behavior/bug that, if you were able to solve it, would fix what I personally consider the biggest problem of Solaris when trying to work on a full pipeline involving multiple departments inside it.( be able to make full layout and manual dressing in solaris viewport --- using stage manager )

In short:

The problem is that if an asset has a previous transformation (including a scale change), when you use a Stage Manager, for example, to transform or duplicate that asset and move it, the transformation and the pivot go crazy. making this node useless if you want to use it by different usdlayers.
In the attached video A, you can see what I mean.

I uploaded a videoB too
, with the same behavior with 2 stage manager nodes.with a simple example.




Why is this so important?
Because it prevents the use of multiple Stage Managers within the same USD. And this limitation makes it impossible to properly use Solaris at each stage of the pipeline in a real production.

Example 1)

Several assets have been created and published by the modeling and surfacing departments for a sequence of 3 shots.

The layout department uses a Stage Manager to load those elements and position them in the scene, scaling, transforming, and duplicating them, in order to publish a sublayer called layout_env_blocking, where the environment blocking pass is worked on (still without working from camera).

In another step within the layout department, once the blocking is approved, the goal is to work on that environment blocking from camera, refining positions and duplicating or relocating things so they look better from the different cameras.
To do this, we would load the layout_env_blocking sublayer and create three branches in Solaris: shot01, shot02, and shot03.
What we need and want is to be able to use another Stage Manager at this point—ideally a different one for each shot_camera—to perform step 2 of layout from camera, adjusting the blocking we already had and adding more detail from the camera’s point of view.
For this we would use another Stage Manager that reads the previous elements and allows us to move them again, transform them, duplicate them, or add new ones.
The problem is that with the bug/behavior shown in video A, this is not possible. Since the assets already have previous transformations, the Stage Manager in shot01 does not behave correctly, and we see the broken behavior shown in video A.

Fixing that behavior would allow us to work full pipeline inside Solaris, since the Stage Manager is the main tool to be able to do layout in the viewport precisely (the Layout node is less precise).

Example 2
of using Stage Manager in a real pipeline:

I work at a company where we had to develop an alternative solution to Stage Manager because of these problems.

In this company there is a layout department and a set dressing department. The set dressing department works from the USD published by layout, which contains the blocking pass and the cameras.

If layout uses a Stage Manager to place elements in the scene, transform them, duplicate them, etc…

When we then load that sublayer in order to work on top of it—putting a new Stage Manager to edit the layout, change variants, move them, etc.—the error shown in the video appears.

CONCLUSION:

If the Stage Manager could fix the behavior shown in the video, and be able to read the previous transformations of the assets while still allowing us to edit transformations, change variants, duplicate, and add new elements (which it already can, except for the bug), that would give the green light to work layout and set dressing fully in Solaris USD within Houdini.

If I haven’t explained myself well or you have any questions, please don’t hesitate to ask—I’m very interested in seeing this solved or improved.
At first this comes from my personal/home projects, but it would also be very good news for the company where I work, which uses Solaris and USD across multiple departments in the pipeline.



attachments :
videoA - bug
videoB - another bug example
hip file with production tests examples , to show who important is the stage manager will be fixed.

Best regards, and thank you so much.

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!!

I love proceduralism, but I think it’s very important that a node like the Stage Manager is actually usable. In a real production, and when using USD, the director, PDs, etc. will always want a layout and set dressing that follow an artistic distribution with a manual base. Of course, always supported by a workflow that is as non-destructive as possible. For example, making a large part of the set dressing procedural starting from that layout or key elements placed manually in a compositional way with the Stage Manager.

With H 20.5 I reported a bug that is still unresolved to this day. And it’s a problem that breaks any kind of USD workflow in real production, unless you either do the dressing in SOPs, or the company develops its own usable Stage Manager.

The bug is that once you use a Stage Manager, you can’t use another one afterwards, either to duplicate another element or to edit the position or transformations of those elements. The second Stage Manager simply goes crazy with pivots and transforms. This is more serious than it seems because it breaks a real USD workflow. For example, in the layout stage we place some elements, duplicate them, etc., and then write a layout sublayer. Afterwards, the set dressing department would take that sublayer and should be able to edit it, add the dressing blocking from layout, but when adding another Stage Manager, the bug appears. When editing positions with a new Stage Manager, even if a previous sublayer has been written, the pivots and transforms go haywire.

This makes it impossible to compose shots in Solaris, which is vital for building sequences or real workflows in a pipeline. This week, with more time, I’ll create a new post with a hip file and report the bug again. Many of us are fighting to get the companies we work for to adopt Houdini and Solaris USD in their pipelines, because they’re incredible, but this bug makes it impossible to work in a pipeline—at least for layout and set dressing.
Cheers