With all the great changes in H20.5, I’m wondering when would one still consider using SOP content?
Why not just build for example your scene straight in Solaris and use SOP Create to create everything you need.
Are there any specific limitations around this approach?

I’m assuming that SOPs/OBJ are still in houdini native scene format and Solaris is USD and hence there’s some constant translation happening? And maybe along those lines - why couldn’t’ houdini go all USD native?

I think the OBJ context exists for the same reason Mantra exists. It's backwards compatibility.

LukeP
Why not just build for example your scene straight in Solaris and use SOP Create to create everything you need.

Because it's easier to use Obj/Sop context for building, designing and organizing projects.(speaking for myself).

Why take the extra steps and do that in Solaris? When you are not going to use Solaris?

alexwheezy
It's backwards compatibility.

It's for forward 'compatability', because it serves as a useful context.

USD is more an assembly/lookdev/playback thing, it not something you can comfortably create content in as it doesn't do skinning, deformations, simulations etc. And /obj is just a 100x faster for a lot of things, so while they do have some overlap neither is a replacement for the other.

LukeP
With all the great changes in H20.5, I’m wondering when would one still consider using SOP content?
Why not just build for example your scene straight in Solaris and use SOP Create to create everything you need.
Are there any specific limitations around this approach?

I’m assuming that SOPs/OBJ are still in houdini native scene format and Solaris is USD and hence there’s some constant translation happening? And maybe along those lines - why couldn’t’ houdini go all USD native?

USD does not tick the need of all of us, and to build a complex massive full openworld and shot/asset pipeline of over 120 HDA where a single one could be over 600 nodes with tons of Python and other DCCs and engineers code outside houdini is a huge thing than many, many of us are not interested or just can not justify the move and resources for at the moment.

Many, including me are still looking for a better viewport optimization like what Clarisse was offering without having to deal with all USD complications, and so far my experience with Karma hasn't been quite satisfying and is still way behind in term of reactivity thing like Eeve, Redshift, or to the glorious quality of Octane... Maybe im wrong, im not closed to change my mind.

But H20.5 has brought a lot's of hope, many things i haven't waiting for like many of us, are happening to what it looks to becomee one of the most exiting milestone in the stunning history of Houdini development!

I think the best workflow is to build in OBJ context, and create a LOP Network in OBJ for Lookdev/rendering, avoiding much of the back and forth, at least IMHO!

vinyvince
USD does not tick the need of all of us, and to build a complex massive full openworld and shot/asset pipeline of over 120 HDA where a single one could be over 600 nodes with tons of Python and other DCCs and engineers code outside houdini is a huge thing than many, many of us are not interested or just can not justify the move and resources for at the moment.

That’s totally fair enough, but if not HDAs or USD I’m genuinely curious how folks are sharing stuff between shots or setups or whatever in Houdini. Back when I was at a small studio that used Maya exclusively and often worked projects with a handful of shots, we still had to deal with referencing and versioning assets and all that kind thing.

Not everyone works in Solaris.

I'm getting used to using the build context to create, and then light and render it in Solaris. It's easier, and also keeps the Solaris part of things relatively simple and streamlined.

Not that I'm an expert with Houdini or anything yet, I'm still learning