Still recovering from last night here. What’s your excuse? ;)
-Nathan
From: Bill Gilman
Sent: Saturday, March 31, 2012 10:43 PM
To: Nuke user discussion
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
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_______________________________________________
Nuke-users mailing list
[email protected], http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users