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?
H20.5 - can we just ditch OBJ?
2849 16 5-
- LukeP
- Member
- 350 posts
- Joined: March 2009
- Offline
-
- alexwheezy
- Member
- 276 posts
- Joined: Jan. 2013
- Offline
-
- BabaJ
- Member
- 2110 posts
- Joined: Sept. 2015
- Offline
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?
alexwheezyIt's for forward 'compatability', because it serves as a useful context.
It's backwards compatibility.
Edited by BabaJ - June 29, 2024 08:00:00
-
- Jonathan de Blok
- Member
- 274 posts
- Joined: July 2013
- Offline
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.
More code, less clicks.
-
- vinyvince
- Member
- 263 posts
- Joined: Sept. 2012
- Offline
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!
Edited by vinyvince - June 29, 2024 12:52:25
Vincent Thomas (VFX and Art since 1998)
Senior Env and Lighting artist & Houdini generalist & Creative Concepts
http://fr.linkedin.com/in/vincentthomas [fr.linkedin.com]
Senior Env and Lighting artist & Houdini generalist & Creative Concepts
http://fr.linkedin.com/in/vincentthomas [fr.linkedin.com]
-
- GCharb
- Member
- 279 posts
- Joined: June 2016
- Offline
-
- antc
- Member
- 322 posts
- Joined: Nov. 2013
- Offline
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.
-
- Soothsayer
- Member
- 874 posts
- Joined: Oct. 2008
- Offline
-
- WinterLightDP
- Member
- 6 posts
- Joined: March 2022
- Offline
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
Not that I'm an expert with Houdini or anything yet, I'm still learning
![](/static/djangobb_forum/img/smilies/smile.png)
http://WinterLightStudios.ca [winterlightstudios.ca]
-
- keyframe
- Member
- 1533 posts
- Joined: July 2005
- Offline
-
- tamte
- Member
- 8723 posts
- Joined: July 2007
- Offline
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
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
Edited by tamte - July 4, 2024 15:42:56
Tomas Slancik
FX Supervisor
Method Studios, NY
FX Supervisor
Method Studios, NY
-
- MASee
- Member
- 5 posts
- Joined: Feb. 2017
- Offline
关键帧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.
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
-
- Morphtek
- Member
- 15 posts
- Joined: Nov. 2018
- Offline
LukePUHM no ,where will i build my procedural geometry for my unreal/unity houdini engine stuff
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?
-
- apprenticeuser
- Member
- 9 posts
- Joined: April 2022
- Offline
/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.
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.
-
- Versalight
- Member
- 3 posts
- Joined: Jan. 2019
- Offline
-
- NicTanghe
- Member
- 210 posts
- Joined: Dec. 2016
- Offline
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)
-
- GrahamDClark
- Member
- 112 posts
- Joined: July 2005
- Offline
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.
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.
![](http://www.grahamdclark.com/pages/portfolioimages/WomanCloseS.jpg)
-
- Quick Links