Hi @pascal ,
I suppose so you got my example file. I have a new information for this issue - if I use incremental save instead save than the scene is saved in 38s instead 8:30min.
I hope the save time can be nearly so fast like incremental save.
Hi Micha - try changing the advanced setting here:
the option was disabled and I disabled it now. The save time is ~6min, still much to slow.
Hi Micha - you can also try turning off compession -
Great, this bring down the time a lot. Only could I get both - a small file size and a fast save? 8 min for compression looks like something is wrong.
Why was the incremental save so much faster than the standard save? Are not both using compression?
@pascal Something is not working properly. When I turn off compression, standard storage is fast like incremental storage, but incremental storage is much smaller than standard storage.
Simple test - I save my current project with incremental storage: after a few seconds I get 1250 MB. Now I save the file with standard memory: after a few seconds I get 1800MB.
So, turning off compression is not a solution, incremetal save shows that speed and high compression are possible in combination.
It would be nice if we could find out what is going wrong here. Or is someone else from the team the better contact?
I’m going to hasard a guess here…
The normal Rhino “Save” function works like this - for a file that has been saved at least once:
- Write a temporary file to disk
- Make sure that the temp file has been written correctly
- If so, delete the original file, and rename the temp file to the original file name
IncrementalSave, as it is saving the current state of the file as a new file, does not need to write the temp file and check/rename it to the original name afterward. It just simply saves the file. So maybe the time problem is steps 2 and 3 above, especially if the file has compression enabled.
That’s my theory at least, but I could be way off in left field.
I’m curious for someone of the McNeel team who will test it and found the reason for the big difference (save is more than 10 times slower than incremental save).
I doubt they’re seeing it, or other people would be seeing it too. I’ve never seen such a thing, I’ve seen kind of the opposite, but that was until I figured out how to make IncrementalSave use SaveSmall.
I got an idea and I did some more tests - I found the problem was that ‘save textures’ was enabled. Maybe incremental save doesn’t save textures. I suppose so the texture collecting progress is so horrible slow.
It’s a pitfall - if I open a new Rhino task and try to save the scene than ‘save textures’ is automatic enabled. Nearly never I need this function and so I must careful disable it always. I’m working on very large files and this option cause a slow down and that the hard disk is faster filled.
I’m glad to have a solution now.
@pascal Is ‘save textures’ enabled per Rhino default or is it at my machine only? I think this options should be disabled per default.
It seems to be a default for new files. Maybe it’s in the template? Yeah I don’t recommend using it by default either, yes it was years ago I was in a situation where it was ‘needed’ but it was not reliable.
I thought it was supposed to remember the last used setting…
It does for a particular file, but new files have it on by default…so maybe it’s a document setting that’s saved in the template?
Hi Micha - There used to be a setting in Document Properties… it was removed because, ‘when would you not want to save the textures?’ Well, in general, why not, but this would be a case… I still think it is the exception to have files with so many or so large textures that it is a problem. (PBRs may change that)
In the meantime, if you
-Save you can set that even after the file has been saved - is that not sufficient?
Yes, for me it’s ok to disable it all the time. It’s one more thing I have to keep in mind
I see no reason to always save the textures in a Rhino file. The textures are on my hard drive and I only save them to the file when I need to send a Rhino file with textures to a client. But that’s not necessary on a daily basis. But daily I have to save my work.
My needs are a fast save and not so big Rhino files.
Hi Micha - I guess the underlying thought is that it makes file sharing a mess if textures are not saved by default, and that would be a far more common problem.
@Micha - I understand it is a bit awkward - for now, you can make an alias or button that has
-_Save _SaveTextures=_No and click on Browse at the command line the first time a file is saved.
Sure…but it inflates file sizes (which does matter with SSDs or network locations,) leaves extraneous temp files scattered around, and my experience saving textures a while back is that sooner or later Rhino will lose track of them and you have to rebuild all your materials.
If we look at say, InDesign, which is all about linked external files and the workflow of passing things along to other people, it doesn’t normally embed anything unless you explicitly do it, and when you want to package everything up to send downstream there’s a separate command for that.
Hi Jim - I can imagine it may need fixing, but as a default, it still seems more certain to work. If I were king, I would simply restore the document setting, then it could be in a template, and for the most part we’d be done. I’ll see what we can do.
@Micha - if you use
-_SaveAsTemplate it looks like you can make a template that works as you want.
@pascal One more thought - could it be that the code for packing the textures is unusual slow? All textures are opened at the current scene. Also starting a rendering doe’s need so much time (in this case all textures are loaded too), so why is saving with textures so extreme slow?
Thank you for the hint with the template.