Opinions On Workflow

   555   3   0
User Avatar
Member
21 posts
Joined: May 2016
Offline
So, I've only been learning Houdini for less than a week (after 20 Adesk years of being afraid of it )and I'm really enjoying the experience. It's so much more user friendly than I had always assumed over the years.

One thing I've been wondering as I continue the learning journey is what are people's general preferred workflow? working as a freelancer or small studio with a relatively simple pipeline. This is specifically related to building the rendering/lookdev pipeline on Solaris/Karma XPU.

From reading and tutorial videos I've been studying my impression is that Solaris is essentially a USD hub (similar to Omniverse) and Karma is a Hydra delegate. Everything that is brought into the Solaris workspace is converted/translated to USD.

I've seen 2 distinct workflows regarding this:

1 - build/import assets in the obj context of the build workspace and import/translate them to the stage context of the Solaris workspace

2 - build/import assets directly in the Solaris workspace stage

Personally I'm leaning towards the second option for several reasons. Primarily because everything is directly available and editable in that space and I don't have to keep switching over to build.
Is there any reason that this is not necessarily better than option one? And also, does it cut down on resources that may be needed for the translation process of assets that have been imported from the first workflow option? I'd love to hear what users here prefer or their reason why one id better than the other, or indeed, why I'm wrong and there are in fact better ways to go about it.

Cheers.
User Avatar
Member
144 posts
Joined: May 2021
Offline
Solaris does not have the geometry processing tools that SOPs has but you can start in Solaris and throw down a SOP Create and dive into SOPs.

I think Solaris is for the USD workflow which is a very production driven workflow. It allows for rendering using Karma. So it depends on if you are dependent on lighting, material, and rendering or are you dependent on animation and geometry processing.

It also depends on if you are in a Production working on a USD code base or if you are independent. I think that USD is awsome but also, the file structure is esoteric and a lot of stuff is still being established through proposals.

What is your end build target/output? A film, a tool, a game, a design artifact etc.?
Brave, Big-hearted Rebel
------
Design the Future, Now.
PHENOM DESIGN
------
Processing smarter, not harder on a M3 MAX 36GB
User Avatar
Member
247 posts
Joined: Jan. 2008
Offline
With the caveat Ive not worked in 20.5 and I know there is a "see through" function to the sop modify LOP.


We import / export everything as usd via solaris. If we are to do something with the geo, we are LOP importing it to /obj and when done, SOP importing it to solaris.
The reson we are building/simulating in /obj(build) context is, we like having all simulation components in one geo container. This way I can have them influencing each other without importing/exporting every components throug LOPs and different networks.

We are also using freelancing artists and everyone knows SOPs, but few know LOPs. We want them to get into sops as fast as possible and stay there as long as possible, purely use solaris with scripted i/o for lookdev and publishing to other departments.


If you do smaller stuff I really dont think it matters. The sop create and sop modify are wrappers with build networks inside them and will in many cases convert the geo anyway.
User Avatar
Member
21 posts
Joined: May 2016
Offline
@mawi @phenomdesign Thank you both for the detailed answers. I'm going to just test both options in a typical scene that I would be look-deving and see which works best for my needs in practice.
  • Quick Links