|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hello group.
I wondered what kind of features could render (pun not intended) our animations
easier.
There are certain situations where you DON'T want your animation render to
terminate, because of state dependent animations, negative clocks and rendered
file names not using the negative index for naming, and maybe other reasons.
where changing the initial_frame and initial_clock to restart from where it
stopped is not sufficient.
What i would introduce is a parse button, to the already present render, pause,
and stop controls.
The parse behaviour would be as follows :
try to parse the file at it is displayed on the editor.
In case of a parse error, the renderer will re-parse and render the file at its
last successful parse state version but with the clock running of course. and
display a colored warning, of course.
A companion feature would be : undo changes to last good parse state.
That's for today...
Have a nice day.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Hello group.
>
> I wondered what kind of features could render (pun not intended) our animations
> easier.
>
> There are certain situations where you DON'T want your animation render to
> terminate, because of state dependent animations, negative clocks and rendered
> file names not using the negative index for naming, and maybe other reasons.
> where changing the initial_frame and initial_clock to restart from where it
> stopped is not sufficient.
>
> What i would introduce is a parse button, to the already present render, pause,
> and stop controls.
>
> The parse behaviour would be as follows :
>
> try to parse the file at it is displayed on the editor.
> In case of a parse error, the renderer will re-parse and render the file at its
> last successful parse state version but with the clock running of course. and
> display a colored warning, of course.
>
> A companion feature would be : undo changes to last good parse state.
>
> That's for today...
>
> Have a nice day.
>
Every time that you re-save a scene, the previous version is renamed
with an added .bak extention. If such a file already exist, the older is
deleted before the renaming. You don't get .bak.bak nor .bak2.
What you want would result in deleting the current file, then using the
automaticaly created .bak file, remove the .bak extention and try again.
The problem is that there is only one .bak file. If you saved the scene
more than once since the last working version, that old version is lost.
Alain
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Every time that you re-save a scene, the previous version is renamed
> with an added .bak extention. If such a file already exist, the older is
> deleted before the renaming. You don't get .bak.bak nor .bak2.
>
> What you want would result in deleting the current file, then using the
> automaticaly created .bak file, remove the .bak extention and try again.
> The problem is that there is only one .bak file. If you saved the scene
> more than once since the last working version, that old version is lost.
Back when I was using single-core mcpov a lot I wrote a "launcher" for
it that would set off multiple instances on the same file (to utilise
multi-core). However it would first create a folder (named as the
filename followed by the timestamp) in which it would copy the pov file
into and put all the output images).
That was really useful for being able to go back and see the source and
result for each version. However it would not work in general as you
would need to keep a copy of all #included files and not just the one
you call to start the render.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|