I like your positive thinking, Bill. R On Apr 1, 2012 8:53 AM, "Nathan Rusch" <[email protected]> wrote:
> Still recovering from last night here. What’s your excuse? ;) > > -Nathan > > > *From:* Bill Gilman <[email protected]> > *Sent:* Saturday, March 31, 2012 10:43 PM > *To:* Nuke user discussion <[email protected]> > *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 <[email protected]> >> *Sent:* Saturday, March 31, 2012 8:52 PM >> *To:* Nuke user discussion <[email protected]> >> *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 <[email protected]> >>> *Sent:* Saturday, March 31, 2012 8:24 PM >>> *To:* Nuke user discussion <[email protected]> >>> *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 <[email protected]> >>> *Sent:* Saturday, March 31, 2012 6:39 PM >>> *To:* Nuke user discussion <[email protected]> >>> *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
