Hey Deke, (moving this to the python discussion...)
Regarding your point 2: someone at our facility has implemented a rolling autosave to an alternate directory so we no longer get that feature I quite like that you mentioned: when Nuke sees a newer autosave in the same dir, it asks the user if they want to open it instead. I really, really miss that. So, I did a bit of digging and it looks like someone added an autosave filter using nuke.addAutoSaveFilter(<callable>). In doing so it appears the autosave features in the Nuke prefs are completely disabled. The knob "AutoSaveName" has the expression: [firstof [value root.name] [getenv NUKE_TEMP_DIR]/].autosave but nothing goes there. So, I tried adding a second filter which restores the functionality I like. However, through my testing it looks like Nuke only honours *one* of the strings returned by autosave filter functions in the nuke.autoSaveFilters dict (the index 0 in the Root list?) I've added a second test function to it which prints 'foo' *AND* returns the root name + '.autosave'. I see 'foo' prints, so the code is being executed, but no autosave is made at the location given by the second function's returned filename. Also, nuke.removeAutoSaveFilter appears not to work. Has anyone else had success with it? Maybe it's time for a bug report. -Ean On Fri, Apr 19, 2013 at 8:44 AM, Deke Kincaid <d...@thefoundry.co.uk> wrote: > The autosave function in Nuke runs on the main application thread. I’m not > sure exactly why but when the Nuke files get in the 20 meg range > the Windows version has always had a considerable lag over the network > doing autosaves then linux or osx. > > A few ways to combat this: > 1. set your autosave to not be as often(every 360+ sec instead of every > 30). > > 2. Explicitly set the expression for your autosave to a folder on your > local machine instead of the network. By default it always saves to the > same location of the nuke file. The really annoying thing with this > solution is when your Nuke crashes and you open a file it won’t say “you > have a newer autosave, do you want to open it” because it is not being > saved in the same location as the original file anymore. So you have to > manually open the autosave. So not a great solution but it definately gets > rid of that lag every 30 seconds with large scripts. > > 3. If you have a cameraTracker, pointCloudGenerator, PoissonMesh, or even > large sets of roto or any other nodes which makes really big Nuke files. > Take it and make those nodes into a nuke precomp (other > Precomp). Then > the large part of your script will be a separate referenced nuke script and > not making your file size blow up. The referenced precomp will not be > constantly autosaving. If you have a heavy piece of geo from the > PointCloudGenerator then write it out as an Alembic file and read it back > in. > > ----- > Deke Kincaid > Creative Specialist > The Foundry > Mobile: (310) 883 4313 > Tel: (310) 399 4555 - Fax: (310) 450 4516 > > The Foundry Visionmongers Ltd. > Registered in England and Wales No: 4642027 > > > On Wed, Apr 17, 2013 at 5:00 AM, Fabian Fischer <i...@visualplastic.net>wrote: > >> Hello, >> >> we got a problem with the nuke autosave function. The UI gets >> unresponsive on every autosave attempt for about 10 up to 30 seconds. It is >> a larger script with 18 MB, but I think that should not be a problem >> anyway. It doesn't matter which storage device is used (We tryed everything >> from SAN, NAS to local SSD) it is always the same. >> It is Nuke 7.0v6 on Windows 7 64 bit. >> >> Any advice would be great, >> thank you, >> >> Fabian Fischer >> >> ______________________________**_________________ >> Nuke-users mailing list >> Nuke-users@support.thefoundry.**co.uk<nuke-us...@support.thefoundry.co.uk>, >> http://forums.thefoundry.co.**uk/ <http://forums.thefoundry.co.uk/> >> http://support.thefoundry.co.**uk/cgi-bin/mailman/listinfo/**nuke-users<http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users> >> > > > _______________________________________________ > Nuke-users mailing list > nuke-us...@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >
_______________________________________________ Nuke-python mailing list Nuke-python@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
