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
