Will Karma ever be available in Houdini without having to use Solaris? I get that Solaris is very clever but it's another very complex context to learn just to access a replacement for Mantra. I bash out little standalone graphics and Solaris would be pointless for me.

as far as I know karma is bound to usd. give it a try, You can dive very deep, but You also can stay in shallow waters and it still will benefit You greatly.

what would Solaris / USD give me? (Apart from just expanding my brain by making me learn stuff which is always good) that would be any use to a tiny one man band?

Looking at the sneak peak video, I'm curious about this Karma ROP. Let's hope and see.

where to start....

- a clean and elegant way to build Your render setups
- nodes for render setups, so You can easily test different settings
- usd advantages when writing usd. no more bottlenecks in ifd generation, prior to rendering
- much faster startup on rendering



just to name some

I think h19 reveal video showed that Solaris is going to be whole UI subsystem to speed up set dressing: scatter and placing brushes, quick lighting setups and controls, straightforward constraint presets, assets management library, functional tree (sub)object manager, render agnostic scenes and shaders, non-destructive layout iterations with layers.
The software just not at the point yet, because at current state it is a technical release. For non tech enthusiast it's better to think that there is no Solaris at all until it suddenly come out on a white horse as finalized product, or more wisely start to discover the new context little by little.
I bet SideFX put enormous effort to bring a set dressing to next level without breaking existing pipelines.
Besides (just by looking what they did with pyro preview) I hope that in the future ogl viewport will evolve into something that gives results with quality very close to final render and it will be not necessary to press render button till last production stages.

I agree that Solaris is clever and useful and neat. I also agree that it adds a needless layer of complexity and one-more-thing-to-know when all you want is some dumb exrs with some objects. You don't always need a full pipe studio multiple department all can do context.

USD has several advantages over traditional OBJ context, and it has a few nagging disadvantages too (the non-destructive nature of USD and the ridiculous rules around what you can/cannot change on Instances).

The Solaris presenters at the View Conference did a really great job explaining USD/Solaris and its a great primer on anyone that wants to get up to speed on USD in Houdini.

At the very least solaris offers a sane way to deal with render pass management. Regardless of project complexity or team size, destructive workflows when generating passes causes tons of problems. So to start off just use it as a takes replacement that actually works, and go from there.

Daryl Dunlap
USD has several advantages over traditional OBJ context, and it has a few nagging disadvantages too (the non-destructive nature of USD and the ridiculous rules around what you can/cannot change on Instances).

Solaris had certainly prioritised non-destructive workflows because that’s primarily what node networks are good at. But USD isn’t inherently non-destructive. Similar to photoshop you can choose to work destructively in one layer or add new layers, keeping previous layers intact.

It’s hard to comment on the instancing because I haven’t seen the videos yet. But it’s certainly true that instance prototypes are more difficult (but not impossible) to edit due to their implicit nature. It’s actually not that hard to create an explicit prototype that can be edited normally, so hopefully the tooling will get better for that over time.

Soothsayer
I agree that Solaris is clever and useful and neat. I also agree that it adds a needless layer of complexity and one-more-thing-to-know when all you want is some dumb exrs with some objects. You don't always need a full pipe studio multiple department all can do context.

In my very limited experience with Lops I've had less context switching and diving inside nodes while working with it.
The time to first pixel is cut significantly. Which results even in faster iterations.
And what I also did not know is how great it is to have a visual dependency graph of a the whole scene at first glance.

I am kinda an one man shop and thought that I could not benefit from usd, but after forcing myself to use it its quite the opposite.

antc
prioritised non-destructive workflows because that’s primarily what node networks are good at.

I think Blender would disagree with that statement.

antc
But USD isn’t inherently non-destructive. Similar to photoshop you can choose to work destructively in one layer or add new layers, keeping previous layers intact.

It’s hard to comment on the instancing because I haven’t seen the videos yet. But it’s certainly true that instance prototypes are more difficult (but not impossible) to edit due to their implicit nature. It’s actually not that hard to create an explicit prototype that can be edited normally, so hopefully the tooling will get better for that over time.

Its the collision of authoring vs layout that's shocking the Houdini Community in my opinion.

Being handcuffed about what you can/cannot do to Instances in USD is just very jarring - and kinda against the Houdini philosophy of low-level access when authoring.

Especially when you consider, how is the laymen supposed to even discover the rule preventing them from making a change?, because Houdini just renders, it doesnt tell you why your attempt failed.

Daryl Dunlap
Its the collision of authoring vs layout that's shocking the Houdini Community in my opinion.

Yeah in the long run it's cool when a context can be used for multiple workflows, but in the short term results in even more stuff learn. If it were me I would pick something simpler than layout to start with. Kind of like with sops you probably want to start with some modeling operations and get the hang of the basics rather than try learn crowds or kinefx right out the gate.

