I think SideFx has been right to adopt USD, I think it is the new standart, an improved and free alembic / fbx, the nature of the USD files makes it easy to handle a lot of geometry referenced with cameras and lights included, references to shaders, particles, all in one, that is incredible, having a file and modifying what is necessary without breaking the hierarchy, in addition the exchange between software is guaranteed.

I'm also wondering, what'll happen next?
Is LOPs gonna be the main context to be used for rendering moving forward?
What about the third party render engines, do they also keep supporting both OBJ+ROP combo and LOPs rendering system, or are they going to focus on only LOPs?
LOPs definitely has potential, but as a lot of people mentioned already, it's a bit confusing and missing some key features.
I think it's not quite there yet in terms of being the main rendering system.
But having two ways to render a scene seems confusing and requires double the amount of developing and maintaining for third parties too.

Yuri Serizawa
But having two ways to render a scene seems confusing and requires double the amount of developing and maintaining for third parties too.

Hydra reduces the development of the render plugins. The porting requierments will be minimal for 3rd party renderer.

Yeah, but at the moment 3rd party renderers have to port for regular old Houdini, and now create a Hydra delegate.

Midphase
Yeah, but at the moment 3rd party renderers have to port for regular old Houdini, and now create a Hydra delegate.

Except now, when a company invest R&D in maturing a Hydra delegate, that code is transportable to other Hydra host environments, the same as the scene artifact of the USD file, along with other benefits the USD platform provides, for example, every Hydra delegate inherently supports command line rendering, since you can feed a USD file to a Hydra delegate from the command line, without needing a DCC.

I cant remember a time when we've had so many rendering options in Houdini, granted, those Hydra delegates are at varying levels of maturity, but, the journey has just begun.

I honestly think that more points of input for feedback will be of a huge benefit.
Many things that have been pre-solved at medium or large studios do not get attention in the LOPs because, well, studios do not mention them since they got people working on them in the studio already.
The Animal Logic presentation was saying exactly that, so don't take just my word for it.
I understand that people with Indie licenses might not be the first people to ask for LOPs feedback - this is fair. I get it. But maybe this year SideFX makes a couple of polls via email blast to ask for those pain points of the “smaller” studios/solo creators?
Maybe even possibly create a small team solving those pain points, just like Labs team is doing amazing work solving pains with the realtime (and now many other) workflows?

I guess most of the great singleuser stuff used for promo on the sidefx insta channel would not realy benefit from solaris in its current state. modeling - animation - rendering should be as seamless as possible for many tasks. As mantra is AOL and Karma will be USD only i'm a bit concerned how things evolve.

wildruf
As mantra is AOL and Karma will be USD only i'm a bit concerned how things evolve.

Karma is still in early stages. Do you really think they would abandon the normal Houdini environment for Rendering?
Mantra is still more feature rich that’s probably why it’s still here. But I can imagine Karma will take its place sooner or later and will probably function very similar, only a bit fresher with all that old code gone)

Best
Christian

Christian_V

wildruf
As mantra is AOL and Karma will be USD only i'm a bit concerned how things evolve.

Karma is still in early stages. Do you really think they would abandon the normal Houdini environment for Rendering?
Mantra is still more feature rich that’s probably why it’s still here. But I can imagine Karma will take its place sooner or later and will probably function very similar, only a bit fresher with all that old code gone)

Best
Christian

No idea about the future of the “classic” render environment. The “USD only” info for karma was announced @ the solaris presentation. I guess features and workflow around USD are subject to change and will defenitely adress all our needs in the future. I only wonder about how all this gets communicated. What about new users ? I get the point that you learn a lot about rendering in general when you learn mantra, but i guess no one wants to jump on a sinking ship. So USD or 3rd party engine in the classic (also EOL?) environment ? is the only way for now …?

After some initial confusion, I believe USD makes a lot of sense, but yes, we have to grasp some concepts and name changes but once over that, I am confident it will be just fine.

The advantages for a medium to a large studio are obvious, for a one-band-studio much less but I would imagine it is what you will be able to do now that you can't do now and hopefully makes it worth it.

- Perhaps you will be able to scale up like never before.
- Perhaps the abstraction layer built between animation/lighting will make you a lot more efficient.
- Perhaps your line of work (for example medical viz) will benefit massively from increased reusability.
- More flexibility in your rendering choices surely may be useful.
- Using modern techniques to do overrides will perhaps allow you to explore with your client in a better way.

And surely more that I can't even think of.

That said, I do wonder what will be the impact with regards to OTLs as assets as right now they are little bundles of self-contained everything and from what I know about USD, it may not be the best approach with this new methods.

Perhaps we have to rethink the role of OTLs in our workflow, rather than assets more like factories…

Just thinking out loud.

jordibares
That said, I do wonder what will be the impact with regards to OTLs as assets as right now they are little bundles of self-contained everything and from what I know about USD, it may not be the best approach with this new methods.

Perhaps we have to rethink the role of OTLs in our workflow, rather than assets more like factories…

