Gus, 4, and Wiley, 2 Their roto skills aren't yet quite what they should be...
On Mar 31, 2012, at 10:53 PM, Nathan Rusch wrote: > Still recovering from last night here. What’s your excuse? ;) > > -Nathan > > > From: Bill Gilman > Sent: Saturday, March 31, 2012 10:43 PM > To: Nuke user discussion > Subject: Re: [Nuke-users] global proxy format setting? > > But of course… please forgive my California-centric solipsism, and here's a > little gem from my time down at Weta: > > "When you're working 7 days, every night is a Friday night!" > > On Mar 31, 2012, at 10:25 PM, Ron Ganbar wrote: > >> It's Sunday morning here, which is working day here... :-) >> >> R >> >> On Apr 1, 2012 7:42 AM, "Bill Gilman" <[email protected]> wrote: >> What are all you people doing responding to this thread on a Saturday >> night?!? >> >> This is what's wrong with VFX, right here. ;-) >> >> I agree that every approach has it's own set of problems. We're doing 4K >> stereo with LOTS of iterations and creative changes in versions. It's more >> important for us to get rough iterations than finished work, at least at >> this stage. I'm sure there will be version issues, but we're trying to take >> the step to the next level as a facility so we're trying to standardize >> basic parts of the pipeline. Using proxies is kind of a live QA of our >> system in other ways. Truth be told, as soon as something looks too soft to >> the wrong person, I'm sure we'll have to bump everything up to 4K. 'Til >> then, however… >> >> >> >> On Mar 31, 2012, at 9:23 PM, Nathan Rusch wrote: >> >>> Hugo: It’s definitely easy to initially set such a system up from a >>> development standpoint, but when you start getting into situations where >>> versions of comp input sequences (mattes, paint work, lighting/fx renders, >>> etc.) are iterating rapidly and concurrently, having to ensure that all the >>> input sequences are synchronized to their local counterparts is more >>> trouble than it’s worth. >>> >>> Even if, for example, you forcefully disable proxy mode when a comp renders >>> on the farm, you can still run into edge cases where the artist has been >>> working in proxy mode, but what they have been looking at is outdated, so >>> you end up potentially wasting a fairly significant chunk of farm time. Now >>> in theory this SHOULDN’T happen if you keep a properly-versioned output >>> pipeline, but that doesn’t mean it won’t, and things like this ALWAYS go >>> wrong in crunch. Plus, since artists are working on multiple shots and will >>> likely switch between 3 or 4 before lunch, they almost certainly won’t >>> remember what versions of everything were synced when for which shots. >>> >>> Having been there and back (at a small, maneuverable studio, no less), this >>> is based on my experiences, so obviously, different people will have >>> different approaches and opinions. Because central storage is the pretty >>> much the most important part of your studio, it just seems like a better >>> investment to put money into improving its performance and network layout >>> than to spend developer time and money maintaining a compromise/workaround >>> solution. Simple things like avoiding layered EXRs and other >>> performance-averse formats like TIFF, managing compression and bit-depth >>> settings intelligently to make good use of existing storage, and tuning >>> your network filesystem appropriately can all go a long way. >>> >>> >>> Ron: >>> os.path.realpath(os.path.join(nuke.root()['project_directory'].value(), >>> read['file'].value())) >>> >>> >>> -Nathan >>> >>> >>> From: Ron Ganbar >>> Sent: Saturday, March 31, 2012 8:52 PM >>> To: Nuke user discussion >>> Subject: Re: [Nuke-users] global proxy format setting? >>> >>> Basically you are all talking about a custom Read node that is tied to your >>> project / sequence / shot setup and that has all these functions built in. >>> In that case a lot of this becomes vert practical. The Read node can make >>> local copies and use them if they exists, and read from the Network if they >>> don't. I used a setup like this several times (even back in Shake days) and >>> it works very well. >>> On a small studio scale, I just never saw anyone put the effort in to do >>> this properly. This is when it becomes a pain in the backside. >>> >>> Incidentally, in case you are using the Project Directory path in the >>> Project Settings panel, then use a ./rest/of/my/path/seq.%04d.dpx how do >>> you resolve this easily via python? >>> >>> >>> Ron Ganbar >>> email: [email protected] >>> tel: +44 (0)7968 007 309 [UK] >>> +972 (0)54 255 9765 [Israel] >>> url: http://ronganbar.wordpress.com/ >>> >>> >>> >>> On 1 April 2012 06:43, Hugo Leveille <[email protected]> wrote: >>> How do you find it impractical? Having a script that copies the network >>> file to a local raid and set it in proxy path is quite practical and easy >>> to manage, not matter how many artist, no? Unless I misunderstand you. >>> >>> Id like to have your view on this. >>> >>> Thanks >>> >>> Sent from my iPhone >>> >>> On 2012-03-31, at 11:30 PM, "Nathan Rusch" <[email protected]> wrote: >>> >>>> Yeah, localizing files is definitely nice (preferable to proxies like you >>>> said), but it becomes rapidly impractical once you exceed a certain number >>>> of artists. >>>> >>>> -Nathan >>>> >>>> >>>> From: Hugo Leveille >>>> Sent: Saturday, March 31, 2012 8:24 PM >>>> To: Nuke user discussion >>>> Subject: Re: [Nuke-users] global proxy format setting? >>>> >>>> What you'll want more often than other is a 1:1 local version of a network >>>> file. Not a mixed resolution >>>> >>>> Sent from my iPhone >>>> >>>> On 2012-03-31, at 11:20 PM, "Nathan Rusch" <[email protected]> >>>> wrote: >>>> >>>>> Once you cross that nebulous critical point where you go from using >>>>> proxies occasionally to regularly, chances are you’re thinking about >>>>> writing scripts/tools to handle it automagically. >>>>> >>>>> In your example, it would be possible to parse out the resolution string >>>>> from the image path, but the easier choice would be to simply hand Nuke >>>>> the path to the proxy sequence and let it set the format for you (using >>>>> read['proxy'].fromUserText('/my/proxy/path')). This would also let you to >>>>> work with a more generalized directory structure. An extremely simplified >>>>> example would be something like: >>>>> >>>>> /pfcluster/Alphaville/PRODUCTION/01_joyluck/RENDERS/3D_ELEMENTS/joyluck_lightTex_v019_ln/LaserGlow/full/joyluck_lightTex_v019_ln_LaserGlow.####.exr >>>>> >>>>> /pfcluster/Alphaville/PRODUCTION/01_joyluck/RENDERS/3D_ELEMENTS/joyluck_lightTex_v019_ln/LaserGlow/proxy/joyluck_lightTex_v019_ln_LaserGlow.####.exr >>>>> >>>>> This way you won’t need to worry about doing any parsing, and can just >>>>> set the proxy knob if that directory exists, or leave it blank otherwise. >>>>> >>>>> To be honest, however, proxies are enough of a pain that the benefits >>>>> rarely outweigh the potential for mixups and mistakes, even >>>>> at 4k and above. >>>>> >>>>> -Nathan >>>>> >>>>> >>>>> From: Bill Gilman >>>>> Sent: Saturday, March 31, 2012 6:39 PM >>>>> To: Nuke user discussion >>>>> Subject: Re: [Nuke-users] global proxy format setting? >>>>> >>>>> Hi Hugo >>>>> >>>>> First off, thanks for the code. It doesn't seem to be working for me but >>>>> maybe it will after you get a chance to play with it. >>>>> >>>>> Out of curiosity, how hard would it be to parse, say, a resolution >>>>> directory and change it to the proxy res? Would this be best done with >>>>> TCL or Python? eg.: >>>>> >>>>> /pfcluster/Alphaville/PRODUCTION/01_joyluck/RENDERS/3D_ELEMENTS/joyluck_lightTex_v019_ln/LaserGlow/4096x3112/joyluck_lightTex_v019_ln_LaserGlow.####.exr >>>>> ^ ^ ^ >>>>> >>>>> would become >>>>> >>>>> /pfcluster/Alphaville/PRODUCTION/01_joyluck/RENDERS/3D_ELEMENTS/joyluck_lightTex_v019_ln/LaserGlow/1024x778/joyluck_lightTex_v019_ln_LaserGlow.####.exr >>>>> ^ ^ ^ >>>>> >>>>> But my real question is: everybody has to do this with shots they're >>>>> using proxies for? That seems really nuts to me. I can't imagine >>>>> everyone has automatic scripts to do this sort of thing. >>>>> >>>>> Here's to it >>>>> >>>>> Bill >>>>> _______________________________________________ >>>>> Nuke-users mailing list >>>>> [email protected], http://forums.thefoundry.co.uk/ >>>>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >>>> _______________________________________________ >>>> Nuke-users mailing list >>>> [email protected], http://forums.thefoundry.co.uk/ >>>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >>>> _______________________________________________ >>>> Nuke-users mailing list >>>> [email protected], http://forums.thefoundry.co.uk/ >>>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >>> >>> _______________________________________________ >>> Nuke-users mailing list >>> [email protected], http://forums.thefoundry.co.uk/ >>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >>> >>> >>> _______________________________________________ >>> Nuke-users mailing list >>> [email protected], http://forums.thefoundry.co.uk/ >>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >>> _______________________________________________ >>> Nuke-users mailing list >>> [email protected], http://forums.thefoundry.co.uk/ >>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >> >> >> >> _______________________________________________ >> Nuke-users mailing list >> [email protected], http://forums.thefoundry.co.uk/ >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >> _______________________________________________ >> Nuke-users mailing list >> [email protected], http://forums.thefoundry.co.uk/ >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users > > > > _______________________________________________ > Nuke-users mailing list > [email protected], http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users > _______________________________________________ > Nuke-users mailing list > [email protected], http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
_______________________________________________ Nuke-users mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
