Jump to content
Hash, Inc. Forums
Sign in to follow this  
bubba

Overwriting existing files

Recommended Posts

I have noticed for a long time (well version 15/16) that render to file allows you to overwrite an existing file without warning. I would think that normal programming standards and practices would frown on this. I would consider this a "bug" but perhaps there are reasons why this happens. Is it worth discussing?

Share this post


Link to post
Share on other sites

In the PC version, you get a prompt when you try to save over an existing file, allowing you to cancel the operation if you want.

Share this post


Link to post
Share on other sites

Have you never, ever gotten an existing file warning?

Share this post


Link to post
Share on other sites

I am only speaking about Render-to-File. No I have never gotten a file warning. I cannot be sure about saving models, choreographs, etc.

Share this post


Link to post
Share on other sites
I am only speaking about Render-to-File. No I have never gotten a file warning. I cannot be sure about saving models, choreographs, etc.

 

On the PC, for everything OTHER than render to file, if you try to do "save AS" and use an existing filename - one will get a warning. If you do "save" - you do not get a warning. This is how it should be

 

I believe the reason for not issuing a warning for render to file to existing file name is probably related to re-rendering to image sequences, as well as any netrender (batch like) issues. It would be more complicated to then have to have a setting to turn off the warning when doing any "batch like" rendering.

 

I vote for leave it alone. Change inevitably means silly PIA bugs, wasting Steffen's time, no matter how trivial you may think the change is.

Share this post


Link to post
Share on other sites

In A:M we (generally) want to overwrite files while rendering.

This is the default setting to facilitate the rendering of large quantities of sequential images.

 

Of course we can change this default.

We have full control to change the default filename and render out to something else.

 

While I've never added the feature request to A:M because it would require a rewrite of the rendering pipeline, I have discussed here in the forum the idea that A:M should ALWAYS AND WITHOUT FAIL render to the same file(s) and location. Bear with me here...

 

The primary thought is that if optimization is gained through the reduction of variables then reducing all variables to a singularity will tend to maximize that optimization. This then creates a single point of reference for a user to expand and extend upon while ALWAYS ensuring the last images rendered are immediately retrievable (i.e. until the next rendering these images are always available and any manipulation of a rendered image should be conducted on copies of the original. Such a pipeline of copied (proxy) images would facilitate many improvements and optimizations to include backup through customizable user settings. Further interface optimizations could be gained by working with the proxy images as A:M could reference the proxy images in realtime unless the fully rendered (larger) images were specifically referred to by the user. As a by product of this process additional workflow enhancing processes could be fielded. Consider... rendered images that automagically appear in the Library's Image tab where they can be immediately referenced for use.

 

At its core I think A:M already does this but my thought is to further extend and optimize that functionality.

Netrender is key to this.

 

Overwriting existing files is not only the default it is also the optimization.

The user can and should customize A:M to personalize their rendering experience.

Share this post


Link to post
Share on other sites
A:M should ALWAYS AND WITHOUT FAIL render to the same file(s) and location. Bear with me here...

I wouldn't like that at all. I like defining where to save renders in the camera in my project. I often work with several different projects in a single sitting and if I forget to move the previous renders out of the predefined folder before I start a new render, that would be disastrous. I really like it the way it is now.

But ... if the "Open Animation" button would open the directory holding the last *rendered* movie instead of the last *opened* movie, my life would be complete ... almost :)

Share this post


Link to post
Share on other sites

I just noticed your response to this Holmes. Regarding A:M always rendering to one location you said...

 

I wouldn't like that at all. I like defining where to save renders in the camera in my project

 

I am obviously such an utter failure at explaining this that I need to draw pictures. Most rational people would stop at "always render to one place" and miss the point of the thing. My error, not the readers. If it becomes necessary I'll create a video of what success might look like. Importantly, even though A:M would render to one place *always* that would not change the users ability to set additional rendering defaults as we do now. It's one of those win-win situations. :)

 

I equate this with what is going on underneath the hood of a tricked out racing car... I don't need to know what is going on under the hood but someone certainly does!

 

Shhh... super secret Indy 5000 stuff ahead... don't let any of this get out or it'll give the other cars unfair advantage. (We want that advantage for ourselves)

