Oh and Gaffer is very very beta. On Thu, Jul 5, 2018 at 10:42 AM Tim Crowson <[email protected]> wrote:
> Katana might be overkill for that. But it’s not entirely clear > specifically what kind of work they need to do, specifically. > > Also remember that Katana doesn’t *create* 3D content, it just renders it. > Houdini would provide them with a full CG toolset if they need it. It would > also allow them to develop elements and pass them off to lighting without > having to worry about caching things out in a way that Katana likes. > On Thu, Jul 5, 2018 at 10:31 AM Jonathan Moore <[email protected]> > wrote: > >> Thanks Tim, I was really hoping that you'd have some thoughts on the >> matter. >> >> Gaffer is a real temptation especially if the client decides to give on >> the power of RenderMan for the artist centric workflow of 3Delight (which >> is really seems to have come of age recently). Unfortunately it's not >> RenderMan capable, AppleSeed, Arnold and 3Delight only. But then there's >> the equally insane price tag... of $0! Gotta love the Linux open source >> scene. ;) >> >> Good to hear your take on Katana vs Houdini. My client isn't short of TD >> talent to customise either and currently do use a customised Houdini >> pipeline but at a far smaller (advertising) scale. >> >> I'm equally taken by the elegence of CEL statements and the manner in >> which flexible templates can be built for different aspects of the >> pipeline. My core question though is whether it's overkill for the scale of >> projects an advertising agency puts though it's internal production >> resource. If the pricing was closer to ADSK or Houdini Core (FX licenses >> are limited at their facility), it would make the decision a little easier. >> >> On Thu, 5 Jul 2018 at 15:59, Tim Crowson <[email protected]> wrote: >> >>> I used Katana at MPC, and lately have been using Houdini at Method. Bear >>> in mind that my use of these products has been for feature films, with >>> medium to heavy shot content. I have not used them in any other context. >>> Bear in mind also that both platforms (because that’s really what they are) >>> require some degree of custom development to achieve efficiency in lighting >>> (as I define efficiency, at least). >>> >>> I far prefer Katana. >>> >>> In my view Katana makes it FAR easier to manage scene data without >>> losing your mind. K is also much more elegant in how it handles per-pass >>> overrides. Houdini’s options for per-ROP overrides (on things that are not >>> the ROP itself, which is vital to be able to do) are problematic for me, >>> personally. >>> >>> Katana also makes it much easier to read the state of things, simply by >>> looking at the graph. Houdini’s paradigm presents you with a bunch of >>> disconnected nodes that don’t seem to be related at all, forcing you to >>> inspect parameters to see what is going on. You adapt to that, but it does >>> create extra mental steps that have to be taken while working. One of my >>> pet peeves is the single-line string field used in the Objects tab on ROPs. >>> It’s a good deal of work to properly read that kind of field, even on mild >>> shots. It’s just a space-delineated list of paths. Translating that into >>> meaningful information takes more time than it should. >>> >>> Houdini’s takes are interesting, although the pros where I am never use >>> them because of awful past experiences. And the few times I have tried to >>> use them they bugged out and simply didn’t work reliably. Besides, at the >>> conceptual level, I don’t agree with storing scene states (or overrides) >>> abstracted from a ROP, *unless* you can combine them later. You wind up >>> making one take per ROP, which then makes me wonder why they aren’t just >>> stored on the ROP in the first place. >>> >>> Katana make sure it incredibly easy, in my view, to not only visualize >>> the data flow, but also to assetize the overrides themselves, for use >>> elsewhere or in other Katana files, combined in any way you like. >>> >>> On the lookdev and lighting fronts alike, Katana’s CEL statements >>> absolutely demolish the equivalent syntax available in Houdini. CEL >>> statements are simply more advanced and “smarter” in what they let you >>> target within a scene graph. >>> >>> For me, lighting especially comes down to efficient data management. In >>> film it’s far more technical of a discipline than people think. The >>> artistic part can be done pretty quickly. Managing how a shot is broken >>> down into layers, in a way that makes responsible use of available >>> resources, is the bigger challenge. And in my view Katana is the king here >>> (though Image Engine’s Gaffer is very similar, from what I understand). >>> >>> I have been using Houdini lately on Aquaman and I guess it’s the stress >>> of production building up, but it’s really just getting on my nerves. Seems >>> like there are far too many possible points of failure and bugs, unless you >>> design a strong custom UX front end, and that’s a lot of work. Getting >>> Katana up to production-ready status requires less development effort, in >>> my view. >>> >>> But there is that insane Foundry price tag... >>> >>> I am curious to hear from others, because my exposure to Houdini is >>> admittedly limited. >>> >>> >>> On Thu, Jul 5, 2018 at 8:45 AM Jonathan Moore <[email protected]> >>> wrote: >>> >>>> Hi all, >>>> >>>> I have a client (an advertising network with their own production >>>> facilities) that currently have a pipeline involving Maya and Houdini with >>>> RenderMan and Redshift as rendering options. There's a smattering of Max >>>> and Modo for asset creation but that's beyond the scope of my enquiry. >>>> >>>> We're currently going through the process of deciding whether Katana >>>> would be an effective tool to add to their pipeline as their are moving >>>> into longer form branded content as well as their existing advertising >>>> output. >>>> >>>> I have a major cognitive bias going into this assessment that Houdini >>>> can be used for Katana style deferred rendering workflows as well as it's >>>> FX bread and butter. Introducing Katana will come at a considerable cost so >>>> I'm wondering what others think and feel about Katana, particularly if >>>> they've already gone through a similar thought process. It doesn't matter >>>> whether you use Katana in you pipeline (or have used it in the past) I'm >>>> just looking for any considered views ref Katana benefits. >>>> >>>> And Jordi, if you're reading this, I would love your take on Houdini as >>>> a lookdev/lighting toolset as I understand that's exactly how you use it at >>>> Framestore. >>>> >>>> Funnily enough, the more deeply I research this, the more I'm reminded >>>> how ahead of the game the Softimage team were. The whole models workflow >>>> (and underlying philosophy) was incredibly flexible as well as powerful. >>>> Sure it had some gnarly aspects much like any referencing system (from what >>>> I hear, Katana it littered with these referencing cul-de-sac's too). >>>> >>>> My internal bias towards Houdini is that is has so many strengths with >>>> regard to deferred procedural loading, packed disc primitives etc etc, and >>>> to be frank, shading networks in Katana suck right now. Plus Houdini pretty >>>> much invented the nodal shading game with VOPs. >>>> >>>> As a positive for Katana, I'm really impressed with the 3delight >>>> integration, and it's promise of seamless a seamless pipe with Maya (a >>>> necessary evil not a preferred choice). I've always had a soft spot for >>>> 3delight and the new OSL driven, artist centric presentation layer/UX is >>>> something that connects with my own thoughts about delivering flexible >>>> rendering power without the need to have all the wiring on show. >>>> >>>> Apologies for the lengthy post. I'm hopping that one or two of you have >>>> gone through similar considerations as you've gradually planned your move >>>> away from Soft. >>>> >>>> As ever, thanks in advance. >>>> >>>> jm >>>> ------ >>>> Softimage Mailing List. >>>> To unsubscribe, send a mail to [email protected] >>>> with "unsubscribe" in the subject, and reply to confirm. >>> >>> ------ >>> Softimage Mailing List. >>> To unsubscribe, send a mail to [email protected] >>> with "unsubscribe" in the subject, and reply to confirm. >> >> ------ >> Softimage Mailing List. >> To unsubscribe, send a mail to [email protected] >> with "unsubscribe" in the subject, and reply to confirm. > >
------ Softimage Mailing List. To unsubscribe, send a mail to [email protected] with "unsubscribe" in the subject, and reply to confirm.
