Let's see if we can keep the conversation civilized and keep the snarky remarks to a minimum:

I just finished watched the latest episode in the Solaris excellent tutorials series by Tyler Bay in an effort to really tackle what seems to be an important development in Houdini workflow:

https://www.cgforge.com/course?courseid=solaris [www.cgforge.com]

I'm coming out of the videos with a great deal of confusion, if not downright concern at the downright confusing node names, networks and processes that Tyler presents in the video. If Houdini was already a considerably challenging piece of software to learn, Solaris and USD seem to take it to a whole new level.

I do everything myself, from modeling to texturing to lighting to rendering and compositing – so my question is: do I really benefit from a USD workflow? All of the layer organization, permissions and overrides, portability, etc. seem unnecessary for my needs.

What I really liked from the Houdini 18 Solaris presentation was Karma's responsive IPR, the ability to work quickly with multiple light sources (reminiscent of Arnold's Light Manager), the ability to move objects in a scene with basic RBD properties, and the ability to rapidly instance and randomize objects and their properties. So my follow up question is: are all those features only possible because of USD? If not, wouldn't it make sense if they were also implemented in the OBJ context?

Or…is there a simplified way to work within Solaris and access those cool toys without worrying too much about all of the organizational aspects of it?

Solaris seems like a very powerful workflow framework for certain needs, but not all needs. To me it seems very PDG-like, in the sense that it's an incredibly useful tool if you have certain specific things that you need to accomplish, but not particularly useful if you have little to no need for those needs.

I would love to hear from you as to what your personal thoughts and experiences are regarding Solaris and USD.

if not downright concern at the downright confusing node names, networks and processes

Yes, as a hobbyist(indie) I still have not yet worked out my own personal workflow because I too find it ‘confusing’, in the sense its like a new language.

But on the other hand similarly like you,

the ability to work quickly with multiple light sources

, I find the same happening with materials/shading.(work quickly with ‘variations’).

Yet, this venture into using many lights/materials than I have before seems it might be lending itself to making more work for myself than necessary. And since I am not yet profficient with the language/context of Solaris/USD - I really don't know where I stand at the moment in terms of efficiency.

My view is that Solaris is primarily a Studio(larger than a single user context) ‘tool’ to aid in the different departments and the use of different software for their pipelines.

I think because of that, being USD, it's going to be unavoidable to have ‘confusing’ naming conventions and workflows in the Solaris/USD - just because of how USD is inately structured.

But that's not to say there can't be or will not be any changes to Solaris as it continues to be worked on and developed, that provides more clarity or ‘intuitiveness’.

I certainly won't know until I've studied USD itself much more.

Agreed,

The sheer fact Pixar chose to use words we have long associated with general Computer Graphics concepts is
super annoying, and adds a level of confusion. Once you get past that, it's not too bad though.

I don't think a single user would benefit from using it, just feels like a big investment for little gain.
Single user would be better off looking into using layered Alembics, as finally in the last release or so
we have this. Using layering of Alembics will get you somewhere in regards to making some stuff modular.

As far as IPR is concerned, latest Renderman and 3Delight (beta) have very snazzy IPR, so I think you aren't
missing out on too much at the mo.


Cheers

Lewie

I was excited after seeing the announcement videos, but I quickly realized Solaris/Karma is pretty much useless for small projects. It adds a bunch of complexity with no benefit that I can see. Karma's nice in theory, but rendering with it is a pain and it's still missing a lot of features. Beta though, so that's all fair enough.

I'd imagine single users and very small teams would be using lops for lighting and rendering only. Perhaps some of the cool RDB placement tools too. That should mean that they can forget about all the pipeline and asset/shot structure stuff that is made possible with the USD-centric lop nodes. Fast turn-around jobs just don't have time to worrying about the kind of thing in my opinion. IMO the sceneimport lop isn't fully featured enough to make that possible yet but I'm sure it'll come in time.

The nice thing for single users however is that, should your needs change in the future, Solaris and all the USD stuff is no doubt going to be a great platform for medium/large scale work and everything in-between. Rather than hitting a wall and needing to go a completely new direction, which is quite likely with OBJ.

Solaris is a dream come true for me. Its still very, very raw - LOPs crashes if you stare at it too long - and I'm not used to Houdini being this brittle. But, its a smart investment by SideFX/Pixar - and it will pay off very nicely in the long run.

