 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3C8B528A.915FBB09@topsurf.com> , John VanSickle
<van### [at] topsurf com> wrote:
> The original file has Inital_Frame=0 and the replacement INI file has
> Initial_Frame=1.
>
> Also, when the original .INI has Final_Frame=-1, the replacement keeps
> getting written with Final_Frame=1.
Well, why are you surprised about this? A frame number can only be positive.
Not positive frame number were never supported. In fact, prior to 3.5 POV-Ray
would not check if you specified valid input. Setting Final_Frame=-1 would
actually turn the animation off, and specifying frame numbers below -1 caused
various problems and errors along the way and was never supported but no error
was reported. Now, in POV-Ray 3.5 all negative Final_Frame values turn the
animation off. Effectively this is done by changing it to Final_Frame=1,
which means there is only one frame and consequently no animation - the result
of Final_Frame=-1 and Final_Frame=1 is the same.
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Well, why are you surprised about this? A frame number can only be
positive.
> Not positive frame number were never supported.
This seems like a very arbitrary limitation. Being someone who likes
zero-based counting, I use Initial_Frame=0 very often, and it has always
worked for me. Are you saying that it isn't going to work in the future?
Anders
--
light_source{6#local D=#macro B(E)#macro A(D)#declare E=(E-#declare
C=mod(E D);C)/D;C#end#while(E)#if(A(8)=7)#declare D=D+2.8;#else#if(
C>2)}torus{1..2clipped_by{box{-2y}}rotate<1 0C>*90translate<D+1A(2)
*2+1#else}cylinder{0(C-v=1).2translate<D+C*A(2)A(4)#end-2 13>finish
{specular 1}pigment{rgb x}#end#end#end-8;1B(445000298)B(519053970)B
(483402386)B(1445571258)B(77778740)B(541684549)B(42677491)B(70)}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c8b7a24$1@news.povray.org> , "Anders K." <and### [at] prostard2gcom>
wrote:
> This seems like a very arbitrary limitation.
If you take a sequence of pictures, do the call the initial picture in the
sequence the 0th or the 1st picture?
> Being someone who likes
> zero-based counting, I use Initial_Frame=0 very often, and it has always
> worked for me. Are you saying that it isn't going to work in the future?
It hasn't been possible in any 3.5 beta and now after five month and several
thousand downloads of each of the betas the first person notices - so it is
correct to conclude that this must be the most important undocumented behavior
in 3.0 and 3.1!?
Not to mention that it was never documented and the documentation strongly
recommends to leave Initial_Frame at one...
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > This seems like a very arbitrary limitation.
>
> If you take a sequence of pictures, do the call the initial picture in the
> sequence the 0th or the 1st picture?
Well, if you make an array, say a[], in C++, do you call a[0] the 0th or the
1st element? For that matter, does it even matter what you call it? I happen
to like zero-based counting. If you like one-based counting instead, that's
fine, but there's no reason at all that setting Initial_Frame=0 shouldn't
work.
> > Being someone who likes
> > zero-based counting, I use Initial_Frame=0 very often, and it has always
> > worked for me. Are you saying that it isn't going to work in the future?
>
> It hasn't been possible in any 3.5 beta
Huh? I just rendered this scene, and it worked fine in beta 12:
// +kfi0 +kff4
#debug concat(str(frame_number, 0, -1), "\n")
I've also rendered several animations (with 3.5 betas) which needed an
Initial_Frame of 0.
> Not to mention that it was never documented and the documentation strongly
> recommends to leave Initial_Frame at one...
It just says that you *can* leave Initial_Frame=1 if you want. It certainly
doesn't require or even "strongly recommend" that you leave it at 1.
Anders
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c8b9f31@news.povray.org> , "Anders K." <and### [at] prostard2gcom>
wrote:
>> If you take a sequence of pictures, do the call the initial picture in the
>> sequence the 0th or the 1st picture?
>
> Well, if you make an array, say a[], in C++, do you call a[0] the 0th or the
> 1st element? For that matter, does it even matter what you call it?
The reason for zero-based counting in programming languages is not because of
a certain "preference", but because of a necessity to provide efficiency.
Using one-based counting (also it it would avoid many bugs) is significantly
less efficient than zero-based counting and especially in the early days would
have been impossible to implement without significant hardware expense!
And maybe I missed something, but how many non-computer programming uses of
zero-based counting are there? Not really any unless they are badly derived
from some computer functionality!!! So using a limitation of regular
programming languages to justify zero-based counting is the worst of all
arguments possible and the least valid. And I should point out that this is
*only* in most but not all programming languages - nearly all books on
theoretical computer science use one based counting because of its natural
simplicity which has been discovered by humans thousands of years ago and
proven itself! Only because to program computers efficiently in their early
days (and which existed in their current form only for a few decades) the
uniformly accepted standard of counting should be considered a matter of
personal preference? Oh well :-(
>> It hasn't been possible in any 3.5 beta
>
> Huh? I just rendered this scene, and it worked fine in beta 12:
> // +kfi0 +kff4
> #debug concat(str(frame_number, 0, -1), "\n")
>
> I've also rendered several animations (with 3.5 betas) which needed an
> Initial_Frame of 0.
Indeed, the checking isn't applied everywhere...
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> And maybe I missed something, but how many non-computer programming uses
of
> zero-based counting are there?
Several. For example, one of my recent POV-Ray projects was rendering a set
of 720 tiles which get assembled into a 36x20 bitmap. To simplify this, I
used animation to make a set of bitmaps called tile000.bmp through
tile719.bmp, and I wrote a program that adds each tile bitmap to the master
bitmap. The formula that it uses to calculate where each tile goes is pretty
simple:
x = n mod 36
y = int(n / 36)
Where n is the zero-based tile number, x is the zero-based row number in the
master bitmap, and y is the zero-based column number in the master bitmap.
Now, If I had used one-based counting for everything instead, the formula
would have looked more like this:
x = ((n - 1) mod 36) + 1
y = int((n + (36 - 1)) / 36)
You say one-based counting would avoid many bugs, but which formula do you
think would be more likely to have bugs in it?
Please remember that I'm not asking you to change anything, only to leave it
the way it is! The current behavior is fine for both one-based and
zero-based counting, so what's the problem?
Anders
--
light_source{6#local D=#macro B(E)#macro A(D)#declare E=(E-#declare
C=mod(E D);C)/D;C#end#while(E)#if(A(8)=7)#declare D=D+2.8;#else#if(
C>2)}torus{1..2clipped_by{box{-2y}}rotate<1 0C>*90translate<D+1A(2)
*2+1#else}cylinder{0(C-v=1).2translate<D+C*A(2)A(4)#end-2 13>finish
{specular 1}pigment{rgb x}#end#end#end-8;1B(445000298)B(519053970)B
(483402386)B(1445571258)B(77778740)B(541684549)B(42677491)B(70)}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c8bfd53@news.povray.org> , "Anders K." <and### [at] prostard2gcom>
wrote:
>> And maybe I missed something, but how many non-computer programming uses
>> of zero-based counting are there?
>
> I wrote a program
So writing a program is a "non-computer programming" use? :-)
> Please remember that I'm not asking you to change anything, only to leave it
> the way it is!
I am not saying it will be changed either!
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sun, 10 Mar 2002 17:02:06 +0100, "Thorsten Froehlich"
<tho### [at] trfde> wrote:
>In article <3c8b7a24$1@news.povray.org> , "Anders K." <and### [at] prostard2gcom>
>wrote:
>
>> This seems like a very arbitrary limitation.
>
>If you take a sequence of pictures, do the call the initial picture in the
>sequence the 0th or the 1st picture?
This all depends on whether you're counting frames or elapsed time.
If your frames are based on elapsed time, it makes a great deal of
sense to number the first one zero (i.e., no time has elapsed yet)...
>
>> Being someone who likes
>> zero-based counting, I use Initial_Frame=0 very often, and it has always
>> worked for me. Are you saying that it isn't going to work in the future?
>
>It hasn't been possible in any 3.5 beta and now after five month and several
>thousand downloads of each of the betas the first person notices - so it is
>correct to conclude that this must be the most important undocumented behavior
>in 3.0 and 3.1!?
>
>Not to mention that it was never documented and the documentation strongly
>recommends to leave Initial_Frame at one...
>
> Thorsten
>
>____________________________________________________
>Thorsten Froehlich, Duisburg, Germany
>e-mail: tho### [at] trfde
>
>Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sun, 10 Mar 2002 17:02:06 +0100, Thorsten Froehlich wrote:
> It hasn't been possible in any 3.5 beta and now after five month and several
> thousand downloads of each of the betas the first person notices - so it is
> correct to conclude that this must be the most important undocumented behavior
> in 3.0 and 3.1!?
So what you're saying is that now that everyone's stopped looking for bugs
and started using the program as normal that if they find any bugs you're
just going to ignore them?
--
sphere{z*5,1pigment{rgb.5}finish{reflection.3specular.5}}box{<-50,-3,-50>
<50,-2,50>pigment{checker/*\__\\__/ * \_\\__*/scale 2}finish{ambient.7}}
light_source/*__\\__\\__\\__\\__\( ~ )\__\\__\\__\\__\\*/{<2,5,1>*4,1}
/*\\__\\__\\__\\__\\__\\__\\__\\__\~ -/__\\__\\__\\__\\__\\*//* Steve */
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <slr### [at] zero-ppslocaldomain> , Steve
<ste### [at] zeroppsuklinuxnet> wrote:
>> It hasn't been possible in any 3.5 beta and now after five month and several
>> thousand downloads of each of the betas the first person notices - so it is
>> correct to conclude that this must be the most important undocumented
>> behavior in 3.0 and 3.1!?
>
> So what you're saying is that now that everyone's stopped looking for bugs
> and started using the program as normal that if they find any bugs you're
> just going to ignore them?
No, what I wrote does neither say nor imply this but something completely
different. Maybe you should read what I wrote more carefully...
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