To my way of thinking there are two prime areas of interest here; location and format. These are by necessity independent.

When optimizing and reducing variables to obliterate time and space however it's important to consider their relationships.

 

Of the two which is most important?

 

Which is more variable?

 

Which can be optimized more fully with the least amount of effort?

 

Importance is in the eye of the beholder. It's a judgement call filled with variables and preferences.

Best to leave that to the driver to determine when appropriate. Just-in-time pitstopping is known to work effectively.

 

Of the two there is a limited set of locations anyone will choose from while there is an infinitely broad range of formats.

It's hard to lock in only one format... one might even be added, change or become obsolete today... so best not to attempt ultimization of formats yet.

 

So location is the winner here by default.

Truth is, it was never a fair contest.

 

So what can A:M gain by rendering to one location? (It also might be good to include what could be eliminated)

Speed (Time)

Filesize (Space)

Uneccessary Usage of Resources (Waste)

 

Waste is primarily in the realm of Formatting so we'll use Location to eradicate the waste.

 

For argument's sake, let us imagine for a moment that A:M always rendered to the EXR format.

 

What are the benefits?

 

What are the constraints?

 

We can run this same exercise with all of the image formats and discover each has it's own particular weakness and strength.

Yet another reason why most would suggest locking in one format is a bad idea. (More on this later?)

 

Have users ever accidentally tried to render to a location that could not be accessed?

I'll answer in the affirmative on that! Read only directories, CDROMs, previously rendered files (OS's usually, but don't always, prompt you before they let you overwrite those things).

All of these 'user errors' represent wasted time.... unaccessible space... each of which is attributed to the tally of delays in getting images rendered.

 

Let us reconfigure.

What is the fastest format to render to?

Who takes the time to considered this?

What format is best/fastest with Multipass On? Renderosity with crazy-high number of rays cast? Nothing except the default settings?

The errors in a rendering benchmark are directly proportional to the number of differing variables.

Apples vs Oranges but only the benchmark setter wins that race.

 

And what of maximum throughput? (I speak of getting all A:M Users past the finish line here)

What is optimized for one person may not be optimal for the remaining 99.999%

No, A:M should not be ultra-optimized exclusively on only one user's favorite set of variables.

(For Mark Largento and Trekkies: this is one of those cases where the needs of the one should not (by default) outweigh the needs of the many)

 

So, why have only one racer win when thousands... potentially everyone... can win instead?

These kind of results can only occur by radically changing the race itself.

But here it helps to understand what race you've entered into.

 

If the goal is to complete the race in the shortest time possible stop circling the track 500 times before you get to the finish line. Wave that flag at one lap instead.

Zoom! You've just saved everyone in the bleachers the equivalent of a century in combined man days where they could enjoy (and attend) other races.

So we discover there are many ways in which rendering is not like a typical race and that this is simply my long winded way of saying that while Format does count, most are completely unnecessary.

 

I'm going to skip the final argument (mostly because I don't know what the future will bring and have little confidence in my ability to bring it to fruition) and move on to where we are today. In case of a tie breaker between Time and Space I will probably yield to Time any day. Even though most of everyone's time no matter the occupation is utterly wasted. In life... unlike rendering... it's the journey that counts, not the destination.

 

I'm reasonably certain A:M already performs in the way I'm talking about already.

Consider that A:M does not render directly to a image file format but rather renders out bits and bytes to a temporary location. Once a successful render is confirmed a header (and possibly footer) is slapped on the whole thing and it's given a filename the OS can recognize and display and it is saved in a designated place. (Note: Some formats require additional interpretors in order to be read by the OS) In principle if not in effect, the renderer already renders to a single solitary location. We can of course change where that file will be saved.

 

So to return to the initial idea. Having the renderer *always* render to the same location doesn't change anything, and yet understanding how to take advantage of this fact (potentially) changes everything. But how do we transform all of that stored and untapped potential into useful visual displays while conserving energy and preventing waste?

 

It's an excellent question with an answer near-perfectly fixed within an optimal timeframe dictated by ideal placement.

I'm still considering where and when that is.

 

 

(In reading back I see so many errors and omissions in what I've said. I'll leave it that way for now. I may attack it again for purposes of clarity.)

Share this post


Link to post
Share on other sites
Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...