I just put 3.7.37a on a computer that had always been running 3.6. I just
started outputting the debug information to a file (to confirm what values were
used per frame since I am making MANY frames and wanted to know what values
cause bad looking frames).

In 3.6 each "block" of debug information was written into the debug.txt (the
filename I am outputting to) sequentially, with each frame appending to the
content already there. So I was able to look through the debug values for the 10
sample frames I rendered (only 10 at the time) and everything was listed. I even
added extra debug text to help separate the frame output because of this
feature. The entire file was overwritten if I restarted another sample run
(which is preferred for my needs).

I just installed 3.7.37a earlier today and ran the same .pov file with the same
options. Now the debug.txt file is created but the information is contained with
each frame. So if I let it finish the entire sample, I will only have the values
for frame 10 not the other 9 (which is needed).

So my question is this:
Is this an EXPECTED feature change or is this a bug I should put into Flyspray?

I did searches but did not find anything that seemed to relate to this, but I
might have missed it.

Post a reply to this message

Am 05.05.2010 19:19, schrieb fillibar:

> I just installed 3.7.37a earlier today and ran the same .pov file with the same
> options. Now the debug.txt file is created but the information is contained with
> each frame. So if I let it finish the entire sample, I will only have the values
> for frame 10 not the other 9 (which is needed).
>
> So my question is this:
> Is this an EXPECTED feature change or is this a bug I should put into Flyspray?

Let's put it this way: If I was in your place, I'd consider it undesired 
behavior at any rate; so do feel encouraged to enter it into Flyspray as 
a "possible bug". If it turns out to be an intended feature, the entry 
can still be re-categorized as a change request.

Post a reply to this message

I suspect it is intentional (and is the result of enforcing that #fopen w/
"write" re-create the file at all times, as the old behavior probably also led
to unwanted results in different situations).

The options are to either implement a fourth type of file access for #fopen
that's essentially "write on first frame, append on all later frames", or to do
it manually in your scene.

Post a reply to this message

Am 06.05.2010 01:50, schrieb MDenham:
> I suspect it is intentional (and is the result of enforcing that #fopen w/
> "write" re-create the file at all times, as the old behavior probably also led
> to unwanted results in different situations).
>
> The options are to either implement a fourth type of file access for #fopen
> that's essentially "write on first frame, append on all later frames", or to do
> it manually in your scene.

Maybe I misunderstood; I thought this was about #debug output being 
redirected to a file.

Of course, if it is about #fopen, then using "#fopen ... append" instead 
of "#fopen ... write" should do the trick (except for the first frame, 
which should use "write" instead to erase the old contents).

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 06.05.2010 01:50, schrieb MDenham:
> > I suspect it is intentional (and is the result of enforcing that #fopen w/
> > "write" re-create the file at all times, as the old behavior probably also led
> > to unwanted results in different situations).
> >
> > The options are to either implement a fourth type of file access for #fopen
> > that's essentially "write on first frame, append on all later frames", or to do
> > it manually in your scene.
>
> Maybe I misunderstood; I thought this was about #debug output being
> redirected to a file.
>
> Of course, if it is about #fopen, then using "#fopen ... append" instead
> of "#fopen ... write" should do the trick (except for the first frame,
> which should use "write" instead to erase the old contents).

No, it is about directing #debug output to a file, the "Debug_File=" command
used in a .ini. I will open a bug about it since my feeling is that if you are
wanting debug information you probably would want it for the entire duration of
a render not just a single frame (if you are making more than one). In the
meantime I will also take a look at #fopen as an alternative.

Post a reply to this message

