Houdini or Katana

[alenrqz21]

Good morning everyone,

My current studio is deciding to migrate from Maya for lgt. We have been checking Katana, however, Houdini is already part of our pipeline and I was wondering if moving to Houdini could really improve the workflow comparing to Maya to the point we can consider Houdini instead or Katana.

My question is, would you recommend Houdini for a full Arnold base lighting workflow and what would be the benefits or cons against Katana?

Thank you,

 

[TobyGaines]

I personally recommend Houdini over Katana, I've used both for lighting, and while it was an older ver. of Katana ( 2012, before Foundry bought it ), it was the slowest lighting tool I've ever used, and rather frustrating to use. Conversely Houdini is the BEST lighting tool I've ever used, despite missing the depth of features of other apps ( like barn doors ) ; the stability and flexibility are unmatched. Adding Katana to your pipeline also does not replace Maya for anything but lighting, whereas Houdini could replace Maya entirely, and you won't have to migrate any Fx either. Adding additional software, which has it's own unique requirements for integration into the pipe, is going to take more effort and more money than using what you already have.

[Yon]

Unless your working on feature films with huge assets/environments Houdini is the way to go. We use Katana here at Imageworks and though I'm not a lighter, I've used it a bit and it's pretty bare..

By the way at the end of 17.5 presentation they spoke publicly about "LOPs", a new lighting context coming in the next major release or two I would guess.

[davpe]

I'm not a Katana user, but I have used Houdini a lot for big and small projects. In overall I'm very happy with it as a lighting tool, and it's developing rapidly. Even super heavy film stuff can be handled very efficiently (depends on your workflows thou). If you already have Houdini implemented, I don't think there is any significant benefit to having Katana alongside - Houdini can do all of it. Katana for sure offers some nice lighting/shot handling tools, but Houdini can be used for doing all sorts of stuff, which can aid lighting/lookdev significantly due to it's ability to actually work with and modify the geometry, allowing arbitrary attributes and processing, without having to transfer data between packages (this is a HUGE advantage, especially with big stuff). So i guess Houdini is more efficient and capable tool in overall. It also offers a very open architecture where you can virtually build your own pipeline/workflow tools with HDAs and PDG, that suit exactly your needs, and it can be done quite easily without extensive programming skills. Sidefx tech support is one of the best I've ever dealt with, which I can't say about Foundry. Last, but not least, I don't know what's the price of Katana license but I imagine it's not exactly cheap. I believe $3000 for Houdini Core is a competitive price, considering it's a multipurpose package.

Edited May 6, 2019 by davpe

[alenrqz21]

On 2019-05-05 at 7:49 PM, Yon said:

Unless your working on feature films with huge assets/environments Houdini is the way to go. We use Katana here at Imageworks and though I'm not a lighter, I've used it a bit and it's pretty bare..

By the way at the end of 17.5 presentation they spoke publicly about "LOPs", a new lighting context coming in the next major release or two I would guess.

Do you think Houdini can't handle huge assets and environments as Katana?

[pclaes]

Since you specifically mention Arnold. I would also recommend to go with Houdini. The HtoA implementation is quite good. 
This became more feasibly with the introduction of the alembic rendertime procedural for Arnold over the past couple of months. 
Combined with Arnold Operators you can make a lot of changes 'at rendertime' without having to load the heavy data in the the scene description file.

For certain things there are limitations (no pointcloud reading or volumesample support yet for shaders at rendertime), but you can use mantra for that. Also if you are forward looking, usd and the lops context will be huge.
Already out now is the TOPS context which can trigger huge dependency trees and spit out final rendered (potentially even slapcomped) renders. 
The customizability, extensibility, stability of Houdini combined with a company that truly listens and supports its clients is unmatched by other vendors in my opinion.

 

In regards to being able to handle huge assets, this mostly comes down to how you optimize and organize your scene assembly. 
Eg. Understanding and making heavy use of instancing, packed disk primitives, rendertime procedurals, level of detail, mipmapping, rat/tx conversion. The kind of control you have over instancing combined with Arnold Operators is quite powerful. 

Mantra is not the fastest renderer, but it is robust and can handle lots of custom scenarios.So in regards to handling large amounts of data, Houdini is great at that. 

[Howitzer99]

I've been building-up my personal lighting pipeline around Houdini, and I'm really impressed with the speed and ability to customize so many of the features in Houdini.  While I'm relatively new to Houdini, I've used Katana for many years, and it really hasn't gotten any faster for geometry loading (scrub the timeline, what?!).  At the end of the day, it all comes down to speed and how comfortable the artists are with the software package to turn-around shots in a tight schedule.

With Houdini, you also get the power of a DCC package, and direct integration with FX elements, since they're mostly being generated from within Houdini already.  One less headache it always nice!

As Peter mentioned, Mantra is definitely not fast, but with all the major render packaged supported in Houdini, at least you're not locked-down to using it if you don't want.

[p2or]

Recently discovered Lookbox by Oliver Hilbert, which I think shows the potential and freedom of Houdini's UI, building a custom lookdev environment as well as all other kinds of workspaces. For now it only supports Mantra, it is still in a beta stage and unfortunately throws an error message on the supplied (old) mantra node within the setup on H17.5 because of some newly introduced 'cryptomatte' variables in recent versions of Houdini. However, it's just an 'hda' so you can always dive into the network, replace the old mantra node and also modify the 'hda' according to your requirements.

For the record: There is also Gaffer, an open source lookdev application with full support for Arnold developed on github by John Haddon and Image Engine.

Cheers,
Christian

 

 

 

[markw]

Hi.  I know this is a bit of an old thread but it might be interesting to some.  I run the VFX and 3D degree in the University of Hertfordshire.  We have been teaching Solaris this year with H18.5.  The screen grabs below are work I am doing for when we move to H19.  I have built quite a few HDA's for reconfiguring data to clean USD stage and external files.  The last pic is the USD lighting template I am building to work with my "asset prepper" .  What I am doing in my HDA's is tagging files with specific collection names that are automatically picked up in the render template (shadow catchers etc).  By creating self contain assets on disk it means we can going into Unreal, Omniverse etc.  I am looking at Katana right now to compliment our USD lighting pipeline but Katana seems to lack the control I have over USD primitives in Solaris.  For example.  the lookDev tool I am making will centre objects and resize the colorchecker, balls etc based on the bounding box of the assest loaded in.  Katana (so far as I can make out with what I know) seems to be more of a "load, light and render only" way of working.  Best.  Mark