Hi guys

We just finished a feature with 1700 cg shots in Clarisse.
Now actively looking for an alternative.
Looking at all the possibilities in Houdini makes me dizzy. Right now I am trying to see how to funnel all the possiblities to replicate the Clarisse workflow ( assets creation, scattering...etc) as a first step. Looks like Solaris / Stage workflow might be closest to what we had in Clarisse ( i know i know in houdini you can do much more) .... but since Houdini is such a beast (and I hear that sidefx is constantly inventing or re-inventing new tools) any info like "don't go down this route...its depricated and x is much better" would be aprecciated

Thanks in advance for any tips and thoughts.

Andras

for layout and scene setup Solaris (/stage) is the way to go as you have seen.
the difference to clarisse is Solaris supports multiple Render Engine where each one has it's own Shader Network. that should change with mtlx but still a progress.

Old stuff in Houdini: /ROP /shop /ch /img
ROP is the old way of rendering with Mantra it is EOL and in the future i guess it will be removed.
SHOP is the old Shader Network it gets replaced with MAT
CH still there for Signal Data / Audio Processing not sure what Sidefx has in mind to update it.
IMG is for 2D Image Compositing there are some rumours for a new Compositing System. (https://sidefx.bamboohr.com/careers/90)


Tutorials for Solaris:
https://www.sidefx.com/learn/solaris-karma/ [www.sidefx.com]

Thank you for the tips )

We modeled our assets in dcc's like Maya and Modo and brought them into in its own clarisse project, applied materials...made combiners ....and then referenced in those project files into our layout scenes. pretty straight forward.

Correct me if I am wrong, but from highlevel... : import geo into houdini, apply karma materials (do variants) and save USD, reference the USDs into the Solaris/Stage and do the layout.

Sorry for the houdini noob sounding qeustion. But does it mean the new (Solaris way) assets are not saved in native houdini files (hip, hda..) but rather in USDs?
I am tyring to keep it as simple as possible ))

andraskavalecz
Thank you for the tips )
We modeled our assets in dcc's like Maya and Modo and brought them into in its own clarisse project, applied materials...made combiners ....and then referenced in those project files into our layout scenes. pretty straight forward.

Correct me if I am wrong, but from highlevel... : import geo into houdini, apply karma materials (do variants) and save USD, reference the USDs into the Solaris/Stage and do the layout.

i would say that is the way how you will work mostly with houdini in Solaris to get a near clarisse feeling. there is the classic way of working in SOP (/obj) and then load the geometry in solaris because before solaris everything was in SOP and then rendered with some nodes in ROP. you can also do it in the classic way, end of the day you must be happy

andraskavalecz
Thank you for the tips )
Sorry for the houdini noob sounding qeustion. But does it mean the new (Solaris way) assets are not saved in native houdini files (hip, hda..) but rather in USDs?
I am tyring to keep it as simple as possible ))

simple as possible and that with houdini? I like your thinking
very good question far far above noob level!

Project file are still for houdini the .hip but you can export the solaris graph data to USD (.usda -> ASCII to analyse what is inside / USD ROP). Functionality Tools are inside Houdini and currently there is no USD way to build something like a HDA. But that could maybe change in the future. Houdini way of working is always reference the files and never embed it into the hip file. NEVER...

currently sidefx has made some move to have parameters information and node network in the geometry data (APEX thing). this is still new and it will take time how the artist can use it in production. it also means for the future one data format for CPU, GPU Functions and no dependency for the houdini core HScript.
Fun Stuff: Houdini core is inspired by UNIX so it means there is a right management where you can set permission to nodes as in the unix world (https://www.sidefx.com/docs/houdini/commands/opchmod.html). but I think all that will be removed and don't used it in production bosses don't like it (didn't happen to me but read it somewhere studio department bosses can get angry).

In the interest of full disclosure here, you may want to check out the Solaris forum to read up on other people's experiences with the Stage Manager and Layout LOP. I remain convinced that real, useful work can be done with these tools, but I also have to admit that they are not where we (or many users) want them to be. But we are working on it. In the next major release of Houdini the Stage Manager is getting a major revamp in terms of both the parameter pane UI and more importantly the viewport based workflows. The layout LOP has seen some bug fixes since the H20 release, but major improvements to that node will have to wait until the Houdini release after the next one.

Using SOP based workflows in conjunction with the Instancer LOP is also an excellent option for some scenarios (especially more procedurally driven environments), but that workflow will be less "Clarisse-like". than working directly in Solaris. Also the next release will include a couple of big improvements for these SOP based workflows too.

As for a meta-level description of how to build scenes in Solaris, I would strongly recommend splitting the process of asset creation from scene assembly. The bridge between these two workflows will be USD files describing each asset. I would guess from what I've heard from other studios that this division is probably similar to what you were doing in Clarisse. But it does remain a useful division. Although you _can_ dump everything into a big hip file or use HDAs to define your assets, most of the time that will result in much worse performance than using USD files to describe your assets.

So yeah, Solaris isn't Clarisse. Yet We will continue to take inspiration from it, and we are actively working towards closing that gap.