Using INI file for animation and setting Initial_Frame=0 ignores the zero, 
starting the series of file names at frame 1. Same happens with command-line 
switch +kfi0

When I tried Subset_Start_Frame=0 the program crashed.

3.7.0.beta.11c.icl8.win32

Post a reply to this message

Bob Hughes wrote:
> Using INI file for animation and setting Initial_Frame=0 ignores the zero, 
> starting the series of file names at frame 1. Same happens with command-line 
> switch +kfi0

The smallest allowed initial frame value is 1.

> When I tried Subset_Start_Frame=0 the program crashed.

Indeed, POV-Ray should not crash when facing invalid input :-)

	Thorsten

Post a reply to this message

"Thorsten Froehlich" <tho### [at] trfde> wrote in message 
news:43fc6bd6$1@news.povray.org...
> Bob Hughes wrote:
>> Using INI file for animation and setting Initial_Frame=0 ignores the 
>> zero, starting the series of file names at frame 1. Same happens with 
>> command-line switch +kfi0
>
> The smallest allowed initial frame value is 1.
>
>> When I tried Subset_Start_Frame=0 the program crashed.
>
> Indeed, POV-Ray should not crash when facing invalid input :-)

Well, good you said that, program crashing problem will likely get fixed 
then. heh-heh

However, since initial frame of zero is unavailable, this must mean 
something was changed. I had mostly used that as the starting number for 
mpeg creation by running a batch file which accepts a number of digits at 
the end of a file name, anim000 for example, and counts up from there. It 
can be worked around, of course. Makes me wonder, though, why it must be 1 
and not 0 anymore. Was there a special reason involved or was it about ways 
people expect counting to begin?

Bob H

Post a reply to this message

Bob Hughes wrote:
> Well, good you said that, program crashing problem will likely get fixed 
> then. heh-heh

:-)

> However, since initial frame of zero is unavailable, this must mean 
> something was changed. I had mostly used that as the starting number for 
> mpeg creation by running a batch file which accepts a number of digits at 
> the end of a file name, anim000 for example, and counts up from there. It 
> can be worked around, of course. Makes me wonder, though, why it must be 1 
> and not 0 anymore. Was there a special reason involved or was it about ways 
> people expect counting to begin?

It was actually never documented to work, and as such never checked if it 
does work. It is possible that previous versions did work with 0 (certainly 
no negative values) for the most part, but I certainly would not want to 
claim the results were predictable for all animation features (i.e. field 
rendering, subframe rendering, etc).

	Thorsten

Post a reply to this message

"Thorsten Froehlich" <tho### [at] trfde> wrote in message 
news:43fc7595$1@news.povray.org...
>
> It was actually never documented to work

I never gave it a second thought, myself, since counting from zero seems to 
go along with things like 0 to 1 to maybe mirror the clock's (decimal) 
values. Just thought 1,2,3... might have been determined to be more common 
and therefore less confusing for frame counts, but then POV is often 
considered to have been made to allow for out of the ordinary user-specified 
numbers so negative frame numbers wouldn't be too surprising either.  ;)

Bob H

Post a reply to this message

"Bob Hughes" <omniverse@charter%net> wrote in message
news:43fc7955@news.povray.org...
> "Thorsten Froehlich" <tho### [at] trfde> wrote in message
> news:43fc7595$1@news.povray.org...
> >
> > It was actually never documented to work
>
> I never gave it a second thought, myself, since counting from zero seems to
> go along with things like 0 to 1 to maybe mirror the clock's (decimal)
> values. Just thought 1,2,3... might have been determined to be more common
> and therefore less confusing for frame counts, but then POV is often
> considered to have been made to allow for out of the ordinary user-specified
> numbers so negative frame numbers wouldn't be too surprising either.  ;)

Indeed 0 is what 3D Studio MAX uses as its first frame (but it has always made
things difficult).

Lance.

thezone - thezone.firewave.com.au

Post a reply to this message

Thorsten Froehlich wrote:
> It was actually never documented to work, and as such never checked if 
> it does work. It is possible that previous versions did work with 0 
> (certainly no negative values) for the most part, but I certainly would 
> not want to claim the results were predictable for all animation 
> features (i.e. field rendering, subframe rendering, etc).
> 
>     Thorsten


Personally, I've always used an initial frame of 0, and never had any 
problems.  So this was really a surprise to me!

...Chambers

Post a reply to this message

Chambers wrote:
> Personally, I've always used an initial frame of 0, and never had any 
> problems.  So this was really a surprise to me!

Hmm, the documentation always strongly recommended using one and never 
changing it. I am actually surprised the old code didn't have any problems 
with it. If there is extremely widespread use of a zero-base, we might have 
to see if we can detect it and do something sensible, though I am not sure 
that will be possible. Most other features use the 0 to 1 range for 
percentages...

	Thorsten

Post a reply to this message