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

FWIW, I've never set foot in the /stage context for production work.

I still can't wrap my head around the upside for small commercial projects and tiny (sometimes solo) teams.

The extra complexity appears to offer nothing in return in my scenario

G

On top of LOP context not being ready to replace Object context yet, there is also no need to push this possible future replacement to happen, it will happen naturally once it is ready, faster and more convenient to use LOPs in all areas

It will also most likely happen independently for each artist at different times or never, you can always use whichever contexts fit your workflows better

关键帧
FWIW, I've never set foot in the /stage context for production work.

I still can't wrap my head around the upside for small commercial projects and tiny (sometimes solo) teams.

The extra complexity appears to offer nothing in return in my scenario

G

While I don't agree that Solaris is more complex for lookdev, it is actually very user-friendly. The only issue is the current lack of USD model resources, which is a long-term development plan. The only reason I hesitate to use it is due to performance concerns. The Hydra framework seems to significantly affect rendering performance and real-time capabilities. I've tested rendering the same model and HDR lighting with Redshift, RenderMan, and V-Ray, and the response and rendering speed at the OBJ level always outperform Solaris. I believe this is an issue with USD. Pixar's development is always very slow, which makes it quite awkward for SideFX as well.

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?

UHM no ,where will i build my procedural geometry for my unreal/unity houdini engine stuff

/obj is still the path of least-resistance for throwing a scene together in a hurry, which is like all the time on small/solo projects.
The Disney workflow has its merits for vfx shows managed in the siloed factory-line style, and is worth learning if you plan on working in such places, but its still a niche tool for a small segment of the many applications of Houdini.

Not everyone uses houdini for rendering. Various gamedev and mesh processing tasks are done strictly in OBJ.

Versalight
Not everyone uses houdini for rendering. Various gamedev and mesh processing tasks are done strictly in OBJ.

Yes i c that argument but they don't have to render in lops.
They could just model everything exzactly the same way but in lops.


Although i must just so not all the nodes from OBJ clutter my lops tab menu is enough of a reason for me.

(Defiantly would prefer APEX working directly in lops though)

While using LOPs as the new OBJ, you may run into an issue in 20.5.238.
It often makes workflow sense to split to two 3D views left/right, have a LOPS level 3D view open, and a SOP level view in SOPs or COPs. But if the LOPs level view is also Vulkan vs Karma then it can get hosed, similar to early v20 had visibility issue and crashes with visualizing SOP attribute and bouncing between LOP and SOPs 3D view.
A bug temp fix is to tear off a pane tab copy of the bugged Vulkan view and both refresh and usually stays stable.
Also redisplay flagging the steps in LOPs helps get back lost textures if using COPs geo.
I'm sure Sidefx will have these glitches fixed soon.