 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I have the Create_ini option set to create an INI. After getting some
undesired images, I noticed that POV-Ray was writing the new .INI file
with values different from what was supplied by the INI used to run
POV.
Final_Frame and Initial_Frame exhibit this problem. Additionally,
the new INI file has no entries for any Declare options in the previous
incarnation of the INI.
I'm running Win95, AMD K6-2/300MHz, 96Megs RAM.
--
ICQ: 46085459
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3C8### [at] topsurf com> , John VanSickle
<van### [at] topsurfcom> wrote:
> I have the Create_ini option set to create an INI. After getting some
> undesired images, I noticed that POV-Ray was writing the new .INI file
> with values different from what was supplied by the INI used to run
> POV.
>
> Final_Frame and Initial_Frame exhibit this problem.
Explain "values different from what was supplied", please. It can mean
anything.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich wrote:
>
> In article <3C8### [at] topsurfcom> , John VanSickle
> <van### [at] topsurfcom> wrote:
>
> > I have the Create_ini option set to create an INI. After getting
> > some undesired images, I noticed that POV-Ray was writing the new
> > .INI file with values different from what was supplied by the INI
> > used to run POV.
> >
> > Final_Frame and Initial_Frame exhibit this problem.
>
> Explain "values different from what was supplied", please. It can
> mean anything.
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.
Regards,
John
--
ICQ: 46085459
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I should point out that there is no need to have the Create_Ini option
switched on for every test render, and that's the only case where the
bug causes any problems.
--
ICQ: 46085459
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3C8B528A.915FBB09@topsurf.com> , John VanSickle
<van### [at] topsurfcom> 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
|
|
| |
| |
|
|
|
|
| |
|
|
