Hi

I need someone to punch me in the nose on Solaris, Stages, and TOPs. I have thus far more or less stayed away from Solaris, Stages, and TOPs. They kind of confuse me, as to how they are suppoused to be used. Start with basics. Are Solaris, Stages and TOPs another version of Houdini separate from 'classic' Houdini with OBJ, ROP, COP, MAT? Or is Solaris workflow is supposed to be used with classic Houdini workflow?
Lets take PRManRIS ROP. In classic Houdini OBJ, all geometry and cameras need to have PRMan attributes. THat is handled by SpareAttr in Renderman24 tab in OBJ context. However I do not see the equivalent tool in Solaris. Importing from Obj context geometry, cameras and PRMAN lights, does work. But as soon as Renderman24 view is enabled , H19 crashes. There is no error message, application just pop quits.

Can an entire scene be done in Solaris , from SOP modeling to DOPs, Materials, and ROPs? Ignoring classic Houdini workflow.

Problem with YT videos is that they don't answer this basic question. THey just hype Solaris and TOPs, but don't explain where it all fits .

It's hard to give a simple answer because there's not a single way to work. But in the most general sense, solaris/lops is intended to replace the lighting and rendering part of obj (including spare parameters to describe render settings) with something more modern and powerful. Layout is another strong candidate because the referencing and override workflows are much improved in lops compared to obj. The main thing is that lops isn't really a rigging/animation context. So for that kind of work it probably still makes sense to import obj into lops.

Tops is its own thing and basically an improved version of rops, more or less. The uses for sops, dops, mat, cops etc doesn't really change with Solaris.

Whether or not an entire scene can be done without obj depends on what you're trying to do. If you're trying to animate a character then no. If you're building a scene with minimal animation it should be possible, bugs aside like with your crash experience.

Dave_ah
Importing from Obj context geometry, cameras and PRMAN lights, does work. But as soon as Renderman24 view is enabled , H19 crashes

If you have an example for us to look at, that might be useful. I tried creating an ultra-simple scene in /obj including a few RenderMan light objects, bringing it into Solaris via SceneImport, and switching the viewport to RenderMan (24.4) RIS, and it's working for me.

If the issue only occurs when switching the viewport to RenderMan, it'd probably also be worth asking on Pixar's RenderMan for Houdini forum.

The crash was due to improper launch of H19 at facility, to facilitate remote work. H19 py3 was launching, but PRmanRIS24.4 is PY2. H19 py2 has to be launched. H19py3 was launching, becouse lic server (remote) was picking up next available lic (which was PY3)and assigning that to me. Some dark magic on part of IT and now I have H19py2 launching . Facility's standard render engine is Arnold.
Thank you to all who replied. I think complexity in Houdini has gotten out of hand, gone off the rails. Its too much. There is duplication of function in multiple locations, thus workflow is highly inconsistent from facility to facility. Which manifests itself in worst way when trying to pickup existing setups from previous FX TD's.

So with scene import. SHould cameras and lights be imported as well. Since primary purpose of Solaris is large scene layout (via USD, ABC, or Arnold StandIn) it stands to reason that lights from OBJ context are ignored , and fresh lights (regardless of render engine)be created. Cameras from matchmove are normally FBX , to be brought in Stage context. For layout USD archives be brought into Stage/LOP , bypassing OBJ context.

Dave_ah
I think complexity in Houdini has gotten out of hand, gone off the rails. Its too much. There is duplication of function in multiple locations, thus workflow is highly inconsistent from facility to facility. Which manifests itself in worst way when trying to pickup existing setups from previous FX TD's.

It's the price of innovation unfortunately I think. Even if obj were totally redundant (which it isn't) it would have to stick around otherwise older files would be broken. Kinks will get ironed out and streamlined with each version as well.

As for different studios, workflows and tooling will always be different. They're constructed by different artists and td's with a variety of opinions and skill sets. The best we can hope is that the foundational components like alembic, usd, openexr, vdb etc and even houdini itself make for an easier ride. It wasn't so long ago that none of those things existed and literally everything was proprietary for the big studios and super hard if not impossible for the smaller ones.

Dave_ah
So with scene import. SHould cameras and lights be imported as well

That's really up to the user

We provide a "Filter" parm on SceneImport to specifically target Geometry (or Cameras or Lights or everything) if that workflow is the most natural fit for what you're trying to achieve.

For many, SceneImport is a useful gateway into Solaris where they have a fully setup scene in /obj and just want to dip their toes in the USD waters with minimal effort, so the translation of everything in one node can be appealing.