ZBrushCentral

quicksave SEEMS to be causing crashes

ZBrush Usage Questions
#1

hi,

this one is really p*ssing me off - I’m experiencing regular crashes which seem to be coincidently timed with a quicksave trying to be run. Sometimes I’ll have two or three crashes in a day, and started noticing that my last qs was a good way back in the progress of the sculpt. I started checking the times and noticed that the last qs following a crash was created almost exactly 20 mins before. So I’m hazarding a guess that it’s that that’s the cause.

It’s ridiculous if this is the case - that you have to continuously remember to save to protect yourself from the automated save messing up! If you have a couple of hours for a concept sculpt, being thrown back 20 mins, plus the time it takes to gather yourself and pick up is a huge setback. Especially when it happens twice in a row, which I’ve been unfortunate enough to suffer.

ZBrush has got more and more unstable with recent releases. Non more so than this one. It feels as if it relies far too heavily on paging data in and out of virtual memory and not enough on RAM. I’ve also had crashes and complaints involving ‘cant read VM file’ ‘disk space is almost full’ (only 80gb on the system drive ZBrush, and a separate dedicated 25gb raid just for you) and other memory related errors.

Add to that; ZBrush appears to try and run the QS even if it’s in the middle of other tasks such as remeshing or rendering.

In my experience at least, this QS function seems to be creating the very instability it’s supposed to be guarding against.

Anyone else agree/disagree?

#2

I’ve seen it try to save when I wasn’t ready yet at least once. I changed the setting to max in Preferences. I save out .zpr and .ztl files on a regular basis. Haven’t had as large a problem as you seem to be having.

#3

Yes Autosaving it´s not very usefull when working. You can change the period of autosave in Preferences>QuickSave>Maximum duration slider to max. Remember to Store COnfig after doing that to have it in your master configuration

#4

Maybe my setup is a little flakey these days Doug. But it does seem that there’s a problem with it, as you’ve both suggested.

It should be made to take a back seat, or have a countdown timer like 3dcoat (a bit more visible tho).
I’ve maxed the timer out too - but good point on the save config 4Z! I’d forgot to do that! =0

#5

I do find Auto-Save a bit intrusive on the default settings. It’s not an issue with small files, but when working with massive projects where the save times are increased, it becomes annoying.

I don’t notice any particular instability related to auto saving on a regular basis. There can always be extreme situations.

I do not find Zbrush to be any less stable over all than previous 4rx versions. I actually find it to be better at coming back from long periods of inactivity, being out of window, and long term memory management seems better to me. I think nothing about just leaving it idle for hours and coming back to work in it, something that would have massively increased instability in previous 4rx versions. Granted I did have a problem with my installation at one point that caused the program to be wildly unstable when using specific functions, but a reinstall fixed that.

As always, it just depends on what you’re doing in the program, and on the particulars of your system hardware/software configuration. Certain functions are more prone to error than others. I regularly work in my bread and butter sculpting routine for 12 hour sessions with no interruptions, sometimes days in a row. When performing other tasks in the program I save much more frequently and expect occasional problems.

One thing I developed early on, though, was rigid save discipline when working in any 3d programs. I save often, manually, in alternating files. I would never rely on an autosave except as a last resort. As you point out, they do have the potential for initiating during a user action which increases the potential for corruption.

If you really feel you’re experiencing crashes due to autosaving, I would simply disable it altogether by maxing out the Max Duration and Rest Duration sliders in the Preferences> Quicksave menu, and storing the config. If that improves the situation, then you know there is a link to the function in your particular installation, and you should report this to Support along with pertinent system info so they can look at it.

#6

Autosave is a great feature but I will never rely on it 100%. My work is too critical and I can’t lose it. I use autosave but like Spyndel I have a strict saving habit that I learned long ago and that will never change. Not just 3D but any major (even minor) projects should be saved in a way that’s easy to recover from errors or problems that can occur with digital data. Time is money and I can’t afford to lose my work or creativity.

#7

I’ve never had these ‘can’t read VM file’ or other memory related errors until recently Spyndel. when I started using ZB around the 3/4 change era I never experienced crashes at all. Maybe it’s my system, but personally I think the autosave and undo slider tax the virtual files a lot more than in the past.

I’m not relying on the autosave either mfrog, but if I have to remember to save every 15 mins in case the autosave crashes the system, what’s the point?

I do hit the quicksave when I remember to before bigger tasks - as far as I can see that’s probably as usuful as an alternating file save. Though when you’re in mid flow it’s easy to forget both to save and the time that’s passed.

I fully understand the importance of saving, and that the protection of work is your own responsibility to point. I mentioned it here to see if anyone had similar problems. The one thing that’s agreed on is that the max duration save is intrusive - so it wants changing.

#8

Again, I’m not doubting that you’re experiencing issues, only informing you that I don’t experience what you describe. Zbrush can demonstrate different behavior on different systems, across different installations. I was previously experiencing consistent crashing behavior when using certain functions, but a reinstall fixed it.

Autosave intervals can be adjusted in the preferences, or disabled altogether.

If you disable Autosave and your issues go away, then that suggests a link on your system, and you should probably contact Support with pertinent information. There’s nothing else we can do for you here.

#9

I don’t wish to sound argumentative Spyndel. That’s not my intention at all :slight_smile: just putting my opinion across quickly to get an response back. I don’t mind to the point answers on forums - sorry if I seem brusque.

I’ve cranked the max duration up - but something else I noticed: a fresh opening of ZB has my maxed out limit on the QS slider, but an “init zbrush” sets it back to 20mins… this is not good -definitely something I’ll point out to Support. Hopefully something will be done about the intrusive behaviour of QS too - it’s a relatively new feature so I’m sure it’ll be refined with new updates :slight_smile:

#10

Initialize Zbrush is supposed to set Zbrush back to its defaults. That’s the point of it. As long as you don’t then store that config it should load with your stored configuration the next time.

In order to disable Autosave, you must max out both the Max Duration, and the Rest duration sliders in Preferences> Quicksave, and then Store the config with Preferences> Config> Store Config.

#11

ah OK - my bad. I assumed it set it back to your personalised settings. thanks

I wish Pixo were a little more clear on what’s reset/retained - according to their help file, ‘all palettes and document data are reset’. It says nothing about preferences and, as it keeps my custom UI but resets the maxed out slider that’s saved in my store>config. it’s misleading on a number of points

#12

The default UI can always be found in the scrolling list of UIs in the top right edge of the program window.

Good Luck! I hope you get your issues sorted.

#13

The default UI can always be found in the scrolling list of UIs in the top right edge of the program window.

sure - what I’m saying, is that init zbrush only resets parts of the software back to defaults. It resets some palettes but not other areas of the UI. It doesn’t state that it resets preferences, yet it does.

Again, not to sound argumentative, just discussion:) - I can’t see what reason there might be to reset to default prefs, unless I was having trouble; in which case the standard is to trash the file. I don’t know of any any other software that defaults preferences in this way.

Also - I was taught (perhaps wrongly) that ZBrush doesn’t have a ‘new’ command as such, and the standard way of starting afresh without a restart is to ‘init zbrush’ - I’m now changing my mind on this one…