So I am correct in assuming that Mantra will be replaced by Karma at some point.
That also means that we are forced to use USD to get stuff rendered while staying in Houdini.
Do not get me wrong I see the benefits of using USD, but would rather see that as option not as something forced upon me.

I am asking as I am bit concerned with that. I don't want to bash on Karma yet due its Beta status.
But with Mantra we had an extreme reliable Renderer that was insanely integrated into Houdini.
Granted its slower than other ones but I yet to find one I can count on and the unlimited access to render nodes makes up for that.

I am evaluating RenderMan at the moment, and find it very promising but already missing the versatility of all the vops we have with mantra.

I'm on exactly the same situation, evaluating Renderman and trying to gather information on Karma roadmap and expected features and limitation, but frustratingly have not found nor received any information… Let's wait and see. If Karma doesn't have the feature parity and flexibility of Mantra, Renderman will be a relatively good and more performant alternative.

sekow
forced to use USD to get stuff rendered while staying in Houdini.

I hope that doesn't end up being the case. I'm sure USD is great for what it is, but it's super overkill for smaller projects.

I was hyped about Karma after all the teasers, but I see now that it's a completely different workflow and is MUCH worse than Mantra for the kind of stuff I like to do. If SESI eventually implements Karma as a “normal” renderer (Mantra, Arnold, Octane, etc.) that will be fantastic. But if it stays USD specific and the whole USD thing becomes a requirement then Houdini will be much less useful for me.

Renderman seems nice, but it has some seriously janky elements compared to Mantra (which is pretty much perfect, outside of being kinda slow). For better or worse, other renderers have a very high standard to live up to.

BrianHanke
Renderman seems nice, but it has some seriously janky elements compared to Mantra

What don't you like about Renderman?

Midphase

BrianHanke
Renderman seems nice, but it has some seriously janky elements compared to Mantra

What don't you like about Renderman?

Since they took away SL, a lot of constraints were added that are still possible in VEX. Here are a couple more:

- No closure support in OSL, so mixing BSDFs is a pain. Try mixing multiple volume phase functions in RenderMan…
- Looking up arbitrary geometry attributes is also a pain (primuv, pcfind, etc.).
- Not being able to create lens shaders with a shading language.

sekow
That also means that we are forced to use USD to get stuff rendered while staying in Houdini.

Mantra requires that the scene be written to a proprietary scene format called IFD in order to render. Most people neither know nor care much about it; it's generated by Houdini every render behind the scenes.

Karma will do exactly the same thing eventually, except it'll use a more open format in the form of USD instead of IFD. LOPs will have a bit of an advantage here in that the USD already exists, but you will be able to render out Objects as well (think Scene import LOP doing all the dirty work inside of a regular ROP).

Tbis also means that Karma can render USD files not generated by Houdini at all, which is something mantra can't do.

Midphase
What don't you like about Renderman?

In my (limited) testing:

- Renderman occasionally stops updating in render view
- You have to click Render in Background instead of Render for some reason when creating an animation, otherwise it interrupts itself on every frame
- The IPR insists on sticking a black _id frame after every animation frame, making playback useless (never did figure out a workaround for that one)
- Having to convert all image textures to .tex is a pain
- The Renderman forums and subreddit are pretty dead, so it's hard for non-experts to learn

All of this stuff is manageable and Renderman results do look amazing, but Mantra just has that extra level of polish that's hard to beat.

twod

sekow
That also means that we are forced to use USD to get stuff rendered while staying in Houdini.

Mantra requires that the scene be written to a proprietary scene format called IFD in order to render. Most people neither know nor care much about it; it's generated by Houdini every render behind the scenes.

Karma will do exactly the same thing eventually, except it'll use a more open format in the form of USD instead of IFD. LOPs will have a bit of an advantage here in that the USD already exists, but you will be able to render out Objects as well (think Scene import LOP doing all the dirty work inside of a regular ROP).

Tbis also means that Karma can render USD files not generated by Houdini at all, which is something mantra can't do.

Like I said, I see the benefits, and I see how LOPs could boost asset heavy productions.
The concern I have is that in production that are not that demanding, LOPs could delay a fast paced workflow.
I am working mostly in Commercials, where short turnover times dictating an effective setup.
The thing is that I already work reference based. Keeping the IFDs very small and export times short.
My gut feeling is that I need to go thru one more step, before pushing out those renders.
For example we can load everything bgeo as pack disk primitives, which Mantra just loads in without any export to ifd (well just the reference path).
Now we would need to build up the ‘export Archive (USD)’ “by hand” with setting it up in LOPs, just to reference the path in an usd.

I might be wrong and in the long run, setting up Lops networks will be as fast as dropping an Obj Node with a file sop in it.

The sceneimport lop should make pulling in simpler obj based setups super easy. Right now unfortunately sceneimport seems to do some funky stuff with embedded material networks. For example on the USD side I can't find a way for it to keep the material prims encapsulated in the respective asset. Rather they are always imported into a global location which makes a mess once there's multiple assets and lots of materials. Also for me the bindings are always busted which I guess is just a bug.

But once these kinks get ironed out it seems there won't be much difference in workflow complexity between an object workflow or referencing bgeo caches directly in lops.