it has been mentioned that Sesi is planning to implement Hengine as a Dynamic Payload, in which case I can imagine you can still use HDAs as porcedural generators of USD subgraphs, that will be created during USD scene composition rather than having to be saved as .usd to disk for every variation of your HDA parameters

tamte
it has been mentioned that Sesi is planning to implement Hengine as a Dynamic Payload, in which case I can imagine you can still use HDAs as porcedural generators of USD subgraphs, that will be created during USD scene composition rather than having to be saved as .usd to disk for every variation of your HDA parameters

Interesting what you say, would it work like the cache nodes? similar.

Fco Javier
Interesting what you say, would it work like the cache nodes? similar.

as far as I understand it would be similar idea to render time procedural, with the difference that the HDA evaluation would happen during USD composition before it's streamed to the renderer so it would be renderer independent and shouldn't require LOPs either (as obviously currently lops can evaluate HDAs and generate USD from them too)

http://graphics.pixar.com/usd/docs/api/_usd__page__dynamic_file_format.html [graphics.pixar.com]
http://graphics.pixar.com/usd/docs/api/_usd__page__dynamic_file_format.html#Usd_DynamicFileFormat_DynamicPayloads [graphics.pixar.com]

Great, so all HDAs can be included with the dynamic payloads condition in the prim layer (USD Container Object). In other words, reference the HDAs as dynamic load to automatically load the entire asset into the USD system, before rendering. I am impressed by the scalability of this system. Great, thanks tamte.

tamte
it has been mentioned that Sesi is planning to implement Hengine as a Dynamic Payload, in which case I can imagine you can still use HDAs as porcedural generators of USD subgraphs, that will be created during USD scene composition rather than having to be saved as .usd to disk for every variation of your HDA parameters

That would be fantastic… thanks

wildruf
I guess most of the great singleuser stuff used for promo on the sidefx insta channel would not realy benefit from solaris in its current state. modeling - animation - rendering should be as seamless as possible for many tasks. As mantra is AOL and Karma will be USD only i'm a bit concerned how things evolve.

On the 3Delight side, we put our bets that the “old” Houdini workflow will be here for many, many years, to come. That's doesn't mean that we won't support Solaris (we are) but we will make sure that 3DelightNSI is nice and mature in good old Houdini too

You can join our beta here: https://discord.gg/MGtJx4q [discord.gg]

I really like Solaris even for Solo use. Since it saw the light I played with it every now and then and I really like the organizational aspect of it, altough it is not user friendly, fiddly and buggy.

I love creating or overriding Cameras, Layouts, Lights, Materials inside a separate "Shot branch" and the possibility of saving all these different things out as an individual nested usd, its way better than using takes or bundles.


But honestly, every time I´ve played with Solaris I reverted back to obj, in the hope Solaris would mature further. In the last few days I´m playing around again more than ever before. A few bugs, aha Moments and questions alike since then.

Currently I´m trying to skip the obj context entirely using "Sop Create" or "Sop Modify" for Terrain Generation, KineFX and other stuff, but its not working out yet. Has anybody figured out how to solo with Solaris?

Best
Christian

Man, its funny you mention this opinion - I've been doing some very heavy R&D on Solaris workflows - and I gotta say, it took me several.....SEVERAL days to get Instancing working in an understandable way.

I think it just the lack in accessible USD documentation for me, like, I wanna do something in LOPs, but its not really clear when/how/why you used one option or node over the other.

Its very frustrating to be honest. What's the difference between a Reference and an Instanceable Reference?

To this day, I dont know.

CV
But honestly, every time I´ve played with Solaris I reverted back to obj, in the hope Solaris would mature further. In the last few days I´m playing around again more than ever before. A few bugs, aha Moments and questions alike since then.

Pretty much my experience so far. I really like the idea behind USD, but I decided to stay with /obj to save some headache.

It kinda reminds me when I did web development for IE6. Of course HTML is/was with good intention, but by the time the tooling is just not good. To be clear, Solaris is very well-designed, but it's ill-implemented.

Maybe I'll try it again when H19.5 comes out. But for now, no thanks.

Daryl Dunlap
Its very frustrating to be honest. What's the difference between a Reference and an Instanceable Reference?

To this day, I dont know.

A regular (non-instanceable) reference generates uniquely accessible USD prims for each reference. Arguably the most important thing being it allows each occurrence to support overrides since they are totally distinct. E.g you reference a character 3 times but want to overlay different point animation on all the meshes for each reference.

An instanceable reference shares all the prims below the root of the reference with any other instanceable references that may exist to the same file (or strictly speaking, with the same composition arc). Because under the hood there's only one occurrence of each primitive it isn't possible to apply overrides. E.g you reference a complex tree asset 100 times and need instancing to save memory when rendering. De-instancing would allow you to overlay a different wind clip onto all the leaves and branches of every tree. But of course some of the prims in each tree are now unique and will likely require lots more memory when rendering.

Where it gets a little trickier is situations where you want to mostly instance, but then override in just a few spots. A vehicle for example where you might want to instance the rigid stuff (chassis etc) but have non-instanced tyres that can rotate and squish. That's all doable, but you have to introduce references at the locations where you want to instance (lops makes that fairly straight forward once you get the hang of it).