The Redshift Hydra Delegate is maturing very, very nicely. Almost catching up to Renderman here shortly.

Daryl Dunlap
Solaris is a dream come true for me.

Can you elaborate on how so? Are you working on large projects with several other people on the team or are you doing solo work?

My personal, not fully educated but more of an “fly-by-and-over” opinion on USD is that anything that helps me with structuring and organizing scenes in a rock-solid, consistent way that won't change much over time and that is understood by any partner/client/etc without the need for documentation on what lives where … is highly welcome.
In theory, USD - like all the approaches in the past promising exactly the same thing - can and one day might be that: an organized, structured, consistent, agreed-upon set of rules where you just open up a scene you created five years ago and immediately find your way to the fridge.
In reality, I fear that USD will be what everything else became that promised structure but was created by one dreamy team of idealists: Adopting to real-world/projects' needs and therefore become a mess sooner than later. This, again, is just a fear. I give a bleep about fancy names like “Pixar” or whatever, having a well-known name is by no means a guarantee for producing the final answer to life, the universe and everything (ACES colourspace anyone?)

There's that ancient joke about any new standard to replace too many existing standards is the very reason for there being too many standards in the first place (I know, it's told slightly different) - USD definitely feels like that, rephrasing the same claims Alembic used when it was fresh.

But I repeat: If even 20% of what USD “promises” becomes reality (structure, organization, re-usability) and if it only 10% tidies up Houdini's mess of “workspaces/contexts” (obj/mat/blop/knop/xop/wrop/ößp …) I am willing to pay money for it. Or, in my world, I am willing to spend some of my very few hours left on this earth on learning how to use it. I am looking forward to looking into it. Even for “one-man-band” projects that I do for experiments or educating myself or figuring out solutions that I then apply in different environments.


Marc

USD looks amazing on paper… and then I think about a relatively junior user being exposed to all of the possible ways to organize things with it, and I get scared.

That said, if you're disciplined and experienced enough, I think there's lots of potential to automate a lot of things that used to require lots of clicking and manual setup. Take lighting multiple shots, which was really only feasible before with multiple HIP files, and sharing setups was lots of manual OTL building. Now you can set up a master lighting rig and branch to different LOP trees for different shots. That would seem to me especially useful to a single user.

Cheers,
Jon

malbrecht
In reality, I fear that USD will be what everything else became that promised structure but was created by one dreamy team of idealists:

Marc - can you clarify what you mean by structure? Are you referring to composition operators like referencing and variants, that in USD are the building blocks for structuring scenes? Or are you meaning conventions centered around naming scene hierarchies in a standard way? USD doesn't really deal with the later, much the same as an operating system doesn't mandate how you organize your files. Therefore the best way to find a fridge asset (for example) is going to be via a prim search (hopefully a fridge asset has “fridge” in the name) or by picking something you can see in a viewport.

@“antc” - I am by no means savvy in USD. What I mean by “structure” is really what the term describes: “A corset” of kinds. I think that what I mean by that is probably best described by what you list as references and variants.
Sticking to fridges (pun intended): If I have a scene that consists of a character, a fridge and a building with rooms and more fridges, I'd like to be able to reliably pick the character from any scene that is built up in a similar way. Not only within Houdini but across the board. I'd like to know what is “environment”, what is “props” and what is “character”. And what is “hero character” and what is “BG character”.
I'd like to know what is “lighting geometry” and what is “lighting sources” and what is “lighting environment” and so on. I'd like to have a topology or taxonomy that I can reuse across scenes without having to set up my own filters within the (what I personally consider convoluted) “contexts” in Houdini. And I'd like to be able to reference between those without having to manually create links - by an “automatism” (that I, probably, have to set up once, but can then reuse).

To me, a “scene description” (or in my world a “directory system” - like the old fashioned TIFF) only makes sense if I can leverage it the way I WANT to, not being limited by a tied-into-a-specific-application way of storing data (that then only makes sense within that application).
That's why I brought up Alembic as an example. I know it doesn't (well) support file references, but in general, it really looks very similar in claims.

I hope any of this makes sense …

Marc

Or are you meaning conventions centered around naming scene hierarchies in a standard way? USD doesn't really deal with the later,..

