Sad Fish says, "Save often"

[Rodney]

It's always a good idea to save your files... that and close all the hundreds of other programs you've forgotten to close... you know... to free up memory.

 

I think this guy was anticipating what was about to happen to him so I took a screen shot of the only thing left of him when things went south.

 

So, don't forget to save your work!

 

P.S. I'm still waiting for Windows to notify me of the solution.

[Fuchur]

...activate autosave in the settings...

and still save different versions...

[Wildsided]

Ah yes that classic A:M seems to have stopped doing anything....I'm sure it's nothing....wait did I save?.....NONONONONONONONONONONONONO!

[robcat2075]

Maker it do that again, Rodney, and send it in as a bug report!

[johnl3d]

Good thing it wasn't user error......

[Rodney]

Good thing it wasn't user error......

 

Well, the keeping open of hundreds of programs could technically be classified as user error so there is that.

 

I would say that an 80% solution to all the 'stablilty' probems I would directly attribute to A:M still relate to user error in that I forget to save just prior to rendering (or something similar). I've thought that if I could narrow the variables down a bit more I might submit a feature request or two which might be as follows:

 

- Upon initiating final render; have A:M prompt for files to be saved if they haven't been saved prior to rendering.

In other words, if any files in the project are 'dirty'... that is to say that they haven't been saved... then the dialog wouldn't appear and A:M would move on to rendering.

This would be a welcomed feature in that once we launch a render we are committed to rendering and if something goes wrong at this point we've lost everything that hasn't been saved.

 

- This, the Sad Fish error ™, wasn't related to final rendering but more likely to having the Render Lock icon toggled on. This is where some R&D on my part might prove beneficial because forgetting to toggle that off (by a simple hit of the Escape key in most cases) has led to many a pitfall... to include changing settings only to discover those settings haven't changed because Render Lock was on. This too could be classified as 'user error' because it relates to a specific workflow that I use consistently. If however, most A:M Users use a similar workflow they also may be running afoul of these errors. Bottom line: if you frequently make changes to settings only to find them later to be unchanged it may be related to Render Lock being engaged.

 

I acknowledge that a backup or saving of files is the ideal but preventing the crash in the first place would be even more ideal.

The two things I could do to solve my own problem would be:

1. Restart my computer more often (as this would force me to close a whole lot of programs that are needlessly using memory)

2. Use the 64bit version of A:M more frequently (as the 64bit release can utilize more memory).

[Rodney]

I am curious about others workflow with regard to Render Lock.

Do most folks just use the Q shortcut key to evoke the standard Render Mode instead?

 

At issue is that anything that invokes the raytracer causes a lag that prevents returning control to the UI.

Render Lock definitely invokes the (long form) raytracer.

[robcat2075]

I am curious about others workflow with regard to Render Lock.

Do most folks just use the Q shortcut key to evoke the standard Render Mode instead?

Q for standard, Shift-Q for Render lock

 

 

At issue is that anything that invokes the raytracer causes a lag that prevents returning control to the UI.

Render Lock definitely invokes the (long form) raytracer.

 

 

I find that when there is some significant render item (like hair) it can take a while for the first pass to start and the UI will appear frozen while does its thinking and frequently during the remaining render until it reaches 100%.

 

You can Escape out of a long render, but it may take a while for that keystroke to get processed also.

 

When I know a complex render is likely I will test as small a portion of the screen as I can, with right-drag.

[Rodney]

Yes, but how to avoid that?

 

I'm somewhat answering my own question here by trying out some things to force a different workflow.