Auto-recovering unsaved scenes

taiuri

I make this suggestion after my Daz crashed while I was rendering and missed my scene. I think It's absolutely necessary the upcoming versions of Daz have the ability to recover unsaved scenes, same Word or Excel does. I think the Daz people has to work on this becuse it's too frustrating to miss all your work due to a "fatal error".

I'd prefer the new Daz has this ability instead of a possible "Genesis 10 figure". I really hope my suggestion is taken.

Richard Haseltine

Have you looked at the change log http://docs.daz3d.com/doku.php/public/software/dazstudio/4/change_log , or tried the current Public Build (Beta)?

taiuri

I have the 4.22 version and I was rendering on 3Delight. Suddenly the "Daz must close due to a fatal error" hated message appeared and I missed my unsaved scene. 

taiuri

I'd wish the message was: "Daz must close due to a fatal error, but don't worry, all the changes will be saved". Do you think the upcoming version comes with this ability. 

CES3D

Please read Richard's post.
The Daz Studio Public Beta already has an Auto Save feature built-in.
However, this feature is currently only available to Premier members.
(It's still Premier member only in 4.23.1.18, right?)

Or, if you are a Windows user, you can use an auto-save tool such as MikeD's Autosave Suite or matew's SaveGuard.

crosswind

CES3D said:

Please read Richard's post.
The Daz Studio Public Beta already has an Auto Save feature built-in.
However, this feature is currently only available to Premier members.
(It's still Premier member only in 4.23.1.18, right?)

Yes .... but I really expect this feature not binded to Premier tier ~~

Or, if you are a Windows user, you can use an auto-save tool such as MikeD's Autosave Suite or matew's SaveGuard.

CES3D

crosswind said:

Yes .... but I really expect this feature not binded to Premier tier ~~

This feature is just being offered to Premier members first, but let's hope that it will be available to Base members in the future. 

crosswind

CES3D said:

crosswind said:

Yes .... but I really expect this feature not binded to Premier tier ~~

This feature is just being offered to Premier members first, but let's hope that it will be available to Base members in the future. 

Okay !

richardandtracy

We can hope, but what is the probability of fulfilment of that hope?

I suspect the filtering of Premier features to the base level will be glacial or slower. Why would DAZ release items for free once they've found a way of making people pay for features other programs consider part of the package? It did happen once years ago with the general release of DS4.xPro, but that's a fair while back and there are all sorts of contra-indicators at the moment where DAZ seems to be trying to generate cash through different avenues (NFT's, AI subs for a better level of AI, and the introduction of Premier) being three such indicators. I'd be very pleasantly surprised if it happens. All I can say is, I rarely seem to be surprised.

Regards,

Richard

Richard Haseltine

crosswind said:

CES3D said:

crosswind said:

Yes .... but I really expect this feature not binded to Premier tier ~~

This feature is just being offered to Premier members first, but let's hope that it will be available to Base members in the future. 

Okay !

The first entry in the chnage log relating to AutoSave says "Initial commit of a set of “Auto Save” features for Premier members", so I think this one is a premier feature. In other cases it says "Premier members are granted early access" so there is a clear distinction between features that are a "Premier preview" and those which are simply "Premier"..

taiuri

I think this function must be available for all users, not only for members. Daz has improved so much in the last years, offering us spectacular figures, but is unable to offer us a very useful function like AutoSave. When Word crashes and you reopen the program, it offers you an Autorecovered file. I think Daz must make that too. At least in the cases where Daz crashes suddenly. 

I really hope this function is the priority for the Daz team, even over an improved Genesis new figure. I hope the upcomig version already comes with this fuction.

Richard Haseltine

taiuri said:

I think this function must be available for all users, not only for members. Daz has improved so much in the last years, offering us spectacular figures, but is unable to offer us a very useful function like AutoSave. When Word crashes and you reopen the program, it offers you an Autorecovered file. I think Daz must make that too. At least in the cases where Daz crashes suddenly. 

Saving a Word file is relatively quick and simple, it is not a useful point of comparison.

I really hope this function is the priority for the Daz team, even over an improved Genesis new figure. I hope the upcomig version already comes with this fuction.

richardandtracy

I have to disagree, saving a Word file is a valid comparison. It's not unusual for me to save several hundred megabyte Word files in a couple of seconds, which is acceptable - and Word's .docx is a zipped text based .XML file. DS takes a good deal of time to save, largely because DS takes an object, and converts every binary object's data into DSON format text to save. This, understandably, takes time.

But the time taken to convert to DSON format is totally unacceptable for an auto-recover file to take this long to save. If, on an auto-recover file (never opened by another package or computer), the decision was taken to save it as a binary file, the file save would be in excess of 1000x faster than the saving of the DSON text file, making an auto-save perfectly acceptable and barely noticeable. For info: I have experience of programming a cross stitch program, where I had a binary (new) and text (original) version of the output, and a timer I put in found the binary was regularly 1500x faster, occasionally up to 2500x faster than the text version.

Any argument in favour of maintaining DSON compatibility is entirely fallacious as it will never be used as a distribution method or even used on another machine. When did you ever even look for a Word auto-recover file? I imagine you just used it if required and thanked your lucky stars it existed. In fact, for a file deleted on normal exit from DS, the format of the file is entirely irrelevant, and a straight memory dump would be perfectly acceptable and blisteringly fast.

Additionally, the auto-recover file save could, largely, be carried out from a separate thread from the main thread. The processing impact on the main thread of DS would be almost invisible to the user, just as occurs with programs that value user data. 

Regards,

Richard.

Richard Haseltine

richardandtracy said:

I have to disagree, saving a Word file is a valid comparison. It's not unusual for me to save several hundred megabyte Word files in a couple of seconds, which is acceptable - and Word's .docx is a zipped text based .XML file. DS takes a good deal of time to save, largely because DS takes an object, and converts every binary object's data into DSON format text to save. This, understandably, takes time.

But the time taken to convert to DSON format is totally unacceptable for an auto-recover file to take this long to save. If, on an auto-recover file (never opened by another package or computer), the decision was taken to save it as a binary file, the file save would be in excess of 1000x faster than the saving of the DSON text file, making an auto-save perfectly acceptable and barely noticeable. For info: I have experience of programming a cross stitch program, where I had a binary (new) and text (original) version of the output, and a timer I put in found the binary was regularly 1500x faster, occasionally up to 2500x faster than the text version.

Any argument in favour of maintaining DSON compatibility is entirely fallacious as it will never be used as a distribution method or even used on another machine. When did you ever even look for a Word auto-recover file? I imagine you just used it if required and thanked your lucky stars it existed. In fact, for a file deleted on normal exit from DS, the format of the file is entirely irrelevant, and a straight memory dump would be perfectly acceptable and blisteringly fast.

Additionally, the auto-recover file save could, largely, be carried out from a separate thread from the main thread. The processing impact on the main thread of DS would be almost invisible to the user, just as occurs with programs that value user data. 

Regards,

Richard.

So you want two file formats? or at least two data-handling routines? That isa ssuming that the formatting is the slow part of the process, and not the preparing of the data for writing in a form that can be read back in to a new session.

richardandtracy

Having experience of such things myself, yes I am making some assumptions. However, as those assumptions are based on my own programming, I'm comfortable that the data I gathered before making that assumption is soundly based. If, however, you have contradictory evidence to show my experience is wrong, please present it, I am always willing to learn. It's my experience that it's the whole process of creating and saving strings of text to save text files that takes so much longer than saving the binary data rather than simply the formatting of the text. Regards, Richard.

Richard Haseltine

It may well take longer, but it may wel be a relatively minor factor given the relative complexity of the task at hand.