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
