I have run into this issue my self, difference being is I have had it on both 
window and linux

I also placed the auto save interval up in time about 180 seconds, you really 
feel the longer delay in auto save when you have a crash and loose more work.

I like the idea of setting auto save to a local location and expansion on this 
Idea it would be possible I should think that you could set up some sort of 
auto sync thing with a third party app to sync the local file to the server, 
but thinking that though a bit more you would have to change the sync to 
location with every shot or project you worked on.

-adam


On 19/04/2013, at 10:50 PM, Fabian Fischer <[email protected]> wrote:

> ok, thank you, so we can stop looking for bottlenecks in our pipeline.. and 
> maybe give linux a shot.
> 
> Fabian
> 
> Am 19.04.2013 09:44, schrieb Deke Kincaid:
>> 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 <[email protected]> 
>> 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
>> [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