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