From what I can see so far it actually does ‘deal with the later’, and is in part a key feature of usd in how it can layer those heirarchies in different ways - which I still haven't wrapped my head around; In order to make full use of it.

Add to this the idea of ‘opinions’ and things like variants, then the analogy to an OS and how one organizes their files falls apart pretty quickly.

Marc - thanks for clarifying. There are constructs in USD like schemas and the kind hierarchy concept to help with identifying things independent of any specific scenegraph structure or convention. Correctly configured kinds can indeed make finding characters, props etc much easier. And as you correctly point out there are many benefits to having a scenegraph format that is not tied to a specific DCC. Regarding the different contexts my experience has been that they have their own merits with SOPs and DOPs being notably stronger than the others. It seems like LOPs (and TOPs) might well turn out to be equally great.

BabaJ - I was referring specifically to naming and organization of prim hierarchies, not the broader USD toolset. Hierarchies could be deep or flat depending on your workflow or preference. Likewise some asset in a scene could be called “poly1” for all USD cares. Beyond that then yes, USD is nothing like an operating system

Daryl Dunlap
Solaris is a dream come true for me. Its still very, very raw - LOPs crashes if you stare at it too long - and I'm not used to Houdini being this brittle. But, its a smart investment by SideFX/Pixar - and it will pay off very nicely in the long run.

The Redshift Hydra Delegate is maturing very, very nicely. Almost catching up to Renderman here shortly.

I'm also curious how it's a dream come true for you?

The fact that it's designed to be many people chomping on things at once kinda negates a real tangible benefit for a
solo user.


Lewie

If I may chime in on this not-really-discussion, maybe a different angle on how “single-user-teams” work can broaden some people's horizons:

The fact that it's designed to be many people chomping on things at once kinda negates a real tangible benefit for a
solo user.

… most of the (experimental and relaxational) projects I do with Houdini involve several different scene(-files) utilizing the same assets. Having to reimport, re-sync, re-do, re-sim, re-attach etc. all and everything, re-export, re-sync, adjust elsewhere, reconnect with scene dependencies again and again AND AGAIN is a major pain in what I use when I sit down and think.
In that respect, ANYTHING that provides a WORKING sync- and distribution process is not only highly welcome but might actually be “a dream come true”. I personally cannot imagine a scenario where I would not have assets reused in several scenes - ever.

Think about a scanned head, medium resolution (90 million triangles), standard texture set applied (12 UDIMs at 8192x8192 each). I may have one scene file with specific light setups, geometry blasted away for performance reason, normal maps converted to high detail geometry, another one with different setups for the same thing, but exportable for inspection elsewhere, another one with a different renderer. No, I do not do that all in one scene file, that would be a horrible mess. But being able to “reference” a major/main scene file where changes to the core geometry would distribute cleanly across dependent scene files but not limiting me to geometry alone (but including lights, maps etc) … that would indeed be nice.
Yes, to some degree I can construct that with Houdini scene files. Which ties me into Houdini exclusively, breaking any inter-cooperation options I might want to test.

Even with this very simplistic scenario, the “idea” of “many people working on one scene file” is absolutely applicable to my Houdini usage - with “many people” simply being me, manipulating reference assets elsewhere.


Marc

Ok I'll try and also add some more to the not-really-discussion I've been working in a large USD-based studio pipeline for a while now (more as a technical director than an artist). But before that I've worked in 1 to 5 person teams on commercials and music videos (mostly Maya). So I have some experience with various scale projects although the smaller stuff was 15 or so years ago.

Like Marc said, and from my experience too, most projects require some kind of referencing and also re-use of setups from shot to shot. Big studios have had that stuff figured out to some degree or other for a long time now. But for small teams that don't have the technical backup, there's typically lots of hoop jumping and error prone time consuming workflows to get bits of data out of one ‘scene file’ and into another. In Maya folks would try and use referencing to handle the sharing but it would break a lot and often cause more problems than it solved. Anyway, similar to Katana, LOPs should make all that a thing of that past, at least from a lighting and rendering persepctive. Hopefully it isn't difficult to imagine how pulling in assets, lighting setups, and applying whatever overrides procedurally is a win. Rendering entire sequences potentially from a single scene file saves time and reduces complexity.

