H21 introduced a lot of very practical updates to Solaris, which is fantastic to see. However, the layout-related tools still feel quite underdeveloped compared to the rest of the ecosystem.

Stage Manager is a step in the right direction, but it currently has some issues that make it difficult to rely on in production. For example:

Copying multiple selected objects in the list sometimes fails or even causes a crash.

Using Labs → Reset Viewport can trigger a series of error popups.

There’s no option to replace assets directly.

The Layout tool itself also seems to have regressed in H21, with more bugs appearing. The overall concept of this tool is excellent and clearly valuable, but after several years it still hasn’t reached a production-ready state. This feels unusual in the Houdini ecosystem, where tools typically mature into very solid solutions.

Given how much feedback and how many suggestions have already been shared by the community, I’m curious if there are plans for a more significant update to these layout tools in the near future. They have a lot of potential, and many of us would love to see them become stable, dependable parts of the pipeline.

I stick with the reference, transform, and duplicate nodes. I haven't bothered trying the stage manager. It seems counter to proceduralism.

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

Year after year, the same question remains: when will we finally see a layout toolset that’s truly production-ready?

Thanks for bringing this up. We've been working hard to bring the layout tools up to the customers expectations. A good chunk of the previous 2 dev cycles have been dedicated to making these better, and we will continue to to spend time on these tools. Based on initial reports, the Layout LOP had issues with the editing brushes, causing assets to randomly change while using say, the scale brush. These issues have been fixed in 21.0.478. If you could point us to existing bug reports or create new ones pointing to other specific problems, we shall have them looked into ASAP.

For the Stage Manager, version 21.0.474 takes care of the crash while re-parenting/copying multiple prims. We are working to make the handling of transforms better in the Stage Manager, and will be updating users soon. Apart from these, are there specific problems you'd like to share?

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.

vijinr@sidefx.com
Thanks for bringing this up. We've been working hard to bring the layout tools up to the customers expectations. A good chunk of the previous 2 dev cycles have been dedicated to making these better, and we will continue to to spend time on these tools. Based on initial reports, the Layout LOP had issues with the editing brushes, causing assets to randomly change while using say, the scale brush. These issues have been fixed in 21.0.478. If you could point us to existing bug reports or create new ones pointing to other specific problems, we shall have them looked into ASAP.

For the Stage Manager, version 21.0.474 takes care of the crash while re-parenting/copying multiple prims. We are working to make the handling of transforms better in the Stage Manager, and will be updating users soon. Apart from these, are there specific problems you'd like to share?

please check this post.

https://www.sidefx.com/forum/topic/89500/ [www.sidefx.com]

https://www.sidefx.com/forum/topic/94066/ [www.sidefx.com]