 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In the POV-Ray documentation on the page about string functions the
following is stated:
> substr(S,P,L) Sub-string from S. Returns a string that is
> a subset of the characters in parameter S starting at the
> position specified by the integer value P for a length
> specified by the integer value L. For example
> substr("ABCDEFGHI",4,2) evaluates to the string "EF".
> If P+L>strlen(S) an error occurs.
However, there are two errors. The last but one line should read:
> substr("ABCDEFGHI",4,2) evaluates to the string "DE".
And the last line should read:
> If P+L+1>strlen(S) an error occurs.
Or something like that.
Can anybody confirm?
And is this a known bug?
Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated January 28)
/ Also visit http://www.povrayusers.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rune wrote in message <3a942303@news.povray.org>...
> In the POV-Ray documentation on the page about string functions the
> following is stated:
that's funny
looking at time of your post it seems that I've met this bug at the same moment
perhaps even in solving the same problem :-)
> > substr("ABCDEFGHI",4,2) evaluates to the string "EF".
> However, there are two errors. The last but one line should read:
> substr("ABCDEFGHI",4,2) evaluates to the string "DE".
I can confirm
> > If P+L>strlen(S) an error occurs.
> If P+L+1>strlen(S) an error occurs.
I can confirm
> Can anybody confirm?
yes
> And is this a known bug?
I don't know
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
It seems that the one who wrote that part of the doc thought that the
indexing starts from 0 and ends at strlen(S)-1, as in C.
Perhaps the problem is not in the documentation, but in povray. In my
opinion this behaviour is a bit inconsistent. Array indexing starts from 0.
--
char*i="b[7FK@`3NB6>B:b3O6>:B:b3O6><`3:;8:6f733:>::b?7B>:>^B>C73;S1";
main(_,c,m){for(m=32;c=*i++-49;c&m?puts(""):m)for(_=(
c/4)&7;putchar(m),_--?m:(_=(1<<(c&3))-1,(m^=3)&3););} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Position 1 might be a good way of saying first character of a string though,
since it isn't a completely numerical thing being dealt with.
substr("abcd",1,1) being "a", instead of substr("abcd",0,0), just looks more
correct in this context to me.
Why isn't there a strlen() in the documentation? :-)
Bob H.
"Warp" <war### [at] tag povrayorg> wrote in message
news:3a94e885@news.povray.org...
> It seems that the one who wrote that part of the doc thought that the
> indexing starts from 0 and ends at strlen(S)-1, as in C.
>
> Perhaps the problem is not in the documentation, but in povray. In my
> opinion this behaviour is a bit inconsistent. Array indexing starts from
0.
>
> --
> char*i="b[7FK@`3NB6>B:b3O6>:B:b3O6><`3:;8:6f733:>::b?7B>:>^B>C73;S1";
> main(_,c,m){for(m=32;c=*i++-49;c&m?puts(""):m)for(_=(
> c/4)&7;putchar(m),_--?m:(_=(1<<(c&3))-1,(m^=3)&3););} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 22 Feb 2001 07:10:17 -0600, Bob H. wrote:
>Why isn't there a strlen() in the documentation? :-)
There is, but it's not with the string functions. It returns a numeric
value, so it's with the float functions:
strlen(S) Length of S. Returns an integer value that is the number of
characters in the string S.
--
Ron Parker http://www2.fwi.com/~parkerr/traces.html
My opinions. Mine. Not anyone else's.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Sorry, I didn't look hard enough. I used Context Help by right-clicking on
strlen within a scene file and it claimed not to have it even though I knew
it was a function. Using Scene help button in WinPOV found it fine.
Bob H.
"Ron Parker" <ron### [at] povrayorg> wrote in message
news:slr### [at] fwicom...
> On Thu, 22 Feb 2001 07:10:17 -0600, Bob H. wrote:
> >Why isn't there a strlen() in the documentation? :-)
>
> There is, but it's not with the string functions. It returns a numeric
> value, so it's with the float functions:
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
>
> It seems that the one who wrote that part of the doc thought that the
> indexing starts from 0 and ends at strlen(S)-1, as in C.
>
> Perhaps the problem is not in the documentation, but in povray. In my
> opinion this behaviour is a bit inconsistent. Array indexing starts from 0.
>
But don't forget that in Pascal/Delphi it works the other way:
copy('ABCDEF', 3, 2)
returns 'CD'.
Both ways have their advantages, i would keep it the way it is now.
Christoph
--
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other
things on: http://www.schunter.etc.tu-bs.de/~chris/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rune <run### [at] inamecom> wrote:
> In the POV-Ray documentation on the page about string functions the
> following is stated:
>> substr(S,P,L) Sub-string from S. Returns a string that is
>> a subset of the characters in parameter S starting at the
>> position specified by the integer value P for a length
>> specified by the integer value L. For example
>> substr("ABCDEFGHI",4,2) evaluates to the string "EF".
>> If P+L>strlen(S) an error occurs.
> However, there are two errors. The last but one line should read:
>> substr("ABCDEFGHI",4,2) evaluates to the string "DE".
> And the last line should read:
>> If P+L+1>strlen(S) an error occurs.
> Or something like that.
> Can anybody confirm?
> And is this a known bug?
This is C style, counting from 0 rather than 1, which is what arrays do.
Have you tried the program to see what it does? Does it count from 1 or 0?
If it goes from 1, then I see it as a bug in the program, not the docs,
because it's inconsistent.
Speaking of manual bugs, can anyone confirm that the #range feature for
#switch is actually lower < value <= upper and not lower <= value <= upper
like it says in the manual?
Geoff
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Geoff Wedig wrote:
>
> Speaking of manual bugs, can anyone confirm that the #range feature for
> #switch is actually lower < value <= upper and not lower <= value <= upper
> like it says in the manual?
The doc is correct.
#switch( var)
#range (1, 10)
box{ 0, 1 pigment{ color rgb 1 }}
#else
sphere{ 0, 1 pigment { color rgb <1,0,0> }}
#end
creates a white box when var=1, not a red sphere as you think it would.
>
> Geoff
--
Francois Labreque | //\\ Wear an ASCII ribbon!
flabreque | || ||
@ | \\// Support the campain
videotron.ca \\ against HTML e-mail
//\\ and news!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann <chr### [at] gmxde> wrote:
: Both ways have their advantages, i would keep it the way it is now.
The problem is that it can cause confusion.
If someone is used to use substr() and then starts using arrays he will
probably be confused at first and think that also in arrays the indexing
starts from 1. And the other way around.
It's the same type of confusion as caused by functions taking radians and
rotate taking degrees...
--
char*i="b[7FK@`3NB6>B:b3O6>:B:b3O6><`3:;8:6f733:>::b?7B>:>^B>C73;S1";
main(_,c,m){for(m=32;c=*i++-49;c&m?puts(""):m)for(_=(
c/4)&7;putchar(m),_--?m:(_=(1<<(c&3))-1,(m^=3)&3););} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Francois Labreque <fla### [at] videotronca> wrote:
> Geoff Wedig wrote:
>>
>> Speaking of manual bugs, can anyone confirm that the #range feature for
>> #switch is actually lower < value <= upper and not lower <= value <= upper
>> like it says in the manual?
> The doc is correct.
> #switch( var)
> #range (1, 10)
> box{ 0, 1 pigment{ color rgb 1 }}
> #else
> sphere{ 0, 1 pigment { color rgb <1,0,0> }}
> #end
> creates a white box when var=1, not a red sphere as you think it would.
Hmm, then something else must be funny, because when I do
// Define a bunch of stuff.
#switch(clock)
#range(0, 9)
#define stuff
#break
#range(10, 20)
#define stuff
#break
#end
The 10th frame doesn't get any definitions from the switch, which is why I
mentioned this. I had to set it to range(9.5, 20) to get it to work right.
So what else might be causing this?
Geoff
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Francois Labreque" <fla### [at] videotronca> wrote in message
news:3A952F9F.43B9E767@videotron.ca...
>
> Geoff Wedig wrote:
> >
> > Speaking of manual bugs, can anyone confirm that the #range feature for
> > #switch is actually lower < value <= upper and not lower <= value <=
upper
> > like it says in the manual?
>
> The doc is correct.
>
> #switch( var)
> #range (1, 10)
> box{ 0, 1 pigment{ color rgb 1 }}
> #else
> sphere{ 0, 1 pigment { color rgb <1,0,0> }}
> #end
>
> creates a white box when var=1, not a red sphere as you think it would.
Nope, sorry. Not so it would seem. It is 1 to 10 inclusive but you need a
#break ahead of the #else otherwise you actually get both objects. In
MegaPov anyway.
Bob H.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 22 Feb 2001 12:31:32 -0500, Geoff Wedig wrote:
>#switch(clock)
>
> #range(0, 9)
> #define stuff
> #break
> #range(10, 20)
> #define stuff
> #break
>
>#end
>
>The 10th frame doesn't get any definitions from the switch, which is why I
>mentioned this. I had to set it to range(9.5, 20) to get it to work right.
>
>So what else might be causing this?
roundoff error?
--
Ron Parker http://www2.fwi.com/~parkerr/traces.html
My opinions. Mine. Not anyone else's.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker <ron### [at] povrayorg> wrote:
> On 22 Feb 2001 12:31:32 -0500, Geoff Wedig wrote:
>>#switch(clock)
>>
>> #range(0, 9)
>> #define stuff
>> #break
>> #range(10, 20)
>> #define stuff
>> #break
>>
>>#end
>>
>>The 10th frame doesn't get any definitions from the switch, which is why I
>>mentioned this. I had to set it to range(9.5, 20) to get it to work right.
>>
>>So what else might be causing this?
> roundoff error?
Not in this case. I'm dealing strictly with integers.
Geoff
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 22 Feb 2001 13:10:38 -0500, Geoff Wedig wrote:
>> roundoff error?
>
>Not in this case. I'm dealing strictly with integers.
Are you sure clock is an integer?
--
Ron Parker http://www2.fwi.com/~parkerr/traces.html
My opinions. Mine. Not anyone else's.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker <ron### [at] povrayorg> wrote:
> On 22 Feb 2001 13:10:38 -0500, Geoff Wedig wrote:
>>> roundoff error?
>>
>>Not in this case. I'm dealing strictly with integers.
> Are you sure clock is an integer?
Well, initial_clock and final clock are both integers, and equal to initial
frame and final frame respectively. And in the log they're all .00000, so
yeah, pretty sure. ;)
Geoff
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 22 Feb 2001 13:41:49 -0500, Geoff Wedig wrote:
>Ron Parker <ron### [at] povrayorg> wrote:
>
>> On 22 Feb 2001 13:10:38 -0500, Geoff Wedig wrote:
>>>> roundoff error?
>>>
>>>Not in this case. I'm dealing strictly with integers.
>
>> Are you sure clock is an integer?
>
>Well, initial_clock and final clock are both integers, and equal to initial
>frame and final frame respectively. And in the log they're all .00000, so
>yeah, pretty sure. ;)
Can you tell me what initial and final clock/frame are, so I can try to
duplicate the problem?
--
Ron Parker http://www2.fwi.com/~parkerr/traces.html
My opinions. Mine. Not anyone else's.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Ron Parker" <ron### [at] povrayorg> wrote in message
news:slr### [at] fwicom...
> On 22 Feb 2001 13:10:38 -0500, Geoff Wedig wrote:
> >> roundoff error?
> >
> >Not in this case. I'm dealing strictly with integers.
>
> Are you sure clock is an integer?
Always a good idea to make the variable in question readable in order to be
sure; via a text object, file output, or message stream. Example:
#debug concat("Clock value is ", str(clock,0,-1))
But from what I can tell a clock done by frame number instead of the typical
0 to 1 is pretty much an integer.
Of course another good question might be what version of POV is being used,
just in case, eh?
Bob H.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker <ron### [at] povrayorg> wrote:
> On 22 Feb 2001 13:41:49 -0500, Geoff Wedig wrote:
>>Ron Parker <ron### [at] povrayorg> wrote:
>>
>>> On 22 Feb 2001 13:10:38 -0500, Geoff Wedig wrote:
>>>>> roundoff error?
>>>>
>>>>Not in this case. I'm dealing strictly with integers.
>>
>>> Are you sure clock is an integer?
>>
>>Well, initial_clock and final clock are both integers, and equal to initial
>>frame and final frame respectively. And in the log they're all .00000, so
>>yeah, pretty sure. ;)
> Can you tell me what initial and final clock/frame are, so I can try to
> duplicate the problem?
Not easily. I've revised the code to get rid of the problem frames. I
believe they were 0 and 90 or 0 and 70 (one of the two).
Here's the switch I was using. There were default parameters (essentially
case 0) defined before the #switch. I found that frames 13, 20, 25, etc
were using these defaults rather than the range, and assumed it to be dues
to that be a < rather than <=. I changed them to .5 less and everything
worked fine.
#switch (clock)
#case(0)
$attack_percentage = 0;
$window_opening = 1;
$engine_glow = 1;
#break
#range(1,12)
$attack_percentage = 0;
$window_opening = (25-clock)/25;
$engine_glow = 1;
#break
#range(13,19)
$attack_percentage = 0;
$window_opening = (25-clock)/25;
$engine_glow = (37-clock)/25;
#break
#range(20,24)
$attack_percentage = (clock-19)/50;
$window_opening = (25-clock)/25;
$engine_glow = (37-clock)/25;
#break
#range(25,37)
$attack_percentage = (clock-19)/50;
$window_opening = 0;
$engine_glow = (37-clock)/25;
#break
#range(38,59)
$attack_percentage = (clock-19)/50;
$window_opening = 0;
$engine_glow = 0;
#break
#range(60, 69)
$attack_percentage = (clock-19)/50;
$window_opening = 0;
$engine_glow = 0;
$shield_on = (clock - 60)/20;
#break
#range(70,90)
$shield_on = min((clock - 60)/20,1);
#break
#end
Geoff
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bob H. <omn### [at] msncom> wrote:
> "Ron Parker" <ron### [at] povrayorg> wrote in message
> news:slr### [at] fwicom...
>> On 22 Feb 2001 13:10:38 -0500, Geoff Wedig wrote:
>> >> roundoff error?
>> >
>> >Not in this case. I'm dealing strictly with integers.
>>
>> Are you sure clock is an integer?
> Always a good idea to make the variable in question readable in order to be
> sure; via a text object, file output, or message stream. Example:
> #debug concat("Clock value is ", str(clock,0,-1))
> But from what I can tell a clock done by frame number instead of the typical
> 0 to 1 is pretty much an integer.
> Of course another good question might be what version of POV is being used,
> just in case, eh?
This was Megapov 0.6;
Geoff
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> It's the same type of confusion as caused by functions taking radians and
rotate taking degrees...
> /*- Warp -*/
All the trig functions use radians, but rotate, and camera angle are degrees.
Sometimes I have to convert angles five times in one macro. Any idea why they
didn't keep things consistent?
--
Dan Johnson
http://www.geocities.com/zapob
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3A959B66.9B14E1DA@hotmail.com>, Dan Johnson
<zap### [at] hotmailcom> wrote:
> All the trig functions use radians, but rotate, and camera angle are
> degrees.
> Sometimes I have to convert angles five times in one macro. Any idea
> why they didn't keep things consistent?
They did...they kept the functions consistent with their C equivalents,
except for vrotate, which they kept consistent with the rotate
transformation, which they used degrees for because most people use
degrees for that kind of angular measurement, and they probably used
degrees in the camera angle for the same reason...see? ;-)
My guess is that the transformations were added first, and used degrees
because they are the angle usually used. The camera angle probably just
went along with these. But later, when trig functions were added, they
were kept consistent with the C functions, so people coming from C
wouldn't get confused.
It would be nice to just use revolutions as the standard measurement,
and provide a radians() function that takes radians, and a degrees()
function for degrees. Probably not going to happen, though...there are
few scenes it wouldn't break.
--
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/
<><
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bob H." wrote:
>
> "Francois Labreque" <fla### [at] videotronca> wrote in message
> news:3A952F9F.43B9E767@videotron.ca...
> >
> > Geoff Wedig wrote:
> > >
> > > Speaking of manual bugs, can anyone confirm that the #range feature for
> > > #switch is actually lower < value <= upper and not lower <= value <=
> upper
> > > like it says in the manual?
> >
> > The doc is correct.
> >
> > #switch( var)
> > #range (1, 10)
> > box{ 0, 1 pigment{ color rgb 1 }}
> > #else
> > sphere{ 0, 1 pigment { color rgb <1,0,0> }}
> > #end
> >
> > creates a white box when var=1, not a red sphere as you think it would.
>
> Nope, sorry. Not so it would seem. It is 1 to 10 inclusive but you need a
> #break ahead of the #else otherwise you actually get both objects. In
> MegaPov anyway.
I forgot to type the #break statement, so sue me!
[Note to self: Never post before your morning coffee]
--
Francois Labreque | //\\ Wear an ASCII ribbon!
flabreque | || ||
@ | \\// Support the campain
videotron.ca \\ against HTML e-mail
//\\ and news!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Geoff Wedig <wed### [at] darwinepbicwruedu> wrote:
:> Are you sure clock is an integer?
: Well, initial_clock and final clock are both integers, and equal to initial
: frame and final frame respectively. And in the log they're all .00000, so
: yeah, pretty sure. ;)
It may (seem to) have an integer value, but that doesn't mean that it's
an integer type.
As all values in povray, it's a floating point value. It shouldn't be
necessary to say more...
--
char*i="b[7FK@`3NB6>B:b3O6>:B:b3O6><`3:;8:6f733:>::b?7B>:>^B>C73;S1";
main(_,c,m){for(m=32;c=*i++-49;c&m?puts(""):m)for(_=(
c/4)&7;putchar(m),_--?m:(_=(1<<(c&3))-1,(m^=3)&3););} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 23 Feb 2001 07:23:32 -0500, Warp wrote:
>Geoff Wedig <wed### [at] darwinepbicwruedu> wrote:
>:> Are you sure clock is an integer?
>
>: Well, initial_clock and final clock are both integers, and equal to initial
>: frame and final frame respectively. And in the log they're all .00000, so
>: yeah, pretty sure. ;)
>
> It may (seem to) have an integer value, but that doesn't mean that it's
>an integer type.
> As all values in povray, it's a floating point value. It shouldn't be
>necessary to say more...
It shouldn't be, but I will anyway. If when we calculate the clock value
we divide before we multiply, we can get roundoff error. I'm pretty sure
that if we multiply before we divide, we won't, so that's why I wanted the
original values Geoff used: so I can have a test case.
--
Ron Parker http://www2.fwi.com/~parkerr/traces.html
My opinions. Mine. Not anyone else's.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Francois Labreque" <fla### [at] videotronca> wrote in message
news:3A95C73E.8AE8DD82@videotron.ca...
>
> I forgot to type the #break statement, so sue me!
>
> [Note to self: Never post before your morning coffee]
;-) Applies to me more often than not, morning noon or night (less the
coffee part).
Bob H.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> Geoff Wedig <wed### [at] darwinepbicwruedu> wrote:
> :> Are you sure clock is an integer?
> : Well, initial_clock and final clock are both integers, and equal to initial
> : frame and final frame respectively. And in the log they're all .00000, so
> : yeah, pretty sure. ;)
> It may (seem to) have an integer value, but that doesn't mean that it's
> an integer type.
> As all values in povray, it's a floating point value. It shouldn't be
> necessary to say more...
Except for the slight problem that floats can represent integers, the
initializers and additions are integers. There's absolutely no reason why
these wouldn't be integers too. Or are you saying that Pov gets numerical
error when adding 1 succesively to 0 for values < 100? If so, then POv has
far worse problems than the range statement.
Geoff
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3a9690a0@news.povray.org> , Geoff Wedig
<wed### [at] darwinepbicwruedu> wrote:
> Except for the slight problem that floats can represent integers
The problem is not that they can't represent integers if rounded at for
example the tenth digit, but if you take the whole floating-point number
you may well have a case like this (the error is just a _very_ simple
example, the real error will be more complicated and may appear in
different operations because of the way floating-point numbers are
represented internally).
Imagine: integer 4 = floating-point 4.00000000001
integer 2 = floating-point 2.0000000001
2.00000000001 + 2.00000000001 = 4.00000000002 != 4.00000000001
Get the idea?
Thorsten
PS: In some cases POV-Ray tries to compensate for this with a little
threshold when comparing for equality.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich <tho### [at] trfde> wrote:
> In article <3a9690a0@news.povray.org> , Geoff Wedig
> <wed### [at] darwinepbicwruedu> wrote:
>> Except for the slight problem that floats can represent integers
> The problem is not that they can't represent integers if rounded at for
> example the tenth digit, but if you take the whole floating-point number
> you may well have a case like this (the error is just a _very_ simple
> example, the real error will be more complicated and may appear in
> different operations because of the way floating-point numbers are
> represented internally).
> Imagine: integer 4 = floating-point 4.00000000001
> integer 2 = floating-point 2.0000000001
> 2.00000000001 + 2.00000000001 = 4.00000000002 != 4.00000000001
> Get the idea?
I deal with float and integer problems every day. My work is in
mathematical computation, so yeah, I've heard of the idea.
And it's completely irrelevant. It may be true in many cases, but in *this*
case, we're dealing with a float that was *initialized* to an integer, and
with integral values small enough to fit in the storage bits, they're stored
as integers (basically). It's only when you have to use the shift bits that
funky things happen. This has *long* been a standard. If I were doing
dividing, where a small roundoff could have occured, then there might've
been some question, but in this case, we're dealing with integers added to
integers, albeit stored as floats. I can't see why they'd conflict in this
fashion. Or is POV doing something extremely funky with the clock? I
suppose it's possible that rather than use the settings I gave it for
initial and final clock, it still does 0-1, but then multiplies it by the
difference and adds the initial_clock, to get the clock setting given to the
scene file, but that seems like a lot of work when the true values are right
there.
Geoff
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 23 Feb 2001 14:36:47 -0500, Geoff Wedig wrote:
>funky things happen. This has *long* been a standard. If I were doing
>dividing, where a small roundoff could have occured, then there might've
>been some question, but in this case, we're dealing with integers added to
>integers, albeit stored as floats. I can't see why they'd conflict in this
>fashion. Or is POV doing something extremely funky with the clock? I
>suppose it's possible that rather than use the settings I gave it for
>initial and final clock, it still does 0-1, but then multiplies it by the
>difference and adds the initial_clock, to get the clock setting given to the
>scene file, but that seems like a lot of work when the true values are right
>there.
That's what I thought it must be doing, too, at first, but I see now that
it computes the clock delta and adds it for each frame. The clock delta is
given by (final_clock-initial_clock)/(final_frame-initial_frame), which
should be exactly 1 unless you're using an old Pentium, but perhaps there's
something funky about division that I don't understand.
--
Ron Parker http://www2.fwi.com/~parkerr/traces.html
My opinions. Mine. Not anyone else's.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Is Cyclic_Animation turned on or off?
--
Mark
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker <ron### [at] povrayorg> wrote:
> On 23 Feb 2001 14:36:47 -0500, Geoff Wedig wrote:
>>funky things happen. This has *long* been a standard. If I were doing
>>dividing, where a small roundoff could have occured, then there might've
>>been some question, but in this case, we're dealing with integers added to
>>integers, albeit stored as floats. I can't see why they'd conflict in this
>>fashion. Or is POV doing something extremely funky with the clock? I
>>suppose it's possible that rather than use the settings I gave it for
>>initial and final clock, it still does 0-1, but then multiplies it by the
>>difference and adds the initial_clock, to get the clock setting given to the
>>scene file, but that seems like a lot of work when the true values are right
>>there.
> That's what I thought it must be doing, too, at first, but I see now that
> it computes the clock delta and adds it for each frame. The clock delta is
> given by (final_clock-initial_clock)/(final_frame-initial_frame), which
> should be exactly 1 unless you're using an old Pentium, but perhaps there's
> something funky about division that I don't understand.
May be. I've not spent any time on it, figuring that it looked like a doc
problem, and even if it wasn't, the fix I used worked quite well, so why
worry too much about it?
Geoff
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mark Wagner <mar### [at] gtenet> wrote:
> Is Cyclic_Animation turned on or off?
Dunno why that'd make a difference, but no, it wasn't.
Geoff
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 26 Feb 2001 12:13:34 -0500, Geoff Wedig wrote:
>Mark Wagner <mar### [at] gtenet> wrote:
>
>> Is Cyclic_Animation turned on or off?
>
>Dunno why that'd make a difference, but no, it wasn't.
It makes a difference in the computation of clock_delta. And you didn't
answer the question. :)
--
Ron Parker http://www2.fwi.com/~parkerr/traces.html
My opinions. Mine. Not anyone else's.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker <ron### [at] povrayorg> wrote:
> On 26 Feb 2001 12:13:34 -0500, Geoff Wedig wrote:
>>Mark Wagner <mar### [at] gtenet> wrote:
>>
>>> Is Cyclic_Animation turned on or off?
>>
>>Dunno why that'd make a difference, but no, it wasn't.
> It makes a difference in the computation of clock_delta. And you didn't
> answer the question. :)
Sorry, no, it wasn't turned on. Better? ;)
Geoff
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