It's true that heavy use of layering in USD is likely to be more suitable for large teams. But the thing is this - a single USD file for say an asset that contains all the geometry and shading is no more or less valid than the same assset with two dozen files all layered together. The end result, the ‘composed’ result in USD speak, is identical. So buy into just what you need, and if you aren't sure I'd say start simple - i.e with a single USD file per asset that you can reference into LOPs. In fact even simpler if you don't mind not having material networks in your files is to reference bgeo files from LOPs if that's whats easiest to begin with.

The other really important factor I think is how a LOPs workflow interacts with HDA based workflows. USD can't encode rigging and LOPs isn't a rigging context. So if the shots in your project contain mostly rigged assets and due to limited resources you don't want to get knee deep into a sparse baking/export pipeline then there has to be OBJ or SOP level HDA's in your scene. The key there is that the asset referencing is now happening in OBJ/SOP using the traditional HDA mechanisms anyway. So it has to remain a very valid workflow. That said, the main thing that a baking/export process would buy a small team is mulitshot lighting. Of course multishot gets a little messy if there is tons of ‘live’ rigged and keyframed assets for many shots in a single file.

On a small project though, if I were going to wind up with say 10 assets in a sequence and 5 of them needed rigging anyway, I'd probably just do them all as HDA to start with and only move to USD for the five non-rigged if I thought there were significant performance benefits. Probably though there wouldn't even be time to find out! On the other hand if there were 100 assets and still only 5 rigged I'd probably try do the other 95 as USD and skip OBJ for those entirely. But who knows - ultimately you can do whatever you want and 100 OBJ nodes is also fine so long as it is getting the results you need.

Ultimately I think if LOPs requires too much USD knowledge I'm pretty sure sidefx will keep banging on the user experience until it doesn't. Most non-techincal lighters using Katana are not super familiar with the underlying scenegraph machinery but they can still create great shots with great lighting.

antc
Ultimately I think if LOPs requires too much USD knowledge I'm pretty sure sidefx will keep banging on the user experience until it doesn't.

I want to chime on this point that was in made here, LOP/USD/Hydra represents a significant bump in the barrier of entry to producing content in Houdini.

It took me a couple months to wrap my head around it, trying to discover why SideFX/Pixar even invested so much R&D into realizing this new context - that's what my comment is based upon.

I think this just the tip of the iceberg in terms of what this technology will do going forward.

But I get it, I see the benefit, I see the philosophy and its a natural fit into Houdini pipeline - and I'm excited to watch this framework continue to mature inside/outside of Houdini going forward - the USD 20.02 spec. update just drop last week I believe.

Still no word on when/if that will be integrated into H18.

Reading this thread confirms a few things I grasped around the time little was known about this project.

Some people, mainly those operating in studios as TA/TDs, will benefit from this. Others, in smaller studios or freelancers, not so much.

At this point I'm on the fence whether these new technologies popping up like shrooms after a summer rain, are a step towards the democratization of technology in this field or quite the opposite, requiring more and more specialization, to the point where there's an incredibly high-risk high-reward contingent on what one will decide to sink in a lot of time, by learning this or the other.

It does feel a lot like PDG to me, in the sense that for some people this is heaven sent, while others are left scratching their heads trying to figure out why SideFX would have invested so much effort into something that seems unnecessary.

In my mind, I see the development of tools like PDG and Solaris/USD as SideFX's way to make damn sure that they will remain the de facto DCC at worldwide studios for at least the next decade +. That is absolutely necessary to their survival in a field that is not only incredibly competitive, but where everything can change extremely rapidly.

For my own purposes, I will stay vigilant on the developments of Solaris, but for the time being I can function quite well without ever going into LOPs.

At the moment I tend to get far more usage out of what SideFX Labs is doing, but I will continue to stay up to date with the new developments in hope that this will all turn into something very useful shortly.

Apart from all said, we have to take into account this is the very first iteration of the Stage/USD implementation in Houdini. I'm sure SideFX (and maybe third parties too) will be polishing and improving the base tools we've received on this release over the years in a way the barrier of entry for very small teams or individual will be reduced.
On the other side, Houdini has always required effort and study to fully understand so I have no issues with Stage requiring a long readjusting time to be included in your own personal workflow. For me, the only deal breaker right now is the presence of bugs and the fragile state of every hydra delegate, with a totally incomplete Karma, buggy and still missing features and workflows Renderman, etc. Rendering to disk is still a little nightmare…