Daryl Dunlap
Being handcuffed about what you can/cannot do to Instances in USD is just very jarring - and kinda against the Houdini philosophy of low-level access when authoring.

Especially when you consider, how is the laymen supposed to even discover the rule preventing them from making a change?, because Houdini just renders, it doesnt tell you why your attempt failed.

I'd at least expect to see some warnings from the lop node that tried to apply the edit/over to an instance proxy prim, which is basically the problem. But I agree it would be great if instances were easier to deal with. The 'U' in USD makes instancing quite tricky.

Maybe in 5 years

Just found this thread.
Sidefx can we please replace mantra with Karma?
Solaris is cool and great and all that, and its "the future" just because disney / pixar say so . my problem with it is that it is inherently an outdated workflow. pixar functions as a bunch of silos with deptments for each task. Naturally usd reflects the way pixar works. this taylorism / waterfall like workflow is anitquated and old. most of tech has moved on to devops / agile workflows. I know this is vfx we are talking about but for the most part episodic television and commercials work more in a devops / agile way where features films work in waterfall / silos. I think this is why you get people in these forums who are just like "just use solaris is so great" becuase they are not workin in a agile way. Solaris forces me into another silo and I do not like that. Houdini was great for small agile multi fasceted teams having control of data at anypoint along the chain and being able to make rapid changes is amazing. and this is why it is far supirior to maya for this type of workflow imo. forcing everyone into a waterfall siloed workflow to use karma / usd sucks imo. the karma rop doesnt really work very well it almost never renders things as expected. why cant karma just drop in and replace mantra? how can redshift / arnold/ vray / octane all work in obj context and solaris? I rufuse to run my teams in silos i just dont agree with the philosopy of the assembly lime for fast pased episodic / commercial work . its to hard to keep people busy at the begining or end of the chain unless you have constant new projects coming in for them to jump onto. I like my teams small and multi faceted and having the same team on a show from begining to end. there are no sep silos or dept. so USD for me is a great format as a replcement for abc but the workflow imo is for large studios using the outdated waterfall workflow. Your basically making me have to purchase a third party render engine that still supports houdini as a authoring tool since you seem to be abanoding it in favor of solaris. I dont like being forced to work a certain way and i dont like being told by people who think they are smarter then everyone else to just get on board with usd. the workflow is super old and outdated at the core. at this day and age we need to get smaller and faster not more siloed and slower. just my opinion I wish sidefx would jsut offer karma as a replacement to mantra.

https://www.sidefx.com/docs/houdini/nodes/out/karma.html [www.sidefx.com]

Houdini 20.5 Nodes Render nodes

Karma render node
Renders non-USD scenes using Houdini’s Karma renderer.

Since 19.0
This ROP is an HDA wrapper around Scene Import, to provide a Karma workflow to Houdini artists coming from Mantra or other non-Solaris third-party renderers in Houdini.

This node lets you render to MPlay, or it can create a floating Karma Viewer, for an IPR-like experience

yeah the karma rop is not great ussually just crashes or renders things gray scale or wrong. . I have not tried in 20.5 I will check it out .

Michael Kirylo
. Naturally usd reflects the way pixar works. this taylorism / waterfall like workflow is anitquated and old

USD isn't mandating any kind of workflow though, or even shooting for that. USD is all about interchange, hence the name. The layering is primarily to support non destructive editing, and can be leveraged by larger teams to work on the same scene concurrently, primarily to avoid rigid waterfall style workflows. An individual however might choose to work destructively in a single layer for simplicity reasons and that's totally fine.

I'm not sure what version(s) you're referring to wrt experiences with the Karma ROP but I've hit issues in the past as well and I've yet to play around with 20.5

Correct about usd I’m talking about Solaris. I don’t want to jump into another context and build all my lighting look dev there and loose all my attributes / connections to Houdini. Just seems like Houdini as an authoring tool is being left behind . Unless I’m missing something . Will karma ever replace mantra? Or is the plan to just not be able to render from obj level in the future ? Main thing for me I I don’t want to deal with layers and the way my obj are named and structured that’s why I left maya in the first place .

Michael Kirylo
Just seems like Houdini as an authoring tool is being left behind

My thoughts as well. Have worked with the tech since PRISMS, get & appreciate the design concept, (mostly) enjoyed seeing its progress... until recently.
Tying something as significant as a renderer to a client's workflow was a significant turning point: where Sidefx seemed to give-up on the plan and start stickytaping kinda-interoperable 3rd-party tech to its application, much like 3DSMax after it was sold and passed-around. This doesn't diminish its usefulness, but still disappointing. I'd hoped to one-day see ROP-vopnets, not another blackbox.