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