"fillibar" <nomail@nomail> wrote:
> clipka <ano### [at] anonymousorg> wrote:
> > Am 06.05.2010 01:50, schrieb MDenham:
> > > I suspect it is intentional (and is the result of enforcing that #fopen w/
> > > "write" re-create the file at all times, as the old behavior probably also led
> > > to unwanted results in different situations).
> > >
> > > The options are to either implement a fourth type of file access for #fopen
> > > that's essentially "write on first frame, append on all later frames", or to do
> > > it manually in your scene.
> >
> > Maybe I misunderstood; I thought this was about #debug output being
> > redirected to a file.
> >
> > Of course, if it is about #fopen, then using "#fopen ... append" instead
> > of "#fopen ... write" should do the trick (except for the first frame,
> > which should use "write" instead to erase the old contents).
>
> No, it is about directing #debug output to a file, the "Debug_File=" command
> used in a .ini. I will open a bug about it since my feeling is that if you are
> wanting debug information you probably would want it for the entire duration of
> a render not just a single frame (if you are making more than one). In the
> meantime I will also take a look at #fopen as an alternative.

My fault, I misunderstood what you were doing (mostly because I forgot
Debug_File exists :-/).

Still, I suspect that someone probably made a similar change in the source to
what I'd mentioned, and instead of "create on first frame, append on all later
frames" (ideal) or "append on all frames" (acceptable, probably) it's doing
"create on all frames", giving the results you're seeing.

Post a reply to this message

"MDenham" <nomail@nomail> wrote:
> "fillibar" <nomail@nomail> wrote:
> > clipka <ano### [at] anonymousorg> wrote:
> > > Am 06.05.2010 01:50, schrieb MDenham:
> > > > I suspect it is intentional (and is the result of enforcing that #fopen w/
> > > > "write" re-create the file at all times, as the old behavior probably also led
> > > > to unwanted results in different situations).
> > > >
> > > > The options are to either implement a fourth type of file access for #fopen
> > > > that's essentially "write on first frame, append on all later frames", or to
do
> > > > it manually in your scene.
> > >
> > > Maybe I misunderstood; I thought this was about #debug output being
> > > redirected to a file.
> > >
> > > Of course, if it is about #fopen, then using "#fopen ... append" instead
> > > of "#fopen ... write" should do the trick (except for the first frame,
> > > which should use "write" instead to erase the old contents).
> >
> > No, it is about directing #debug output to a file, the "Debug_File=" command
> > used in a .ini. I will open a bug about it since my feeling is that if you are
> > wanting debug information you probably would want it for the entire duration of
> > a render not just a single frame (if you are making more than one). In the
> > meantime I will also take a look at #fopen as an alternative.
>
> My fault, I misunderstood what you were doing (mostly because I forgot
> Debug_File exists :-/).
>
> Still, I suspect that someone probably made a similar change in the source to
> what I'd mentioned, and instead of "create on first frame, append on all later
> frames" (ideal) or "append on all frames" (acceptable, probably) it's doing
> "create on all frames", giving the results you're seeing.

That is the area I wonder about... Is it a feature because someone wanted it
"create on all frames" at one point, or is it a bug because it is supposed to do
one of the others. For my usage, it is a bug, so I am entering it now. Hopefully
that will either resolve the feature or bug question. If it is a feature, I just
need to find a workaround (rendering 1 frame at a time is really not an option).

Post a reply to this message

"fillibar" <nomail@nomail> wrote:
> I just put 3.7.37a on a computer that had always been running 3.6. I just
> started outputting the debug information to a file (to confirm what values were
> used per frame since I am making MANY frames and wanted to know what values
> cause bad looking frames).
>
> In 3.6 each "block" of debug information was written into the debug.txt (the
> filename I am outputting to) sequentially, with each frame appending to the
> content already there. So I was able to look through the debug values for the 10
> sample frames I rendered (only 10 at the time) and everything was listed. I even
> added extra debug text to help separate the frame output because of this
> feature. The entire file was overwritten if I restarted another sample run
> (which is preferred for my needs).
>
> I just installed 3.7.37a earlier today and ran the same .pov file with the same
> options. Now the debug.txt file is created but the information is contained with
> each frame. So if I let it finish the entire sample, I will only have the values
> for frame 10 not the other 9 (which is needed).
>
> So my question is this:
> Is this an EXPECTED feature change or is this a bug I should put into Flyspray?
>
> I did searches but did not find anything that seemed to relate to this, but I
> might have missed it.

In case anyone actually is interested in this, it has been submitted into
Flyspray as:
FS#109 - Debug_File No Longer Appends Frame by Frame Debug Data

Post a reply to this message