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

Reply via email to